TWiki and Intranet seamless authentication revisited

I would like to once again - perhaps from a more strategic angle - to visit the topic of authentication. I think I've read all there is on the topic in the official documentation as well as in the Support web.

What I would like to achieve is stated in the below requirements. I would guess this is pretty standard for a corporate intranet. My guess is that this is what most TWiki administrators on corporate intranets would like. Simply put this is about getting the buy-in from the endusers.

Requirement #1: Authentication should be seamless, i.e. no prompt for password

This implies single sign-on. The basis here is that on a corporate intranet the user is already authenticated when he logs onto his workstation so requiring him to input that information again when he enters into TWiki is just another way to annoy him and will hurt the buy-in of the TWiki site. Typically this implies that TWiki (or rather the Apache Web Server) needs to authenticate against some corporate user directory, e.g. if on Windows it is Active Directory.

Here is what I think I know on the topic. Please correct me.

There are only two methods that I'm aware of that will solve this.

• NTLM. This works pretty well. In Active Directory it is deprecated in favour of Kerberos but it is still supported and will probably live in the Active Directory product for another 20 years. (there are simply too many applications that depend on it).
• Kerberos. Active Directory support Kerberos but I have not played with it. It looks very complex to configure indeed. Not for the faint of heart I would say.

Many people seem to be using LDAP authentication from within Apache. I haven't played with it but as far as I can tell LDAP authentication in itself will not meet this requirement as it will still prompt for username/password. So LDAP authentication is off the list. (again please correct me)

Requirement #2: A sensible WikiName and TWiki should know the user's email address

On corporate intranets user's login names are typically not very recognisable. They are typically (often for security reasons) made up of something that has nothing to do with the user's real name, such as F2645K. In TWiki it would be much nicer to have sensible WikiName, i.e. JohnDoe rather than F2645K. Have you ever tried one of the tracker applications in TWiki where all your colleagues are named F5786A, P525A3, etc ? Just doesn't work, does it?

Also we would like TWiki to know the user's e-mail address in order to use the many features within the TWiki that take advantage of e-mail.

So what would be the solution to this? I can see two possibilities:

1. Collect this information via LDAP and somehow put it into TWiki. While I think this can be accomplished technically you will still be stuck with the problem of how to build a WikiName from the user's First and Last name in the external user directory. There are two problems with the get-it-from-LDAP-approach: (1) it is not standard functionality in TWiki, i.e. you are own your own and (2) it will collide with Requirement #3 in any case.
2. Use the TWiki registration topic. This is compelling and all users will accept to be prompted for this information once and for all. It also allows users to select a WikiName of their own which is nice. The problem with this method is that actually in a seamless authentication environment TWiki users are never prompted for registration. What we want is of course that they are prompted the first time they try to edit something. There has been made in the past some TWiki hacks on this but who wants to edit the Perl code directly and have it break with every TWiki upgrade? Is there a supported way of forcing users to register? Actually come to think of it we would probably want users to register on first view rather than on first edit. This is because permissioning in TWiki, afaiu, is done on the basis of the WikiName and not the login name. It won't be a perfect solution with the permissioning: You will have to know the user's WikiName and you won't know that before they have registered. Yuck!. This raises the question if permissioning of topics and webs can be done on the basis of login name rather than WikiName?

Requirement #3: We need to work around a non-coorporative AD/LDAP administrator

The thesis here is that the person or persons administrating the Active Directory (or other repository) either cannot or will not help you. TWikis are often used as departemental solutions, rather than corporate-wide solutions, and does therefore not have the power/mandate to make changes to the firm's central user directory.

