Introduction to Authentication for Trac

This is a work in progress document - and is written by someone who has been working this stuff out, rather than an expert. Please feel free to add clarifications, corrections and additions

When deploying with on a server such as Apache, Trac relies on any of the server's HTTP authentication methods, such as Basic and Digest. This is not the case for the development server tracd, which is not covered here. Therefore, if you want to get Trac authentication working, you first need to understand how your server and your browser deal with HTTP authentication.

There are 2 basic approaches to Trac authentication:-

1. Restrict access to the whole Trac installation, so that none of the trac pages are visible without authentication.
2. Restrict access such that the Trac installation is visible to someone without authentication, but you can login with Trac.

The following examples are based on an Apache httpd server - further information on authentication on Apache can be found at ​http://httpd.apache.org/docs-2.0/howto/auth.html

They use a password file at /var/www/db/passwd. You can manipulate this file with the htpasswd program or with user_manage as described in ​http://stein.cshl.org/~lstein/user_manage/.

Require Authentication To Access The Entire Trac Installation

This method simply requires HTTP authentication for the root of the site. Nothing can be accessed without authentication.

It has the advantage of being simpler to implement and manage. It also allows you to know that your data is as secure as your web server authentication scheme and that there is a degree of trust in the user information entered on tickets etc.

The disadvantage of this method is that you cannot have a finer control over user permissions (Ex: user abc can view, but not edit location /path/to/location ).

For a trac installation under /var/www/trac, visible as URL http://www.example.com/trac/ you can use an authentication stanza for Apache similar to:-

<Location /trac>
  AuthType Basic
  AuthName "trac"
  AuthUserFile /var/www/db/passwd
  Require valid-user
  ... extra directives to invoke trac
  ... - ie ScriptAlias or mod_python stuff
</Location>

Note that in the current version of Trac, clicking on the logout link above the navigation bar does not logs user out because the browser still remembers the HTTP authentication and keeps sending it.

Optional Authentication For The Trac Installation

This method of authentication allows unauthenticated users to control specific user permissions (view, edit, etc.) for different parts of the site.

In this method, only the /login subpath of each project requires authentication. If users successfully hit this path authenticated, the server returns them a session cookie valid for the project's path, which keeps their section active for the rest of the project.

The /login login subpath can be accessed by users using the Login link on the top menu bar.

The following examples suppose that /trac is the location of your project.

Basic Authentication

To do this you need to control access to the login location under each Trac project, so for the example above you would change the configuration to:-

<Location /trac/login>
  AuthType Basic
  AuthName "trac"
  AuthUserFile /var/www/db/passwd
  Require valid-user
</Location>
<Location /trac>
  ... extra directives to invoke trac
  ... - ie ScriptAlias or mod_python stuff
</Location>

Note that no file or directory named 'login' needs to exist: it is a virtual location managed by Trac's cgi script.

If you have many projects under a single location (Ex: /trac/proj1, /trac/proj2), and you want to use a single passwd file for all of those projects, you could use <LocationMatch ^/trac/[^/]+/login$>...</LocationMatch> instead of Location to set authentication for all the projects at once.

Digest Authentication

To setup digest authentication, follow the instructions to create the digest password file. ​http://httpd.apache.org/docs/2.2/programs/htdigest.html. For the realm set in htdigest you must put a matching AuthName.

For example:

htdigest -c /path/to/.htdigest TracRealmName UserName

 ...WSGI config if using WSGI
 <Location /trac>
   ...mod_python config if using mod_python
   AuthType Digest
   AuthName "TracRealmName"
   AuthDigestDomain /trac
   AuthDigestProvider file
   AuthUserFile /path/to/.htdigest 
   Require valid-user
 </Location>

Don't forget, if you are using Digest with WSGI you must enable authentication passthrough with:

  WSGIPassAuthorization On
  WSGIScriptAlias /trac /path/to/trac/config.wsgi 

Note that optional login requires cookies, and that the chosen authentication schema be active in Apache. (Basic is by default in most installations, digest usually requires changes to http.conf)

Create admin user

Finally, you probably want to give one of your users admin permissions. This allows that user to control many settings from the admin panel. It is accessible from a link on the top of the page, visible only to admin users.

To do so, choose one of the existing users on your passwd file, say the user anadmin, and use:

  trac-admin /path/to/the/trac/project permission add anadmin TRAC_ADMIN

Issues

You really do want your subversion repository to be using the same names as the Trac authentication names so that labelling of changesets matches with names assigned to tickets etc. This means there is a great advantage in using DAV access to the subversion database and sharing the authentication (password) files between Trac and the WebDAV areas (maybe using group access to give a subset of the users access to the subversion database), although this can be done in other ways.

In the authentication methods shown here the password pretty much travels in clear text over the network. You can use Digest authentication to prevent the clear text password going over the network, but this can still be sniffed and subjected to off-line dictionary search attack. If you require greater security then you really should use SSL for encryption, or another means of access control.