1. Introduction

Welcome WANdisco Subversion Access Control admin guide. Subversion Access Control is a network proxy that provides Subversion Administrators with a comprehensive, easy to setup security agent that offers the following capabilities:


1.1 Technical Overview

SVN Access Control 01

Subversion Access Control works as a proxy between Subversion users and the Subversion server. Subversion users connect to Access Control using the standard port 80. Access Control relays user interactions to the Subversion server using port 81. Subversion users never have direct access to Subversion, allowing administrators to keep control over their Subversion repositories.

1.2 Access Control Model

Access Control uses Apache's 'mod_authz_svn' module to apply path-based authorization of Subversion repositories through an authz configuration file. Path-based authorization uses the repository's directory structure as the basis for permitting or denying specified users or groups of users read and or write access to repository files and folders. Through sets of user-created rules, precise control can be applied to what a user can access or overwrite. The limitation of path-based authorization is that once a user is granted permission to access and write to a particular path (directory), it's only possible to limit authorization to a specific file using rules based on regular expressions.

To some extent, running with path-based authorization should therefore dictate how repository files are arranged, ensuring that sensitive material is secured within subdirectories.

tipSpecific permissions overrule inherited permissions.
Access Control tries to match the path itself, and then the parent of the path, then the parent of that, and so on. The net effect is that mentioning a specific path in the access file will always override any permissions inherited from parent directories.

Authz

Subversion's authz (authorization) implementation requires that your group definitions be defined within the authz file. As authz is unaware of Access Control (or any other third-party data stores), Access Control writes all user grouping and user permissions to the authz file. For more information, read our Knowledgebase article, Introduction to Authz.

How we apply rules when authz is not enabled

authz and regular expression based Access Control rules
If you use authz to manage user authorization through Apache you need to be aware that Access Control rules that use regular expressions to define resources are not supported by authz so won't be written to the authz file.

Access Control rules that contain explicit resource paths will apply only to an exact match of the path.

e.g.

With authz enabled,

/svn/repo_1/folder_a/.* RW (applied to all folders and files)

Will be treated as:

/svn/repo_1/folder_a/ RW (applied to all files but not subfolders)

This rule:
"svn/repo_1/folder_a RW"
applies the read/write privilege ONLY to "folder_a" and will not apply to any subfolders. In order for a rule to also apply to subfolders it must use a regular expression to match all the parent folder's contents, e.g.:

/svn/repo_1/folder_a/.* RW
The wildcard .* will ensure that the rule applies to everything within "folder_a".

Important Clarification on how regular expressions are implmented

The implementation of regular expressions works predictably against "write" operations. However, when performing bulk updates, Subversion will only present the top-most path. So the implementation will not prevent "read" operations from returning repository objects that would be blocked if that path in question had been referenced as a top-most path.

Example

If a rule is coded to prevent an account from accessing "/svn/repo_1/trunk/special_path/.*" and the user requests an "svn checkout" of "/svn/repo_1/trunk" then the "/svn/repo_1/trunk/special_path" (and all descendants) will be included in the checkout.

The only currently available mechanism for limiting read access on bulk updates is the use of the authz module, but the use of regular expressions are not supported when authz is used.

1.3 Important Terms

In this guide we'll refer to a number of concepts that you might not have previously encountered. Reading through this list will help ensure that you understand exactly what we mean when we use them:

Authz
The Authz gives you directory-based control over where each user can access. It's an effective means of securing areas of your Subversion repository from unauthorized access or change. Read Setting up Authz
Login ID
The actual Subversion account name that can be successfully authenticated by Subversion or SSH daemon (if using the ext SSH protocol). The Subversion login id is also the primary key for a user in the Access Control user database.
Principal
Principal can be any valid user or group. After authentication, Access Control maps a login id to a set of rules that include the actual user and all its associated groups and sub-groups.
Resource
Resource is a Subversion repository-based file, directory, module or the SVNROOT itself. Resource patterns can be specified as Perl-style regular expressions that are tied to access rules. All directory paths should be specified in the slash-terminated form. For example, specify /a/b/c/, not /a/b/c.

** Alert! **Alert
The use of regular expressions to define access control patterns is not supported if the authz module is enabled.

IP Mask
A Perl-style regular expression specifying the Subversion client's IP address. It is used in Rules that you wish to apply only to a matching client network, subnet or a machine.
member
A user who is associated with an Access Control team.
Team
An collection of Subversion users who are organized into a group based on some arbitrary criteria such as location, type of work, etc.
subteam
A subteam is a team that is created from members of a parent-team.
Permission
Permissions are resource related privileges needed by a user to execute specific Subversion commands. WANdisco Access Control supports these privileges: List, Read, Write, Copy, Delete, Admin
delegated administrator
It is now possible for a system administrator to give a user sufficient permissions to manage the members of a subteam. In large teams of far-flung developers this is a great boon as it can great reduce the workload of senior systems administrators who can have much of the day-to-day user management handled by team leaders and senior developers.
Node
The node is the server on which the WANdisco Access Control proxy software has been installed.
GUID
Globally Unique Identifier. WANdisco Subversion Access Control assigns a GUID to the Access Control node.
prefs.xml
The preferences files contain information on the Access Control. The preference file is located in svn-security/config.

1.4 Key

Throughout this document we'll highlight things using the following types of information box.

** Alert! **Alert
We use alerts to highlight something we think is important for you to know.

