Integrating Crowd with Subversion
The Crowd Apache/Subversion Connector will still be available, but will not be supported by Atlassian beyond 31 December 2014.
This page provides guidance on how to use Subversion's authorization module to integrate Crowd and Subversion.
If you were already using the Crowd Apache/Subversion Connector before 31 December 2014 and have been experiencing problems, we recommend switching to use Subversion's authentication module: Alternative setup for existing Crowd Apache/Subversion connector users.
If you have integrated Crowd with Apache you can then use Crowd to password-protect a Subversion repository and provide fine grained access by group or user.
The following features are supported:
- Authentication: Use Crowd to password-protect your Subversion repository.
- Authorization: Provide fine-grained access by group or user.
Step 1. Integrating Crowd with Apache
First you will need to integrate Crowd with Apache. Please follow the instructions on integrating Crowd with Apache.
Note that you do not need to define Subversion as an application in Crowd. Subversion and Apache will both use the same Crowd application.
Step 2. Configuring Crowd Authentication for Subversion
If you are using Apache to manage access to a Subversion repository (instructions) and are using Crowd to manage the Apache authentication (instructions) then you can use the same configuration method to delegate Subversion's user authentication to Crowd.
Example:
<Location /svn>
AuthName "Atlassian Crowd"
AuthType Basic
AuthBasicProvider crowd
CrowdAppName myappname
CrowdAppPassword mypassword
CrowdURL http://localhost:8095/crowd/
CrowdCreateSSO off # Improves performance when using Subversion clients that don't store cookies
DAV svn
# Set this to the path to your repository
SVNPath /var/lib/svn
# The following three lines allow anonymous read, but make
# committers authenticate themselves.
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
</Location>
If your Subversion clients do not store cookies, you will achieve much better performance by disabling single sign-on with the "CrowdCreateSSO off" directive. This will avoid a request being made to Crowd for every single request to Subversion.
You will also need to edit your Apache configuration file to load Subversion's authorization module mod_authz_svn
.
LoadModule authz_svn_module modules/mod_authz_svn.so
Note that you will need to restart Apache before any changes to its configuration files will take effect.
Step 3. Configuring Crowd Authorization for Subversion
To restrict Subversion repository access to certain groups and/or users, you can add the Require group
and Require user
directives, described in the page on integrating Crowd with Apache.
For more fine-grained access, the AuthzSVNAccessFile
directive allows you to define path-based access rules.
Example:
<Location /svn>
AuthName "Atlassian Crowd"
AuthType Basic
AuthBasicProvider crowd
CrowdAppName myappname
CrowdAppPassword mypassword
CrowdURL http://localhost:8095/crowd/
CrowdCreateSSO off # Improves performance when using Subversion clients that don't store cookies
DAV svn
# Set this to the path to your repository
SVNPath /var/lib/svn
AuthzSVNAccessFile /etc/apache2/dav_svn.authz
Require valid-user
</Location>
The AuthzSVNAccessFile
setting lets you define a file where you can configure group and user access at directory level.
Here is a short example:
[groups]
# Groups referred to in other sections must be listed here, but group membership is obtained from Crowd.
bazdevelopers =
foodevelopers =
# Everyone has read access to the repository
# (unless modified below).
[/]
* = r
# Members of the bazdevelopers group can
# read and write to the BazWord project
[/BazWord]
@bazdevelopers = rw
# Members of the foodevelopers group can read and write
# to the FooCalc project
[/FooCalc]
@foodevelopers = rw
# Members of foodevelopers can read the branches
# directory but only user juliag (the release manager)
# can write to this path
[/FooCalc/branches]
juliag = rw
@foodevelopers = r
# peterc is a contractor, so he's denied all access to the statistics
# module (which is full of trade secrets).
[/FooCalc/trunk/statistics]
peterc =
Notes:
- The format is a series of one or more repository paths (minus the leading URL) followed by one or more group or user directives for each path.
- You don't have to include every single path. If an exact path match is not found, the settings for the nearest parent directory are used.
- Access for the user or group can be set to one of:
rw
: read and write access.r
: read-only access.<blank>
: no access.
- Group names are indicated by a leading '
@
' character. - Lines starting with a '
#
' are comments. - If you make use of the SVNParentPath directive to configure multiple repositories, repository paths should be specified in the form
repository:path
, for example:
[groups]
developers =
[public:/]
* = r
@developers = rw
[public:/community]
* = rw
[private:/]
@developers = rw
Mixing Authenticated and Anonymous Access
A common requirement for Subversion access is to have a combination of anonymous access (where a username and password is not required) and authenticated access. For example, many administrators want to allow anonymous users to read certain repository directories, but want only authenticated users to read (or write) more sensitive areas. To enable anonymous access, add the following line to the Apache configuration file:
AuthzSVNAccessFile /etc/apache2/dav_svn.authz
AuthzSVNNoAuthWhenAnonymousAllowed On
Satisfy Any
Require valid-user
When anonymous access is enabled as shown above, Apache will not require a password for any part of the repository that matches the '*' user in the AuthzSVNAccessFile
file. For example, if you wanted to allow anonymous read access to most of a repository but require authentication for a private section, the AuthzSVNAccessFile
file would look like this:
[groups]
developers=
# login not required to read, only members of the 'developers' group can check in changes
[/]
* = r
@developers = rw
# anonymous access denied to /private directory
[/private]
* =
@developers = rw
See also this example in the Subversion documentation.
For a detailed description of the AuthzSVNAccessFile
file format, see the Subversion documentation.
Additional Configuration Options
You may customize your configuration further with some optional commands. See the Subversion documentation for more information.
Step 4. Getting memberships from Crowd
Next you need to take the AuthzSVNAccessFile
file and expand it with memberships from Crowd. This is done with a python script. The script takes your definitions in terms of Crowd groups, expands it out and generates the access-file-expanded.authz
file (containing the list of users and groups from your Crowd instance).
- Download the python script from Bitbucket.
In the Apache
httpd.config
file edit theAuthzSVNAccessFile
setting to point to where theaccess-file-expanded.authz
file will be located (this is the file that will be generated / updated by the script)- Copy your
crowd.properties
file to Apache's Config directory. Create a script with the following:
if generate-authz-svn-access-file.py --config crowd.properties --check-event-token access-file-expanded.authz; then : # Do nothing; file is current else generate-authz-svn-access-file.py --config crowd.properties access-file-template.authz >access-file-expanded.authz.tmp && mv access-file-expanded.authz.tmp access-file-expanded.authz fi
Edit the example above so that the file paths are correct for your environment.
- Run the script and check that the
access-file-expanded.authz
file is updated. - Create a scheduled task, using cron or some alternative, to run the script regularly, for example hourly.
Notes
Note that group memberships specified in the
[groups]
section of the file described in the Subversion documentation are ignored by the Crowd Apache connector, because group memberships come from Crowd. However, any groups referred to in other sections must be named here.Subversion will convert all group names specified in this file to lower case before comparing them to group names supplied by Crowd. For this reason, you must enable the "Lower Case Output" option for your Subversion application.
Alternative setup for existing Crowd Apache/Subversion connector users
The Crowd Apache/Subversion Connector will not be supported by Atlassian beyond 31 December 2014.
If you are experiencing problems with your existing setup, we recommend moving to the following alternative by using Subversion's authentication module to generate a AuthzSVNAccessFile
and populate it with memberships from Crowd.
A python script takes your definitions, in terms of Crowd groups, from the AuthzSVNAccessFile
, expands it out and generates the access-file-expanded.authz
file, containing the list of users and groups from your Crowd instance. You can then automate running this script so that the mapping files used by Subversion are kept up to date.
- Download the python script from Bitbucket
Edit your Apache httpd.conf configuration file to load mod_authz_svn (instead of the Atlassian Crowd Apache Subversion Connector)
LoadModule authz_svn_module modules/mod_authz_svn.so
- In the Apache
httpd.config
file edit theAuthzSVNAccessFile
setting to point to where theaccess-file-expanded.authz
file will be located (this is the file that will be generated / updated by the script) - Copy your
crowd.properties
file to Apache's Config directory. Create a script with the following:
if generate-authz-svn-access-file.py --config crowd.properties --check-event-token access-file-expanded.authz; then : # Do nothing; file is current else generate-authz-svn-access-file.py --config crowd.properties access-file-template.authz >access-file-expanded.authz.tmp && mv access-file-expanded.authz.tmp access-file-expanded.authz fi
Edit the example above so that the file paths are correct for your environment.
- Run the script and check that the
access-file-expanded.authz
file is updated. - Create a scheduled task, using cron or some alternative, to run the script regularly, for example hourly.
RELATED TOPICS
- Using the Application Browser
- Adding an Application
- Configuring the Google Apps Connector
- Mapping a Directory to an Application
- Effective memberships with multiple directories
- Specifying an Application's Address or Hostname
- Testing a User's Login to an Application
- Enforcing Lower-Case Usernames and Groups for an Application
- Managing an Application's Session
- Deleting or Deactivating an Application
- Configuring Caching for an Application
- Overview of SSO
- Configuring Options for an Application