Deja Vu?

This article is about using TWiki in an intranet, where users are required to authenticate for intranet access - be it TWiki or anything else.

I know that this has been discussed several times, nevertheless I'd like to bring it up once more. I have been motivated to start this by recent bug reports from TWiki:Main.PeterThoeny (e.g. Bugs:Item594) in which he referred to TWikiMission, and after having re-read TransparentAuthentication, NoIntranetUserLogon and a couple of articles referenced therein.

Not only did (and does - Dakar is lurking) TWiki change over time. Many corporate intranets have made progress as well: Intranets today are "portals", support single sign on, have LDAP services at hand, etc. Compared to that TransparentAuthentication etc. look a bit stale.

I would guess - and I'd like to hear your opinions - that today one of the most critical question for TWiki deployment in an intranet is:

• How does it fit into our <insert your favourite portal software here>?

TWikiTemplates and TWikiSkins are a big help for page layout, and the plugins add almost everything you could possibly need in functionality. However, in my opinion some things around TWikiRegistration and TWikiUserAuthentication still have to catch on. Before I start hacking my own TWiki installation, I'd like to know how common our "corporate intranet setup" is:

• We authenticate against a central server (Windows Domain Controller)
• The Intranet Portal is authenticated with the same user ids. With Internet Explorer you won't even notice that you are authenticated.
• Using LDAP I can query the users' names and mail addresses given their login name
• Apache serves can be integrated into the Single-Sign-On comfort with mod_auth_kerb, however this gives login names which cause trouble in TWiki (Kerberos principals containing '@', e.g. mchhjoer@FSCPLEASENOSPAM.NET). Note how TWiki is "helpful" by adding "STOPSPAM" here?

Does that sound familiar?

Currently I am browsing through the TWiki documentation - and sources - to investigate how to make most out of TWiki in such an environment. Pointers, ideas, different requirements are welcome!

-- HaraldJoerg - 06 Oct 2005

We use Kerberos (PubCookie) for authentication and use the LoginNameAliasesPlugin to munge login names to remove characters we don't want. One thing I've considered is modifying this plugin to do autoregistration in an environment such as yours (i.e. if a user isn't already registered, lookup their full name, create a WikiName for them and register them).

-- ClaussStrauch - 06 Oct 2005

Take a look at the SiteMinderPlugin. I think I implemented exactly that there.

-- MartinCleaver - 06 Oct 2005

SiteMinderPlugin is obsolete now.

-- AndrewBanks - 02 Jun 2006

I admit ClaussStrauch's idea of autoregistration is pretty much what I had in mind. I have prepared a separate article about that which isn't really finished, but since we are getting in the discussion pretty fast, I'll upload it: HowToAvoidRegistration

And I had a look at Martin's SiteMinderPlugin (which I hadn't discovered before). From its effects it looks pretty similar to LoginNameAliasesPlugin - restricted to SiteMinder but delivering the necessary mapping from login user ids to WikiNames.

After what I've read in recent days on TWiki, I think that the whole authentication and registering docs on TWiki.org are in severe need of merciless refactoring....

-- HaraldJoerg - 06 Oct 2005

-- HaraldJoerg - 09 Oct 2005

PLEASE NOTE: Authentication is not the same thing as Authorization. All that Harald has written about assumes an intranet context where the user are already set up, that is they have been authorized to use the network facilities.

ALSO:
"Transparent Authentication" could mean other things. It could mean an Internet site where the logon mechanim transparently requests a X.509 certificate from the user's computer or transparently requests the user's computer for some biometric information.

At the moment we already have a form of "transparent authentication" using session management and cookies. If you set your browser up so that cookies are not discarded at the end of the session you can re-visit a TWiki site that uses SessionPlugin until the cookie expires and you will be .... transparently authenticated.

-- AntonAylward - 10 Oct 2005

Anton - thanks for your remark. I agree that having a clear terminology helps to understand things, and then to get design and implementation right.

As you write, I have been writing about an intranet context, and I added a sentence to the top of the page to make that clear. To be precise, I have been writing about an intranet where $ENV{REMOTE_USER} is always set.

In my opinion, TWiki should be able to cope with:

1. Intranets and internets without own authentication - leaving TWiki alone with the task. The TemplateLogin and ApacheLogin managers are currently taking care for that. New login managers could do about anything imaginable from within TWiki, and they might - or might not - use passwords.
2. Intranets and internets where the web server already has taken care for authentication and makes this visible through $ENV{REMOTE_USER}. In this case TWiki may choose to simply trust the server. Then it doesn't need to care how the user did authenticate, and it may be totally impossible for TWiki to do anything like "password management".

I am fully aware about the difference between authentication and authorization, and I realize that in both these cases TWiki - and only TWiki - has to take care for the authorization to use TWiki resources. I am heading towards a design where authentication is based on login names and authorization is based on wikinames, and TWiki takes care for the mapping between these two in all environments. Currently it fails to do so if $ENV{REMOTE_USER} is set: TWiki regards the session as 'authenticated' and does not take proper care about whether the user is authorized to do anything more than TWikiGuest.

This is a point where many current issues touch. Item594 , and even Item593, now moved to RemoveWriteProtectionOfUserHomePages, RegisterCgiScriptRewrite and RegistrationAsPlugin, just to name a few.

I fully understand the points you have made in Item594 regarding the need to customize the registration process. I indeed have the same desire, though from the opposite direction: You want more registration before you grant authorization to use your TWiki internet, I want less registration because I want to fully rely on the intranet portal setup.

I hope we manage to separate TWiki's needs (in my opinion boil down to loginname, wikiname and mail address) from the needs of a TWiki site administration, which should be fully customizable.

Well. Again. More an article than a comment. Sorry.

-- HaraldJoerg - 10 Oct 2005

More an article than a comment No Don't appologise.

I realise that you do understand the difference between authentication and authorization. However its clear from the comments here and in BUGS that some develoeprs don't, and don't even see the set of conditions that we are discussing here. They talk of the registration process as "authentication". While I can see that a registrant is 'claiming to be' an identity, the misuse of the term means that its not differentiated from the log on "authentication" and fails to recognise that there is a process - explicit or implicit/hidden for authorizing use of resorces.

Even the policy decision "anyone can edit anything" of the classical early Cunningham approach is an authorization decision.

The plugins for login (currently TemplateLogin and ApacheLogin but potentially more) are a powerful facility. I'm working on ideas for extending this to registration.

-- AntonAylward - 10 Oct 2005