tipCaution
The stop symbol is used when we want to caution you against doing something.

tipTip
Tips are principles or practices that you'll benefit from knowing or using.

tipKnowledgebase
The KB symbol indicates that you can find out more about the subject in our online Knowledgebase.

tipuber
Tips that relate using Access Control with WANdisco's ubersvn.

3. Using Access Control

This part of the Access Control Admin Guide will show you how to get started as an Access Control administrator, setting up teams, subteams and Access Rules for your Subversion users.

3.1 Managing Users

This sectio covers how, as an administrator, you manage Subversion users through Access Control. There are three approaches:

3.1.1 Password file control

During installation you choose whether to have Access Control take control of each Subversion repository's password file.

If Access Control is managing the password file:
New users entered into Access Control automatically gain access to Subversion using the same authentication details.

If Access Control is not managing the password file:
New users created in Access Control must also have accounts (with identical details) created in Subversion.

If a user reports of getting an Access Denied message on their client, check they have been regisered on both Access Control AND Subversion.


3.1.2 Updating Subversion Passwords

How user's update their passwords will depend on how you set up 3.1.1 Users can update their passwords from the login screen:

3.2 Creating Users

Use this procedure to manually add new Subversion users to Access Control. To add users en bulk, see 3.2 Importing Users.

3.3 Importing Users

The option is available to bulk import users in a comma delimited file, instead of entering them individually using the Create User screen.

tipCaution importing users to subteams
You can import users straight into teams by including an optional team name field (see the format, below). This will allow you to import to either top level teams or subteams if the subteam has a unique name.

Unique team names are only enforced at the top level and within each parent team. It's therefore possible to have two teams called "QA", so long as they are subteams for different parent teams. Importing a user to "QA" team when there is more than one "QA" team will result in the user being placed unpredictably into one of the teams.

Upgrading Subversion Access Control 4.1 to 4.2

If you are upgrading from 4.1 to 4.2 you will need to convert the access-control.xml file. To do this navigate to the backup folder you created through the System 4.2.9 Export Settings.

Then run perl /opt/svn-security/utils/convertacl41-42.pl access-control.xml. A new file convert-access-control.xml will be created in the same folder. Use this file for the following steps. Please note that running the script from any other folder will not work.


3.4 Creating Teams

Teams are the basic unit of organisation within Access Control. All access policies are applied to teams. TO apply permissions to a single user, you will need to add the user to a team, even if the team is used only for that one user.

tipTeam Names Must Be Globally Unique
All teams must have a unique name within Access Control. It's currently not possible to have two teams with the same name, even if they are located within different directories.

3.5 Working with Rules

Team rules are the business end of the Access Control system, they define how a user who is a member of a team can interact with specific repository resource. A single rule can be useful in itself but the real power of Access Control comes for applying complex policies through a number of rules. The procedure below runs through the creation of a rule, and explains how it's applied.

Access Control applies three rules which define how rules are applied and interact:

No Permission by default: Access Control initially does not allow any user access to any resource. By default, all users are denied. This is essential for security: it closes the window of vulnerability that would allow everyone full access between the time WANdisco is first installed and the time it takes an administrator to create access rules. In order to grant access, the administrator has to explicitly create roles, groups (which define resources) and users.

tipNo associated rules, no access
Newly setup users who report that they're unable to access Subversion may simply not have been assigned sufficient permissions.
Unless you associate access rules to a user either directly or through membership of a team they'll have no repository access.

Parent Directory Inheritance: team members automatically gain membership of subgroups created under their team. As a result they'll get access to all resources available to the subteam. So, access is controlled down the directory tree, while inheritance, goes up the directory tree.

Specific permissions overrule inherited permissions.
Access Control tries to match the path itself, and then the parent of the path, then the parent of that, and so on. The net effect is that mentioning a specific path in the access file will always override any permissions inherited from parent directories.

3.5.1 Understanding Permissions

A user will need to have a certain level of permission on a file before they're able to perform a particular Subversion command. Check the table below to see how Access Control permissions correspond with Subversion Commands:

Subversion Command Permission Required
info Read
log Read
ls Read
status Read
cat Read
diff Read
checkout Read
cleanup Read
update Read
revert Read
annotate Read
propget Read
proplist Read
update Read
commit Write
import Write
add Write
unlock Write
move Write
mkdir Write
copy Read
delete Write


Permission Required = minimum permission needed to execute the corresponding Subversion command.

3.6 Creating Rules

3.7 Creating Subteams

Subteams are teams that have been created under a parent team. The users and repository resources available to a subteam are limited by those that appear in the parent team (which could itself be a subteam). Subteams allow system administrators to delegate responsibility for managing user access for a segment of their repository resources, without having to hand out total control of the repository to subordinates. This is very helpful for organisations working with satellite development sites where managing day-to-day access changes can be made difficult by the distance and time-zone difference between sites.

Subteams Illustrated

How Subteams Work

  • A team can consist of any available users and repository resources.

  • A subteam can only consist of users and repository resources that are available to the parent team.

  • System administrators can recursively create subteams (subteams within subteams witin subteams, etc) to an unlimited extent.

  • The Team Leader of a subteam can only create a subteam if they are given the Create Subteam permission.

  • The delegation of repository resources, through subteams, ca be limited by ensuring that the team leaders are not given the create Subteam permissions, if their team is not suitable for further delegation.

3.8 Testing User Access

