TWikiAuthenticationMethods

Migrated from CommonFrontEndCgiScript: I'd like to investigate various methods that could be integrated into TWiki as a plugin or TWikiService to implement password management and authentication.

Related Topics: HtPasswordCodeDuplication, CommonFrontEndCgiScript, TWikiOO

This sub-discussion started in CommonFrontEndCgiScript as a result of the desire to consolidate all of TWiki's CGI scripts into the core code as TWikiServices, and call them from a single front-end script. For sites desiring password authentication for only part of TWiki's functionality (edit or attach, for example), the possibility of using the web server's built-in authentication methods becomes difficult on many platforms, especially if the administrator does not have permission on their server to edit the web server's configuration file to implement URL-based authentication. This is due to the fact that the .htaccess file can restrict access only on a script-by-script basis (using <Files> tags) The administrator is forced to migrate from these rules:

AuthUserFile /filepath/to/TWiki/data/.htpasswd
AuthName ByPassword
AuthType Basic
SetHandler cgi-script
ErrorDocument 401 /urlpath/to/TWiki/bin/oops/TWiki/TWikiRegistration?template=oopsauth
    <Files "edit">
       require valid-user
    </Files>

    <Files "preview">
       require valid-user
    </Files>

to these rules, for a CommonFrontEndCgiScript called twiki:

AuthUserFile /filepath/to/TWiki/data/.htpasswd
AuthName ByPassword
AuthType Basic
SetHandler cgi-script
ErrorDocument 401 /urlpath/to/TWiki/bin/oops/TWiki/TWikiRegistration?template=oopsauth
    <Files "twiki">
       require valid-user
    </Files>

which requires the administrator to authenticate for all TWiki activity.

If the administrator does not wish to force the user to authenticate for all activity via this CommonFrontEndCgiScript, it is necessary to come up with a way to do authentication based on what activity the user is involved in, managed within TWiki via CGI and Cookies.

There are currently several useful modules on CPAN which can be used to implement a CGI-based authentication front-end to TWiki

• Authen-Challenge-Basic: MD5-based authentication
• Authen-Smb-0.91: NT/Smb authentication
• perl-ldap-0.25: LDAP authentication and database access

There is also code embedded in various TWiki cgi scripts used for managing password information:

• installpasswd: Script to allow the TWikiAdminGroup to install new passwords for users.
• passwd: Script which allows the user to reset their password.
• register: Registration script, which creates new user's home topic, password entry, etc.

This code should be centralized in an htpassword management module (See HtPasswordCodeDuplication).

In cases where LDAP or some other remote authentication method is in use, the htpassword management facilities aren't of much use; password management is usually handled by a pre-existing company-issue system.

Currently there is an AccessDotPm module which is used to check that a user belongs to a specific TWiki group (See TWikiAccessControl). This module could be extended to provide pluggable authentication services in a way similar to the StoreDotPm module's current (see current CVS version) back-end implementation.

Authentication for an htpasswd based system via CGI is likely to involve the following steps:

1. User requests a topic for activity edit
2. TWiki CGI script notices the user requests an edit
3. CGI script checks for a set cookie
   • cookie is set, password matches, we move on to the edit activity
   • cookie is set, password doesn't match, we redirect to the same CGI script, with the same CGI arguments, but with the addition of an authentication request parameter.
   • cookie is not set, we redirect as above.
4. Authentication has been requested, so CGI script generates a TWiki login form via the AccessDotPm module.
5. User submits TWiki Login form
6. CGI script checks data against htpassword database.
   • password matches, we go on to the edit activity with reinstated CGI parameters after setting the password cookie.
   • password doesn't match, we go back to step 4, unless this is the 3rd try, then we call security

This same use case could be applied to other forms of authentication, except the process of checking passwords would be relegated to one of several pluggable authentication handlers.

The implementation of an integrated authentication service like this would have to coincide with the development of the CommonFrontEndCgiScript implementation. We can start with basic MD5 authentication and move up from there, once most of the architectural work is done, and object interfaces are defined.

-- PeterNixon - 11 Jul 2002

Thought a little more about this, and I could do an exploratory implementation of this in the current TWiki codebase; Cookies are sent from the browser based on the URL path, so I could set it up to send the password cookie for any paths beginning with http://servername/twiki/bin. I could implement this as a standard TWiki plugin which could do the access checking and redirection during it's initialization sequence. (same as SessionPlugin, with more facilities)

-- PeterNixon - 12 Jul 2002

How about, scripts that need authentication redirect to the authenticate script giving parameters of what they should do once that is successful.

i.e.:

1. request for bin/edit&topic=TWiki.WebHome
   1. no cookie info, redirect to bin/authenticate?returnto=edit&topic=TWiki.WebHome
2. authenticate script called
   1. if fail, bail out
   2. if not, find out where to go next, i.e. redirect back to bin/edit&topic=TWiki.WebHome

-- MartinCleaver - 13 Jul 2002

Yep, that was the intent, but it probably got muddied up there somewhere...

... we redirect to the same CGI script, with the same CGI arguments, but with the addition of an authentication request parameter.

But I think you may have summarized it a little better.

I still feel that when we finally do have a CommonFrontEndCgiScript, there will not be a need for a separate authentication script, as authentication will be just one of the many activities it will support.

-- PeterNixon - 12 Jul 2002

I am working on a AuthCookieHandlerPluginDev ... perhaps it could be a start.

-- AndreaSterbini - 24 Sep 2002

I use a modified version of the SessionPlugin to manage authentication cookies. We have a corporate LDAP server that lets us translate from an X.500 login name to a wiki name, which we then cookie. You're welcome to the code if you are interested.

-- CrawfordCurrie - 25 Sep 2002

See also ImproveViewAuthentication

-- MartinCleaver - 30 Jun 2003

Transferred to Bugs:WebHome. As of Dakar release TWiki will have APIs for pluggable authentication and login, and pluggable registration is on the way.

-- CrawfordCurrie - 11 Jan 2006