= 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 [wiki:TracStandalone 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:- {{{ 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:- {{{ 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 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 ...mod_python config if using mod_python AuthType Digest AuthName "TracRealmName" AuthDigestDomain /trac AuthDigestProvider file AuthUserFile /path/to/.htdigest Require valid-user }}} 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.