Customizing Backtalk Authentication

Version 1.1.7

© 1996-2001 Jan Wolter, Steve Weiss

This document is so incomplete that you might as well pretend it doesn't exist at all yet. We hope to fill it out more in future releases.

Backtalk is an advanced web-based computer conferencing system written and distributed by Jan Wolter and Steve Weiss. For general information about Backtalk, see the Backtalk home page. This document describes methods for customizing Backtalk's authentication system.

It is common for administrators to want to integrate a conferencing system like Backtalk with web-based applications that might be running on their site. They may already have some sort of database with user names and passwords, and they may want those logins and passwords to work with Backtalk as well.

Backtalk can be configured to use a large variety of different databases and techniques for authentication simply by using different options on the configure command. These are described in the installation manual. These cover a wide range of options, and may suffice to integrate Backtalk with many pre-existing authentication databases. However, in many cases some customization the Backtalk will be required.

Starting with release 1.1.7, we have made a concerted effort to modularize the Backtalk authentication system to make it simple to add new authenication options or customize existing ones. In general this will still require at least a modest amount of programming. The beginings of a flexible SQL interface has also been added which should eventually make it possible to integrate Backtalk with just about any SQL database without doing much programming.

All of this is still at a somewhat immature stage. It will continue to improve with time.

User Databases

Conceptually, user information in Backtalk is divided over several databases. In some configurations they may not all really be separate, but it is useful to think of them as such. Backtalk has built in support for multiple different implementations of most of these. We'll compare them to the Unix equivalents, just to give a clearer idea of what each database is. In most cases, actually using the Unix database is one possible (though unusual) option.

There are some databases that are not yet in modules, but which will probably be in future releases. These include users' settings (corresponding to the Unix .plan file and other "dot files" normally kept in the home directory), and user's participation files, which record which portions of the conferences they have read. It'll probably be a lot longer before the actual conference data is modularized.

User's which to share user information between Backtalk and another program will need to decide which databases they actually want to share. The authentication database is a must. The identity database is generally nice to share, so a person doesn't have to change their full name in two different places if they get married and take their wife's last name. Since you will not want to have multiple account creation tools, there would be little use in sharing the next uid database. The group database may be useful. The session database would normally be nice to share (if you are using it at all) so that people can move between different parts of the system without having to re-login.

Sharing Authentication and Session Databases

We'll start with a discussion of the most important of the shared databases: the authentication database. This is influenced significantly by the type of authentication system you are using. For lots of information on this, see Jan Wolter's Guide to Web Authentication.

Basic Authentication Systems

Basic authentication is a user login system that is built into virtually all browsers and http servers. Typically the user will see a pop up box appear with a login/password prompt when he tries to access a secure area. Actual authentication will be done by the HTTP server, not by CGI programs like Backtalk. With Apache, the authentication will be handled by some standard authentication module, like mod_auth, mod_auth_dbm or mod_auth_db, or by some similar third party module, like mod_auth_external, mod_auth_pam or any of zillions of similar things.

Generally, in such configurations, the format of the authentication database will be dictated by the HTTP daemon's authentication module, which must be able to read it to do authentication. Backtalk fully supports the formats used by mod_auth, mod_auth_dbm and mod_auth_db as well as a combination of mod_auth_external and pwauth that authenticates out of a Unix password file.

Note that with basic authentication, the user's browser remembers his login and password and resends them with every request. So every page must be able to check authentications, and thus must be able to read the authentication database. Thus if want user to be able to access two applications both running basic authentication then they need to share an authentication database.

Luckily, this is probably easy, because the actual authentication checking is done by the HTTP server. So you just have to use the same authentication module pointing to the same authentication database, and everything will be peachy. You'll need some administration and account creation tools that work with the database, but very likely either those from Backtalk or from the other application will do just fine.

Sharing session databases in basic authentication systems is even easier, since there aren't any.

Form-Based Authentication Systems

Basic authentication systems have an often shabby looking pop-up box, and do not allow a user to logout without exiting all browser windows, so sites seeking a professional look and feel often avoid them, prefering some form of form-based authentication.

In these systems, the user find a login and password box in a form on the main browser window. When he submits his login info it is passed to the CGI program, which checks that the password is correct, and gives access to the next page only if it was. To avoid forcing the user to login again for every new page their after, the CGI sends back to the browser not only the page, but some form of certificate that will be automatically resubmitted to the browser with each future request. Normally it will either be contained in a cookie, or will be passed from page to page as a CGI argument. In the simplest case the certificate could just be the user's login and password, but that has obvious security problems. Most commonly the certificate is simply a random string of characters called a session ID. The CGI maintains a database that tells which user each session ID was issued to, so that when a session ID comes back, it can easily identify the user. Session IDs usually expire after a short time of not being used. Logging out is handled by invalidating the session ID.

Note that such systems typically have only one page that actually checks logins and passwords and thus only one page needs to have access to the authentication database. This can be handled by either Backtalk or the other application, whichever is handy, so the authentication database does not have to be shared. Obviously, whichever application is handling logins should also be handling account creation and administration.

However, all secure pages will need to check the session database, so that must be shared between applications. This is going to be a bit more of a challenge to accomplish than sharing the authentication database under basic authentication was. In that case the HTTP server imposes some regularity on the database formats, while in this case an application could use any database format you'd care to imagine, and the odds that one program will be able to read the other's database are low.

Another issue is the passing of the session IDs. Backtalk currently supports only the cookie option. If your other application passes it as a CGI variable, this is a problem that probably isn't very hard to solve but that we haven't addressed yet.