|Version 6 (modified by 10 years ago) ( diff ),|
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|
The basic idea is that Trac itself does not do authentication (other than for tracd which I don't intend to cover here). Authentication is done by the http daemon environment, and the authentication information passed to trac when it is invoked by the httpd.
There are 2 basic approaches to Trac authentication:-
- Restrict access to the whole Trac installation, so that none of the trac pages are visible without authentication.
- 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 will need to manipulate this with the
htpasswd program or you could look at http://stein.cshl.org/~lstein/user_manage/
As an alternative you could drop in digest authentication - the Apache documentation describes this.
Require Authentication To Access The Trac Installation
This is the simplest method in both concept and implementation. 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.
For a trac installation under
/var/www/trac, visible as URL
http://www.example.com/trac/ you can use an authenticaton 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, you will still see the logout link above the navigation bar, even though the link will not work (i.e. do nothing).
Optional Authentication For The Trac Installation
This method of authentication allows unauthenticated users to see and to make (limited) changes to the Trac system. Authenticated users have a bit more access. To login you click on the Login entry on the top menubar; after authentication you are given a cookie which is used for authorization and access control.
To do this you need to control access to the
login name under the Trac system, so for the example above you would change the configuration to:-
<Location /trac> ... extra directives to invoke trac ... - ie ScriptAlias or mod_python stuff </Location> <Location /trac/login> AuthType Basic AuthName "trac" AuthUserFile /var/www/db/passwd Require valid-user </Location>
To setup digest authentication follow the instructions to create the digest password file. http://httpd.apache.org/docs/2.1/programs/htdigest.html. For the realm set in htdigest you must put a matching AuthName.
...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)
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.