A Subversion user environment that requires complex access policies across large numbers of repository resources can require the creation of a lot of team rules. When users belong to multiple teams and have their access controlled by many rules it's possible for a user's access to a particular resource be mistakenly blocked. The Lookup/Search tool lets users identify which rules prevail for a given resource.

3.8.1 Exporting/Importing Access Control Settings

Subversion Access Control Export Settings tool, situated under the System tab is used to backup all of Access Control's settings (although not the Subversion repository data). This includes the users, teams and rules. See Export Settings.

3.9 Access Control Examples

3.10 Using LDAP/Active Directory

What follows is a an example setup of an LDAP group withing Access Control (this should work much the same for connecting to an Active Directory service).

3.11 Setting up SSL encryption

Subversion Access Control can be set up to use SSL encryption. First you should run through the following steps after extracting the Access Control files (but before running setup).

SSLv3 is support (though not enforced). If your browser setting has SSLv3 disabled, you will get a handshake error message. If it has both SSLv3 and TLS enabled, then, depending on the browser, it will try to switch from TLS to SSLv3 during the handshake. If you receive a handshake error message in your browser, make sure that TLS is disabled and only SSLv3 is enabled. All current browsers support SSLv3.

3.11.1 Setting the server key

In the keystore, the server certificate is associate with a key. By default, we look for a key named server to validate the certificate. If you use a key for the server with a different name, enter this in the SSL settings.

3.11.2 SSL Troubleshooting

A complete debug of the SSL logging will be required to diagnose the problems. To capture the debugging, run the java process with:

'-Djavax.net.debug=all' flag.

To enable the logging of SSL implemented layer, turn the logging to FINEST for 'com.wandisco.platform.net' package.

3.11.3 Using SSL for both LDAP and emails

If you're specifying secure email (using a truststore) and LDAP authentication over SSL (using a truststore), the same truststore must be used for both sets of certificates. If different truststores are used then the LDAP truststore will overwrite the email truststore and secure emails will stop working.

4. Admin Console Guide

Welcome to the admin guide for WANdisco's Subversion Access Control. This guide will help you take control and manage the access of your Subversion repositories.

Access Control has a browser-based Admin Console for making user access changes, changing settings or viewing system logs.

Connecting to the Admin Console

Connect to the Admin Console through a web browser, using your server's hostname or IP address, along with the administration port (defaults to 6444).

On connecting you'll be prompted for a login. The default admin username is admin and the password is specified during setup. This section will run through the different screens available in the Admin Console, explaining what they do.

4.0.1 Admin console key

key

The admin console screen consists of the following elements:
Top menu bar: includes the product license and any expiry date, along with links to documentation and support.

Section tabs: The admin consoles different sections are seperated on tabs. They consist of the following sections:

** Alert! **Alert
The layout and features available in admin console alter depending on your license agreement. So you may not see all the elements described in this guide.

Section menu: Appears on the left-hand side and contains links to features that are specific to the tab.

Product version line appears at the bottom of the screen and shows the product version and build, the version of Java installed and the operating system.

4.0.2 Login

On the authentication screen there are a number of links available, even if you don't login.

key

Quick Links

Proxy Status - Proxy Status Displays the node's status in the tab's main panel.
Change User Password - Follow this link to change the password of a User, it's not used for changing the Admin password.

4.1 Security

The security tab handles all user related functionality.

tipTip
The Security tab features product capabilities that are available when the Access Control product has been bundled with Subversion MultiSite. The documentation for using Access Control can be found in the User Guide Section.

4.1.1 Create Team

In Access Control a Team is a group of users who are associated with a resource or collection of resources. Teams underpin how user authorization is managed in Access Control.

key

Name*
A name by which Access Control will refer to the team. A Team name can consist of letters numbers and spaces.

tipTeam Names Must Be Globally Unique
All teams must have a unique name within Access Control. It's currently not possible to have two teams with the same name, even if they are located within different directories.

Description
A description of the team. This can help distinguish the team, possibly referring to the team's purpose or location.
Add Users
Enter usernames into the "Add Users" entry field, will make the user appear. Entering a letter into the field will result in all users whose usernames begin with that character being listed under the entry field.

key

If you prefer, instead of entering the username of each user you wish to add to the team, you can click the Browse button and select from all available users by ticking check boxes. Tick those users that you want in the team, or if you're adding a lot of users it maybe be faster to click Select All then untick users that you don't want to add. When you've finished selecting users, click the Save button.

key

Add Resources
Resources are repository folders. Browse the repository and select a folder, or type in the directory path and click the Add button.

key

Adding a resource to a team doesn't automatically provide the team's members with authorization to access the resource, first Team Rules must be created that will set the specific permissions for selected team members.

4.1.2 List Team

List Teams is the default screen of the Security tab. All teams and subteams are listed, along with the number of users in the team, the number of sub teams and the number of team rules that apply to the team /sub team.

You can view a team by clicking on it's name. You can edit a team's settings by clicking on the Actions drop down and then clicking Edit.

key

4.1.3 View Team

The details of a team can be viewed by clicking on the team's name on the List Teams screen. This will show the team's summary tab which shows the teams details. The summary screen doesn't allow any changes to teh team to be made directly, instead, click on the tab that correspond to the property that you wish to change.

key

Team Leaders
Lists users who have been assigned as Team Leaders to the team. Team Leaders are able to manage the team's settings, adding or removing users, team leaders or repository resources.
key
Add Team Leaders -
Open a dialog box for adding additional team leaders.
key

