= Introduction to Authentication for Trac
{{{#!box note
This is a work in progress document, 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 on a server such as Apache, Trac relies on any of the server's HTTP authentication methods, such as Basic and Digest. 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 in the [https://httpd.apache.org/docs/2.4/howto/auth.html Apache Auth documentation].
They use a password file at `/var/www/db/passwd`. You can manipulate this file with the [https://httpd.apache.org/docs/current/programs/htpasswd.html htpasswd].
== Require Authentication To Access The Entire Trac Installation
This method simply requires HTTP authentication for the root of the site. Nothing on the site 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 anonymous access, typically with view-only permissions, is not allowed.
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:
{{{#!apache
AuthType Basic
AuthName "trac"
AuthUserFile /var/www/db/passwd
Require valid-user
# ... extra directives to invoke trac
# ... - ie ScriptAlias or mod_python stuff
}}}
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 session 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:
{{{#!apache
AuthType Basic
AuthName "trac"
AuthUserFile /var/www/db/passwd
Require valid-user
# ... extra directives to invoke trac
# ... - ie ScriptAlias or mod_python stuff
}}}
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 `...` instead of `Location` to set authentication for all the projects at once.
=== Digest Authentication
To setup digest authentication, follow [https://httpd.apache.org/docs/2.2/programs/htdigest.html the instructions] to create the digest password file. For the '''realm''' set in htdigest you must put a matching !AuthName.
For example:
{{{#!sh
$ htdigest -c /path/to/.htdigest TracRealmName UserName
}}}
Sample configuration:
{{{#!apache
# ... WSGI config if using WSGI
# ...mod_python config if using mod_python
AuthType Digest
AuthName "TracRealmName"
AuthDigestDomain /trac
AuthDigestProvider file
AuthUserFile /path/to/.htdigest
Require valid-user
}}}
If you are using Digest with WSGI you must enable authentication passthrough with:
{{{#!apache
WSGIPassAuthorization On
WSGIScriptAlias /trac /path/to/trac/config.wsgi
}}}
Note that optional login requires cookies and that the chosen authentication schema is active in Apache. Basic is the 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 to maintain control over the settings in the admin panel. It is accessible from the Admin link in the navigation bar 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:
{{{#!sh
$ 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 labeling 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 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.