AuthCookieHandlerPluginDev

I am finishing the last touches to the AuthCookieHandlerPlugin.

+++ What it does

Defines an accessHandler for Apache/mod_perl that:

• uses the TWikiAccessControl group definitions to define access rules
• stores access rules to a Mysql database for fast access
• updates the database at topic save time
• uses Apache::AuthCookie to implement a cookie-based session
• log in the database all user actions for later analysis
  • I am planning a SuggestInterestingTopicsPlugin using the SUGGEST idea of Paolo Palmerini

Advantages:

• you can protect whatever file you like (even the pub directory)

See you soon!

-- AndreaSterbini - 24 Sep 2002

Andrea, this is really interesting especially if you have an interface to allow the authentication to be farmed off to another service. We have a strong export-control server that we would like to use alongside classification of webs and topics according to export control rules. I can image an implementation where a topic contains (for example)

• Export control: EAR99

an attempt to access this page triggers the authentication to determine if the logged in user has access to EAR99 documents. If they do, the cookie should record this for the next attempted access.

We also have a security rating scheme that should trigger a specific authentication requirement. For example:

• Security Rating: Confidential Proprietary
• Page Owner: MataHari

an attempt to access the page should refer to an ACL set up by Mata Hari and redirect to a "request for access" page if that person is not on the ACL. If access to the page is permitted by the ACL then this fact should be cookied.

Or something like that, anyway. Whatever it is, it should be extremely lightweight to minimise the page-access overhead - which is usually the big problem with these sorts of schemes.

-- CrawfordCurrie - 25 Sep 2002

Andrea, did you ever release this?

-- MartinCleaver - 30 Jun 2003

I am debugging it.

-- AndreaSterbini - 28 Aug 2003

Andrea, do you have to protect your entire bin/* directory with this plugin? How does it get around the ImproveViewAuthentication related problems, where view can be accessed publically and edit cannot?

That is, I understand that Apache::AuthCookie, providing mod_perl is available, will use the Apache webserver to enforce requiring authentication to access the site. Likewise, in the .htaccess file in bin, the AuthType Basic can be replaced by this authentication scheme. But what happens when a user just views a page? view is not currently protected by Apache's authentication scheme, so I would imagine that, following how Apache works, even if the cookie was present Apache would not continue to define REMOTE_USER. Would it? Does it? How do the semantics for AuthType suddenly change when not using basic authentication?

And regarding using mod_perl, how are you implementing sessions so that they subsequently "forget" plugin information and have to reload it from view to view? In other session-based plugin modules, this was not possible with the current architecture of TWiki. That is, in order for plugins to handle receiving authentication information and setting the user's name, they would have to run WELL before initPlugin ever runs. This means that plugins like SessionPlugin (and later SmartSessionPlugin) had to force their initialization routines (at least for authentication info) to run on LOAD of the plugin, in BEGIN{} sections. The problem with mod_perl is that those initializations would thus only run once. (this applied to things like SpeedyCGI as well)

How does your plugin get around this?

In summary:

• This plugin should require that bin is entirely protected. If it does not, Apache's method of operation is a mystery.
  

  Does your plugin require that all files in bin get protected with it, including view? If it does not, is that because Apache changes how it acts with this authentication scheme? Is it because Apache CONSTANTLY looks for that cookie information even when pages are NOT protected by this authentication scheme? If this is the case, does that mean that someone who is authenticated in folder X under TWiki suddenly sends her authentication information to folder Y which has nothing to do with TWiki, but also happens to have files in it authenticated with AuthSession?

• If this plugin uses mod_perl, TWiki should not have any way to unload and reload it as needed every time a TWiki page is accessed.
  

  How does your plugin manage to use both mod_perl and an authentication engine that sits within a PLUGIN? Does it also require some patches be made to the TWiki core?

Regarding previous requests to farm off authentication to another service, realize that SmartSessionPlugin already provides this. As long as the other service:

• Creates a cookie on successful authentication

• Puts the CGI session variable in CGISESSID and stores session files in a place that TWiki can access (like /tmp) (if the farmed off service just uses CGI::Session, then that makes this extremely easys) (and the variable name and folder info can easily be changed within SmartSessionPlugin as well)

• Stores the user name in a session variable like AUTHUSER (this is configurable)

Then SmartSessionPlugin will provide authentication. As mentioned before, I'm skeptical that SmartSessionPlugin will ever work with mod_perl-type speed-ups, but I'm skeptical that ANY plugin can ever work with TWiki to do authentication in TWiki core code's current state.

-- TedPavlic - 28 Aug 2003

I have read very fast your pages and I hope I am not missing an important point ...

I will have a deep look a both SessionPlugin and SmartSessionPlugins ... I'm very sorry that I did'nt before (the plugin is a back-port taken from a heavily-modified version of TWiki used by FrancoBagnoli at Florence Univ.)

What I am doing is to use THREE handlers for mod_perl:

• the normal Apache::SessionManager as a translation handler to transparently translate URIs containing the session ID (for the case the cookies are not enabled).
• an Athentication handler that recognizes the user/password and stores the user in the session (or redirects to the Login page)
• an Authorization handler that uses the stored username and the DBI database to decide if the pair page/action should be authorized

All the scripts in bin and all the files in pub are protected, including view ...

• if the authentication handler has no credentials then it falls back on the TWikiGuest/guest username/password

PS: the access rules are ready for MultiLevelWikiWebs

-- AndreaSterbini - 29 Aug 2003