tipDefault Team Leader Permissions.
When you make a user into a team leader, you enable them to change the team's setup. However, they need to be further assigned specific permissions to Create Users, Create Subteams and Disable users. See the next section for how to enable Team Leader User permissions.

Manage Team Leaders
Open a dialog box for changing team leaders' permissions, or removing team leader status.
key

From the Manage Team Leaders dialog you can remove a user's team leader permissions or enable/disable the following user permissions:
Create Subteam - Enable the team leader to further delegate a team by creating a subteam, assigning users, team leaders and repository resources from those available in the parent team.

Create Users - Enable the team leader to add new user accounts.

Disable Users - Allow the team leader to disable Users. A disabled user will appear within the team's user list, but will be prefixed with a (D). A disabled user will have all SVN permissions removed. It's not possible to selectively disable a user's access, a disabled users will be disabled in all teams.
Team Members
Team Members lists all users who are currently assigned to the team.
key
Create user - Create a new new users that will automatically be added to the team. See Creating Users for information.

Add Team Members - Add an available user to the team. Only users who are present in the parent team can be added.

Manage Team Members - The Manage Team Members dialog contains tabs to Enable Users, Disable Users and Remove Users.

key

Manage LDAP Settings - This option is avaible if you have at least one LDAP server added.
key
Resources
The resources tab lists all repository directories that are associated with the team. Team members do not have access to these resources by defaut; a team leaders or system administrators must first create rules that specify which team members can access the resource, along with a file permission (write access or read-only).
key
The Resources tab has two buttons:
Add Team Resources -
Opens a browse window to the repository file system from where a directory can be selected.
key
Delete Team Resources -
Directories can be removed by clicking on the blue crosses, then confirming the deletion.
key
Rules
The Rules tab shows all existing rules associated with the team. You can view a rule's settings by clicking on the team's name. You can create a new rule by clicking onCreate Team Rule or delete a rule by clicking on Delete Team Rules, then selecting the rules that you wish to delete.
key
Subteams
The Subteams tab lists all subteams that have been created under the current team. The list of subteams will work as a 'tree view', allowing you to toggle the visibility of subteams by clicking on the parent team.
key
It's possible to subdivide teams into smaller 'Subteams', which allows you to delegate areas of team resonsiblities to deputies. A subteam can only consist of users from the parent team, plus whatever resources are available in the parent team. Click Create Sub Team if you would like to delegate some of your users
Create Team Rule
Rules are used to control how team members (either all of them, or a subset) are able to interact with the team's allocated repository resources.

tipDenied by default
In the absense of any team rules, all team members are denied access to all repository resources. This might seem like 'bunker mentality' but it's the only sensible strategy for ensuring that a repository's data is secured against unauthorized access.

Team Setting Tabs
The tabbed side panel lists the team's members, the subteams and the associated Team Rules. It's possible to edit these settings by clicking on the Edit button at the bottom of the main panel.
Edit
Click the Edit button to make changes to the Team. Clicking this button has the same effect as clicking on the Edit Action on the Team List screen.

3.2.2 Edit Team

The Edit Team screen lets you make changes to an existing team.

key

Team Leadership
Teams and subteams can be assigned Team Leaders with delegated authority over the team. Any number of team leaders can be assigned, but they must themselves first be members of the team.

  • Create Sub Team The team leader is able to created a subteam of their team (or subteam). This ability works only within the team, it won't allow the team leader to create a brand new root-level team. Only a user with System Administrator permissions is able to do that.

  • Add User The team leader is able to create additional users to add to the team.

  • Disable Users The Disable Users facility allows a team leader or system administrator to temporarily remove a user's access to Subversion and the Subversion MultiSite admin console.

    tipDisable User is universal
    It's important to realise that Disable Users doesn't currently work on a per team basis, and that a team leader who disables one of their team members will also disable the user in all other teams in which the user belongs.