Authentication methods like LDAP (which anyway fails on Requirement #1) and Kerberos require a special account to be configured in Active Directory with a never expiring password. This account will be used by the queries from the web server. If the corporate user directory administrator is non-coorporative it means you can forget about both LDAP authentication and Kerberos single sign-on.

NTLM passes this requirement without problems. It doesn't require any intervention on the central user directory.

Summary

It seems with these requirements I'm stuck with NTLM for single sign-on. Correct?

I would greatly appreciate if I could get help on :

• Validating the text above. Are my assumptions and conclusions correct?
• Answer to the specific questions raised in the text:
  • Is there a supported way of forcing users to register?
  • Can permissioning of topics and webs be done on the basis of login name rather than WikiName?
• Suggestions

Thx

Environment

-- LarsBruunxHansen - 04 Jul 2007

Answer

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

I can only agree with your requirements, and mostly with your conclusions, too.

On your Requirement #1, you are correct in that LDAP authentication against Active Directory will ask for userid and password. Its main benefit is that your users have the same userid and password as for their other AD based services, so TWiki doesn't need any own password management. For Kerberos, I'd call it complex, but not very complex. The Apache/Kerberos/AD part is well described in the tutorial Using mod_auth_kerb and Windows 2000/2003 as KDC, but there are some additional quirks with TWiki as mod_auth_kerb will return userids as Kerberos principal with a syntax userid@REALM, which TWiki mistakes as mail addresses.

For your Requirement #2, consider the TWiki extension LdapContrib, which allows to query LDAP directories. You can combine your two alternatives by querying LDAP at registration time only, and use the results to populate the fields of TWiki's registration topic.

On your Requirement #3, I found that even with a grass-root TWiki run by one department, my AD administrators have been cooperative enough to grant the Kerberos service account. Maybe I was just lucky, but I think it is worth a try, they might see a benefit in a centralized user management. I could convince them that I manage information for which we've signed a non-disclosure agreement and need to restrict access. If the tutorial I mentioned above doesn't look "official" enough, I found it helpful that the same technique is described in an IBM Redbook titled "Windows-based Single Signon and the EIM Framework on the IBM eServer iSeries Server" Note, however, that if you use LDAP only for user authentication then you do not need a special account. LDAP will still fail on your Requirement #1, and you might need an account to do the LDAP queries to map the login names to personal information.

I am running a TWiki with Kerberos authentication against Windows Active Directory, automatic registration and population of user's topic from LDAP, but this is exactly one of the hacks you might have found in Codev. I had to edit the Perl code, and it broke on every update so eventually I gave up and froze the TWiki version to conserve this functionality.

So to come back to your questions: I think your assumptions and conclusions are correct, and there is no supported way to force users to register. You might be stuck with NTLM. On the other hand, from a pragmatic point of view: If it works, why not stick with it?

I don't know exactly how things will turn out in TWiki 4.2, but things seem to be more centered at the login ID instead of the Wikiname. Maybe there will be a chance to do topic and web access control based on login IDs. I personally would not want this, though, because it makes the access control lists unreadable: who was this IA005692 guy? Or was it an 'Oh' and not a Zero in the third place?

-- HaraldJoerg - 05 Jul 2007

Harald, Thank you for taking time to answer. Appreciated. Amazing that you can live with a situation where your TWiki is frozen at a certain version level. My respect goes to you .. as well as some sympathy.

Why not stick with NTLM it it works you say? Good point and it does work fine. It is not so much the deprecated NTLM that bothers me but more this problem of having a readable user identity, i.e. a WikiName rather than login name. For the access control list I can live with them defined on the basis of login names. In true wiki style 99.99% of the content is open to anyone anyway so access control lists are not frequently edited. I've tried registering one user who's login name is also part of a few of (existing) access control lists. The access controls still worked even after he was given a WikiName which tells me that access control lists are actually on the basis of the login name and not the WikiName. This is good news for me.

However I'm still stuck with the problem of how to force users to register so that they have a nice human readable WikiName.

-- LarsBruunxHansen - 06 Jul 2007

Thanks Lars for your candid feedback.

On forcing registrations, last year I wrote a RedirectRegisterPlugin for a cient which redirects a user to the registration page if the user is not registered when hitting edit, attach, or when visiting an access restricted topic. I asked the client again for permission to release the plugin to the TWikiCommunity.

-- PeterThoeny - 06 Jul 2007

Lars, While I'm currently having a mini holiday, i'm very interested in making the use cases that you and Harald have laid out here possible in the TWiki Core release. It won't be in the 4.2.0 release, as we're feature frozen, but we should work together to get it done soon after that.

Peter's plugin should be a useful start, but then adding the pre-population of user information (i presume) will require a little more fancy footwork - which will also be needed for the OpenID work.

I think we should move this to be a FeatureRequest in Codev

-- SvenDowideit - 08 Jul 2007

Peter's RedirectRegisterPlugin sounds rather similar to RegistrationOnDemandHack, which has been implemented as a login manager. Once the interfaces for login managers are stable and documented, it could be possible to resurrect it, and maybe merge with LdapContrib to auto-register. My own installation based on that hack is not running LdapContrib since it predates this contrib, and needs SASL/GSSAPI to authenticate the web server before it can run queries).

-- HaraldJoerg - 08 Jul 2007

Based on Sven's input I've created a FeatureRequest for this: ForcedRegistration.

-- LarsBruunxHansen - 09 Jul 2007

Set to answered. Follow up in the feature request.

-- CrawfordCurrie - 20 Aug 2007

The RequireRegistrationPlugin covers the RedirectRegisterPlugin functionality I mentioned earlier.

-- PeterThoeny - 24 May 2008