Repositories / Path / Regular Expression
Add repository resources to the subteam. The available resources are limited to those available in the parent team. Resources are added by entering a path or regular expression (if you're not using Authz) in the entry field. It's possible to use the browse button to navigate through the file structure of the available resources. Click Add to add a resource to the subteam.
Team Settings Tabs
The side panel offers tabs for Users, Team Structure and Rules.
Users
key
  • Add User(s) to Team: Click to open a selection window in which all available users are available to pick. Only users who are members of the parent team will be available.
  • Remove User(s): To remove users, tick their corresponding check box and click the Remove User(s) button.
Team Structure
key
  • Create Sub Team: Click to create a new subteam which will be a child of the currently viewed team (this will also be the top team on the Team Structure list).
Rules
key
  • Click on a team rule to view or edit its settings.

3.2.3 Create Sub Team

The Create Sub Team screen works the same way as the Create Team screen, except that the resulting team can only draw upon the users and resources that appear in its parent team. The parent team is noted at the top of the screen.

key

Sub Team Name*
(Required Field) A name for the subteam.
Sub Team Description
A description to help distinguish the subteam.
Add Users
Type in or browse for users to add to the team. The available users are limited to members of the parent team. If you need to add a user who is unavailable to select, you should first add them to the parent team.
Add Resources
Type in or browse for repository resources or enter a regular expression that will select resources based on the expression's parameters. See limitation concerning the use of regular expressions for this, if Authz is used. Click Add to add the resource to the subteam.

3.2.4 Create Team Rule

Team rules are used to specify what permissions that some or all of the team's users have on some or all of the team's available reponsitory resources. Again, you'll only be able to specify users and resources that are available to the team or subteam.

key

Rule Name*
(Required Field) A name for the rule. Depending on how large and complex your Subversion environment is, it it's possible that you end up with lot of rules. So it's a good idea to give your team rules names that help explain their function.
Users this rule applies to:
Enter or browse for users that this team rule will be applied to. The available users will be limited to the team's members.
Define Resources/Paths/Regular Expressions for this rule:
Enter or browse for repository resources, or type in a regular expression that defines the parameters for resources that should be added, providing that authz is not enabled. The available resources will be limited to those that are included in the team.
IP Addresses this rule applies to:
Enter an IP address or an address pattern defined in a regular expression to appy the rule on the basis of the connecting user's IP address. This feature is useful as it can add an additional check that a logged in user is connected from an authorized computer or network location, but take note that the use of regular expressions in this area is not supported if authz is enabled.

3.3 Create Users

The Create User screen is used to add a new users to the WANdisco MultiSite, which will, providing that MultiSite is managing the Subversion password, also give the user access to Subversion, subject to whatever teams and team rules are applied to the user.

key

Username*
The user's system name.
Password*
A password that the user will use for authentication.
Confirm Password
Re-enter the password to ensure that it was typed in correctly.
First Name
The user's first name.
Last Name
The user's last name.
Email
The user's email address.
System Administrator
The System Administrator check box is only present when a system administrator is creating the user, it will not be available to team leaders who have the permission to add users. Ticking the box will give the new user permissions to use and modify anything in the WANdisco Subversion MultiSite admin console.
Assign User to Team(s)
You can immediately add a new user to an existing team or teams by entering the team name in the entry box.

User View

Use the Edit User screen to modify the user's account details.

Username*
The user's assigned username. This is shown for reference, it's no longer editable. The only way to change a username is to create a new account for the user, then delete old account.
First Name
The user's first name.
Last Name
The user's last name.
Email
user's email addresse.
System Administrator
Check box to enable the use to have full control over the MultiSite admin console.
User Disable
Check box to disable the user's account. When disabled a user is unable to access any resource, through any of the teams of which they are a member. It's not possible to selectively disable a user; if you want to disable a user from a single team (or subset of teams), remove them from the team instead of disabling them.
Team Membership
Lists all the teams of which the user is a member. You can remove them from a team by deleting the team from the list.
Reset User Password
The Rest User Password lets you change a user's password.
New Password
Enter a new password.
Confirm New Password
Re-enter the new password, then click Save to complete the password change.

The user view is available if you click on a username anywhere in the admin console. It lists all the user's details, the teams to which they belong, as well as their System Administrator status, and whether their accoutn is currently disabled. When viewed as a team leader or system administrator, there will also be an Edit button to enable you to make changes to the user's account.

key

Edit User

The Edit screen lets you change of the user's account entries, enable or disable System Administrator permission, disable or re-enable the account.

key

4.1.4 Import Users

It's possible to import users instead of entering them manually through the Create User screen. Use a comma delimited (CSV) format for the import, with the following fields:

<username>,<first name>,<last name>,<email address>,<password>[,<team name>]

key

Click on Choose File and navigate to your import file. When selected click the Import button. A message window will appear, indicating whether the import was successful.

key

tipCaution importing users to subteams
You can import users straight into teams by including an optional team name field (see the format, below). This will allow you to import to either top level teams or subteams if the subteam has a unique name.

Unique team names are only enforced at the top level and within each parent team. It's therefore possible to have two teams called "QA", so long as they are subteams for different parent teams. Importing a user to "QA" team when there is more than one "QA" team will result in the user being placed unpredictably into one of the teams.

4.1.5 Lookup/Search

The Lookup/Search tool lets you test a user's access permissions for a specfied repository resource. For users who are members of multiple teams and to whom numerous team rules are applied, the Lookup/Search greatly simplifies the verification of their access permissions.

key

Username
Enter a username on which to perform a permissions review.
Resource
Enter a repository resource / path for which you want to test the above user's access

Click Lookup to initiate the test. The results are presented as a Read Results and a Write Results. Each result will indicate whether access is granted or denied, and from which rule the permission was granted, and from which team the rule was applied. This is enough information to help you fine-tune permissions without a lot of blind trial-and-error changes.

4.1.6 Create LDAP Authority

It's possible to set up a number of LDAP authorities, if your organisation is runs from more than one LDAP server. Use the Create LDAP Authoritity screen to define your authorities as well as the order in which they are executed.

LDAP Authority

Order: The priority given to the LDAP URL. e.g. A Location Order of 1 means that Access Control will look within that defined authority for a user first. If unsuccessful then Access Control will then check the authority with the next order number (e.g. 2).

Regular Expression: The regular expression offers a means of limiting the number of queries that Access Control attempts when searching for a user accross the available authorities. For example, if you set up an authority whose users have a specific top-level domain in their email addresses, you can use a regular expression to match them to a particular authorities.

URL: the URL for the LDAP authority, using the format

ldap://host:port/dn?attributes?scope?filter?extensions
    [ldap]
    URL scheme name: This is nothing more than a url scheme. It will usually be either 'ldap' or 'ldaps' in the event that you're using SSL for accessing your directory server.
    host
    Hostname: This is the IP address or hostname of your authority's server.
    port
    port This is the port the server is listening on for LDAP/Active Directory communication. eg. 389
    dn?
    Seach Base This is the distinguished name to the path in the directory tree that you want to search for users. e.g. [DC=your,DC=domain]
    attributes:
    [UserName] This is the LDAP attribute that corresponds with the user's login name. This could be their email address or a dedicated account name.
    scope:
    scope This tells the directory server what type of query to perform.
    Filter: [(objectClass=*)]
    This tells the directory server to filter the query for objects matching a particular filter. For more details on constructing an ldap URL, which is a standard and not specific to Apache, view RFC 2255.

Bind User DN: (Optional)
Bind Password: (Optional)
First Name Attribute: (Optional)
Last Name Attribute: (Optional)
Email Address Attribute: (Optional)
Case Insenstive Usernames?: Tick this checkbox if you are using an Active Directory service that has been set up to not recognise character case. You will need Access Control to do the same, otherwise it will treat a username that appears with different case patterns as different users.
System Administrator Group?: Tick this checkbox if the authority will return users who are System Administrators (able to access the MultiSite admin console).

Support for Active Directory Nested Groups

Active directory allows the definition of groups that are themselves members of a parent group. This provides the administrator with a useful organizational structure.

We have a query for that

It is possible to handle Active Directory nested groups using the following query (based on the LDAP_MATCHING_RULE_IN_CHAIN OID). it works as follows:

When we run an ldap query to find all the members of a group, we treat all those members as users.
If a group is returned as a member, we run another query to find out the users that are a member of the included group. ascii example:
sanramon (group synchronized to team in access control)
     +- Jon (user)
     +- Kev (user)
     +- support (group)
          +- Gaz (user)

Looking at the above heirarchy which shows the "San Ramon" (sanramon) team, and set a filter to get all users that are members of the 'sheffield' group. Access control will normally create three users in the team: Jon, Kev and support. What this query does is create three users: Jon, Kev and Gaz (through a recursive search of the 'support' group).

Example Query

The query is :
ldap://10.2.2.45:389/CN=Users,DC=sr,DC=wandisco,DC=com?
sAMAccountname?sub?(memberOf:1.2.840.113556.1.4.1941:=CN=shef_devs_grp,OU=Belfast,DC=sr,DC=wandisco,DC=com)

4.1.7 LDAP Settings

The LDAP settings screen contains all the settings for any LDAP services that you use with Subversion MultiSite. By default, LDAP is not activated. Click on Authenticate using pre-replication LDAP to enable any authorities that you've entered in the LDAP Authorities screen.

El Dapo!

When enabled, all LDAP authorities will be listed, along with the following options:

El Dapo!

Authority Table

Order: LDAP authorities are listed in the order of execution that you set when defining the authorities' properties.
Regular Expression: The regular expression offers a means of limiting the number of queries that Access Control attempts when searching for a user accross the available authorities. For example, if you set up an authority whose users have a specific top-level domain in their email addresses, you can use a regular expression to match them to a particular authorities.

URL: The URL of the authority.
Admin: Authorities that are set to return Admins will show a tick.

Authority Controls


Delete Authorities Select from the list using the checkbox, then click the Delete Authorities button. Using this method to delete multiple authorities in a single action. You can delete a single authority by clicking on its corresponding Actions button and clicking on "Delete".

Admin Guide - Create lookuppass
Note that should you delete the last remaining active LDAP authority you'll see a warning that LDAP authentication will be switched off if you complete the deletion. This is to ensure that you don't get locked out

Test Authorities Use this to verify that Access Control can talk to authority that you select by ticking their corresponding check boxes. On clicking Test Authorities you get a report on the number of authorities to which Accesss Control can successfully connect. Create Authority: To create a new LDAP authority, click the Create Authority button.

Actions: The following, additional actions can be performed on each authority by clicking on the Actions drop-list.

LDAP admin/team polling frequency: The frequency (in minutes) that MultiSite performs a check of the status of the admins / team members. (Default is 5 minutes)

Continue onto next LDAP authority on user not found: Tick to enable MultiSite to run through all available authorities should a user's credentials are not present on the first authority.

Continue onto next LDAP authority on user authentication: Tick to enable MultiSite to run through all available authorities should a user's authentication fail on the first authority.

Use LDAP authorities to authenticate administrators: Tick to enable MultiSite to authenticate its administrators (users who have access to the MultiSite admin console) via LDAP. This will be automatically be ticked and not editable if System Administrator Group? has been ticked in the authority's settings.

Disable non-admin users on removal from last LDAP team: Tick to automatically disable users who no longer belong on any available LDAP authority.

Click SAVE LDAP Settings to save any changes you make on the LDAP Settings screen.

tipRunning with multiple LDAP Authorities
When you enable multiple LDAP authorities, take care that you properly set how SVN MultiSite behalves when handling user logins.

It is possible to set up LDAP in such a way that you'll effectively block access to the SVN Stand-alone Access Control admin console. For example, setting up an additional, lower order, LDAP authority to handle your admin login, but not enable the features:

Continue onto next LDAP authority on user not found
Continue onto next LDAP authority on user authentication failure
- Turning on these options will ensure that SVN Stand-alone Access Control won't reject a login before trying all available authorities.

If you get locked out, use the LDAP reset script to Disable LDAP for Admin Authentication:
i.e.
perl /svn-security/utils/ldapadminrest

4.2 System

The system tab is used to manage system functions such as viewing the Access Control log or importing and exporting user settings.

4.2.1 System

Log Viewer - View Access Controls log file.
SVN Access Control 01

Limiting Log lines

Logs can be generated over multiple lines, which can make reading/performing greps difficult. It's possible to limit each log to a single line by using the following procedure:

  • 1.Set the following line in the svn-replicator/config/log.properties file:
    org.nirala.trace.WandiscoLoggingFileHandler.formatter = org.nirala.trace.SingleLineFormatter
    
  • 2. Replacing any other formatter for this handler.
  • 3. Apply the above change to all nodes.
  • 4. Perform a synchronized stop, then restart all nodes.

4.2.2 Disk Monitor

Set how Access Control monitors disk usage, warning you if the system's available disk space gets too small.
SVN Access Control 01
Use disk monitor: Tick the checkbox to have the disk monitor running.

Interval between checks (in milliseconds): 900000 (15 minutes) is the default interval time between checks.

Determine disk state by: Choose to measure disk usage either by percentage used or bytes free (in bytes, or append KB, MB or GB).

Warn Level: State the level of usage (either as a percentage or bytes free) at which point an alert email will be sent, and resent each time the disk monitor completes a check. So, if you set the Interval between checks to 900000 milliseconds, a warning email will be triggered every 15 minutes.

Critical Level: State the level of usage (either as a percentage or bytes free) at which the node will send an alert email and then shutdown. This will prevent the data on the node from being corrupted.

Click the Save Settings button to save any changes you make.

** Alert! **Alert
You MUST restart the node for any changes you make to take effect.



4.2.3 License Info


SVN Access Control 01

The License Info page contains the details of your WANdisco product license, useful for confirming the details of a number of license-specific features.
Company: Your company name.

Product: The product type. This is currently either svn (Subversion) or (CVS).

License Type: This indicated whether the license is either for evaluation or production.

Access Control:
Shows if Access Control has been enabled on the product.
Number of Allowed Nodes: Number of replicator instances that have been licensed.

Licensed IP Addresses: The IP addresses of each node.

Number of Allowed Users: Total number of possible users that are covered under the license.

License Expires: The date on which the current license will expire.

Maintenance Start Date: The first date covered by the current maintenance contract.

Maintenance End Date: The final date covered by the current maintenance contract.


4.2.4 System Settings

SVN Access Control 01

The system settings screen provides a number of extra controls that allow you to fine-tune Access Control for potential performance improvements.

Enable Access Control Prevayler snapshot:
Tick this option to enable

Run automated backup:
Tick this option to have Access Control automatically run a backup at the end of each day (at midnight). When ticked you can then specify the length of your backup history, which is set at 30 days by default.
To restore Access Control to one of your backup points, use the Import Settings feature.

Enable Audit Trail logging:
Tick this option to record all Subversion activity in the AuditTrail logs. This feature is switched off by default as it creates some additional overhead in transaction processing.

Enable User Access Tracking:
Tick this option to have Access Control save timestamps against each user indicating the last time they interacted with a repository, which can be useful for user management. This feature is switched off by default as it creates some additional overhead in transaction processing.

4.2.5 SSL Settings

SVN Access Control 01

The SSL Settings screen controls all settings related to the keystore and truststore management, used when the secure socket layer protocol is used to encrypt traffic between the replicator and clients.

tipKeystores and Truststores
You might be familiar with the Public-key system that allows two parties to use encryption to keep their communication with each other private (incomprehensible to an intercepting third-party).

The keystore is used to store the public and private keys that are used in this system. However, in isolation, the system remains susceptible to the hijacking of the public key file, where an end user may receive a fake public key and be unaware that it will enable communication with an impostor. Enter Certificate Authorities (CAs). These trusted third parties issue digital certificates that verify that a given public key matches with the expected owner. These digital certificates are kept in the truststore.

An SSL implementation that uses both keystore and truststore files offers a more secure SSL solution.

Use SSL for replication:
Tick the checkbox to enable SSL encryption for Subversion traffic.

Certificate Alias:
The certificate name of the server.

Key Password:
(Optional) password to control access to keys in the KeyStore. All keys in the keystore must have the same password.

KeyStore Filename:
The file in which private keys are stored. Click on the spyglass icon if you need to browse for the file.

KeyStore Password:
Optional password to control access to keys in the KeyStore. All keys in the keystore must have the same password.

TrustStore Filename:
This is the file in which public keys are stored. This can be the same as the KeyStore. Click on the spyglass icon if you need to browse for the file.

TrustStore Password:
Password to control access to the TrustStore.

For more information about running Subversion MultiSite with SSL, see 2.7 Using SSL.

4.2.6 Log Level

Access Control uses one log, and the default level is info. The levels vary from severe, where you get only the most severe warnings, to finest, which logs every action.
SVN Access Control 01

4.2.7 Free Memory

This command frees the memory (GC stands for garbage collection and is only applicable when Access Control is used with the Subversion Multisite.) The command occurs on clicking the Free Memory menu link. The display shows information on the command that was just performed.
SVN Access Control 01

4.2.8 Backup

The backup settings offer basic backup and recovery features

4.2.9 Export Settings

This command allows you to export WANdisco settings, including all user related data, making it available for restoration at a later date..
SVN Access Control 01


The export routine creates a directory containing the files necessary to import user settings back into Access Control. Backup directories use a name string YYYY-MM-DD.HH-MM-SS::XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX ,
e.g. 2012-01-23.16-21-03::2775e033-45b1-11e1-acb4-21d651998aa9

A typical backup directory will look like this:

File properties                                                                
-rw-r--r-- 1 root root 87232 May 30 14:01 access-control.xml
-rw-r--r-- 1 root root   101 May 30 14:01 ExcludeUsersDB.xml
-rw-r--r-- 1 root root   387 May 30 14:01 mailconfig.properties
-rw-r--r-- 1 root root     6 May 30 14:01 MembershipConfigurationRegistry.xml
-rw-r--r-- 1 root root    87 May 30 14:01 NewUsersDB.xml
-rw-r--r-- 1 root root   809 May 30 14:01 NodeRegistry.xml
-rw-r--r-- 1 root root  2440 May 30 14:01 NonResettableDynamicPreferences.xml
-rw-r--r-- 1 root root  2811 May 30 14:01 prefs.xml
-rw-r--r-- 1 root root   162 May 30 14:01 RepoSettings.xml
-rw-r--r-- 1 root root  1162 May 30 14:01 Repos.xml
-rw-r--r-- 1 root root     6 May 30 14:01 ViewRegistry.xml
[root@10-2-5-145 2012-05-30.14-01-50_41e13ec5-a8ab-11e1-a03f-515d761f3659]#              

On a successful export you'll see a confirmation message that verifies the location and name of an export directory.
Admin Console - Export Settings

4.2.10 Import Settings

This command allows you to import WANdisco settings, including all users.
SVN Access Control 01

4.3. Proxy

The Proxy tab handles Access Control proxy settings which alter the way that Access Control works between Subversion and users.

4.3.1 Status

Proxy Status - Displays the node's status in the tab's main panel.
SVN Access Control 01

Click on the change proxy or admin port link to change either the port that Subversion clients will use to connect on, ot the admin port that is used to access the admin console (6444 is the default).

tipuber
When using Access Control with ubersvn, be aware that changing the proxy or admin port will stop the Access Control API from working properly - objects created/linked in uberSVN will stop being carried over into Access Control.

        workaround: After changing the Access Control port (Default:6444), open the file ubersvn/plugins/accesscontrol/uber-plugin.xml and update it to reference the new port number.

SVN Access Control 01

4.3.2 Log Viewer

You can view the logs, including the main log - SVNProxyServer-prefs.log.
SVN Access Control 01

4.3.3 Node

The Node section deals with settings that apply to the server on which you are running Subversion and the Access Control proxy.

4.3.4 SVN Settings

The SVN Settings section contains many crucial settings for how Access Control will interact with your Subversion server.
SVN Access Control 01

Subversion Server Port:
The port on which Subversion is actually running (8080 by default).
SVN Executable
The fully qualified path to the svn executable. On Linux you can run "which svn" to determine the path to the file.
Use authz-based access control?
If you intend to use Apache's authz authorization, tick the check box.
Authorization File:
If you have selected to use authz, enter the path to the authorization file here.

tipAccess Rules when Authz is not enabled
Read how access rules work differently when Apache authz is not enabled - How we apply rules when authz is not enabled

Save Settings
Click to save your settings.
Regenerate Authz File
Should your authz file become Corrupted you can click this button to recreate it using the version stored with the Access Control model.
Regenerate Password File(s)
Should password files become corrupted you can click this button to recreate them using Access Control's database.
Repository List

You can Edit, Delete any of the Subversion repositories that you run behind Access Control - although .

Add Repository: Click to add an additional repositories, either using SVNPath or Parent Path.

Edit Repository

Admin Console - Edit Repository

Click on the Edit link to open the repository's settings screen.

Admin Console - Edit Repository

The edit repository screen lets you modify a number of repository specific settings:

Directory on File System: This is the fully qualified path to the Subversion repository. Not the URL used by clients. You can seach for the location by clicking on the magnifying glass button.

Manage Password File: There are some big benefits to having Access Control manage the Subversion Password file - with this check box ticked, you can add Subversion users by entering their details via the Create Users screen of the admin console.

Password File: Provide a link to the SVN password file on the local file system.

Authentication Realm: Associate an authentication realm with the repository. You should follow the guidance in the Apache documentation for the AuthName Directive.


DAV Location: the directory in which WebDAV is located.

Multiple SVN Repositories: Choose whether you are using SVNParentPath or SVNPath in the Apache location directive.

If you select Yes, SVNParentPath is used in the apache location directive, you'll be presented with a entry box that allows you to select and edit available Root Names.


4.3.5 Email Settings

The email settings screen stores any settings that you have in place SMTP Authentication: If you select No, you'll need to provide your account.
Username and Password in the following entry boxes.
Use SSL/TLS: Choose yes if you wish to send emails over a secure connection.
Host: Enter the address of your mail server.
Port: Enter the SMTP port, 25 by default.
Send Admin Notification To: The email address (You can only specify a single address, not a comma delimited list) to where notifications will be sent.

Email settings are optional. If you don't need alert emails, click Skip to continue. Otherwise, click Next.

Email settings that Access Control uses to send status alerts.
SVN Access Control 01

4.3.6 Stop Proxy

Stops Access Control and prevents client access.
SVN Access Control 01

4.3.7 Shut Down Node

Shuts down Access Control completely.
SVN Access Control 01