Tags:
create new tag
, view all tags
We don't need no Registration
We don't need no View Control
No Wikiname in TWikiUsers
Hey, TWiki, leave us kids alone!
...Leave us kids alone...

Motivation

My problem space

Wikis are wonderful because they allow everybody to participate. Anyone can share his knowledge, or his opinions. There are no hierarchies imposed by the system. Never has it been easier to make a fool of oneself in front of a really big audience.

On the other hand, there are corporate intranets. In many cases run by marketing staff. Authoring is restricted to few Initiated ones, and however cooperative and encouraging they are, it is not the same.

And the abundance of Microsoft Windows has led to many intranets where every user does his initial login against a "Domain Controller". If set up properly, thanks to NTLM and/or kerberos this domain login enables every user to read her mail or authenticate to a Microsoft IIS server without having to enter user id and password again. The domain user id is the user id.

Finally, the fact that authentication for a web server can be done without prompting led to the fact that many intranets are authenticated in the sense that every request receives the domain user id of the reader. Not that it is practically used, but it is there, just in case.

At work, I am living in such an intranet. Which, in addition, has a functional LDAP service. Querying this service allows to get the name, and the mail address, and a couple of other data belonging to the login user id. The real name and the correct mail address for the user id.

And this is an article about helping non-wikians to accept a Wiki more easily by making it closer to what they already know from their intranet.

Now, what has this to do with TWiki?

First of all, I feel in need for a tool which is a bit more than just a Wiki. More in the direction of "workflow", "groupware", "collaboration platform". Of all Wikis I have seen so far, TWiki is one of the most interesting choices because of its rich and very easily extensible functionality. So this article is about how to optimally fit TWiki in our environment.

TWiki, including the current TWiki:Codev.DakarRelease Beta 2, does its utmost to find out whether a request has been authenticated. The login userid, passed by the CGI interface as $ENV{REMOTE_USER} or by CGI.pm as $query->remote_user(), is always recorded and kept. Once set, it is carried over to unauthenticated requests if sessions are enabled. And as soon as you have a login user id, you are no longer TWikiGuest.

If you happen to be registered in TWikiUsers with your logon user id, the WikiName from this list henceforth is your name. This WikiName is used for Access control. If you are not registered, your signature is derived from your login name, and TWiki kindly suggests to register.

What's wrong with this?

The first reason in an environment like ours is: Because it is annoying. People know (well, at least some know) that I can get their name and mail address from the login user id. So why bother the users to enter these information? As a minimal step I should be able to get the values from the corporate directory as defaults into the registration field.

The second reason has to do with Wiki culture. Being able to read without leaving personal traces is one of the sweet spots of WWW, and being able to even write without personal traces has been one of the sweet spots of Wikis (before Wiki spam came up, that is).

Being asked to leave the name and mail address in a generally available page is exactly the opposite. Even in an authenticated intranet only the web administrator can read from the log file of the server who has been using the site.

I'd prefer if every user would be allowed to read as a simple anonymous guest as long as they like, and maybe even experiment with writing pages in the Sandbox web. And I strongly feel that every user should be able to chose whether his name appears on the TWikiUsers list.

How to get there

Strictly separate the login user id from the WikiName

On many TWikis, including http://twiki.org/ itself, the WikiName and the login user id are the same. Yet the TWiki source code (at least in the Dakar release) always considers both of them. A closer inspection will probably reveal that MartinCleaver's work in Dakar brought us pretty far towards this goal. So I think it is not too much effort to make this distinction in the source code a matter of design:

  • A login user id is what has been used to authenticate the user. TWiki should not have any use for it with the exception of string comparison.
  • The WikiName is what is used to determine the role of the user. The syntax of WikiNames is defined by TWiki according to its very own needs. Mainly, the WikiName is used for creating the user's personal page and for access control. Names like "TWikiGuest" and "TWikiRegistrationAgent already carry the notion of a role, as well as the TWikiGroups.

Current usage

  • The login user id is established early in the request, filtered for unwanted characters, and then stored into a TWiki::User object which makes its way into the TWiki::Users object. The original value remains accessible through the $query stored in the session. For an unregistered user, or if $TWiki::cfg{MapUserToWikiName} is false, the wikiname is set to the login user id.

  • The wikiname is used for logging in warnyyyymm.txt, logyyyymm.txt, and as a -w option to RCS. This SMELLs:
    1. Two persons working as TWikiGuest won't collide with their edit leases (note to self: verification needed!)
    2. For security audit purposes, actions must be backtraced to a responsible person. Using wikinames in loggings introduces one more indirection because any log entry must be correlated with the TWikiUsers topic at the same point in time.

  • Related, yet unsorted observations
    1. RCS has restrictions about what it accepts as its -w (pronounced "author") parameter: &lt!-- for example is ok, but @ isn't. This has practical consequences for Apache with mod_auth_kerb, which deliver Kerberos principals (like e.g. achim@GROLMSNET.DE) as $ENV{REMOTE_USER}.

Desired usage

The login user id should never be mangled. Today both the user management and the registration strip "unwanted" characters, and, embarassingly enough, they are doing it in different ways (TWiki::cfg{NameFilter} vs. killing all non-word chars). Apache or other web servers might know authentication schemes which create pretty strange login user ids, and there is no justification to change whatever fits Apache. What if someone invents a clever authentication scheme which allows '<!--' as a valid user id?

The login user id should be used for:

  • table lookup, like in (TWikiUsersDotPm#ObjectMethod_findUser_name_wikin)
  • security logging: to track an action it is necessary to find the person, not the role, whodunnit.
    • I know that this is not really close to Wiki culture. However, it may help to get a buy-in from Your Local IT Authorities (to whom anything Wiki is really suspect) and to enhance confidence of new authors who fear that someone else might steal their ideas or damage their information. We know that Wiki culture works, but many (too many in my opinion) don't.
    • Security reasons make another point for relying on external authentication ($ENV{REMOTE_USER}), if available. If the Local IT Authorities invent some clever authentication method based on palm veins or chipcards, they might be inclined to frown upon applications which still transmit passwords in plain text.
    • The concern about having two user ids (the login user id and the WikiName) doesn't apply here, because the users already have the login user id before they start TWikiing.
  • The WikiName has to be derived from the login user id (if present) or from TWikis own housekeeping (e.g. TWikiGuest).

The Wikiname should be used for:

  • Keeping the user's personal home page
  • As a display variable in signatures, author information on pages, well, on practically anything which TWiki users write or read.
  • For access control. This is, of course, a must since there we need to take care for all the existing access control settings in current TWikis. Can you imagine how often I exclude myself from updating e.g. TWikiAdminGroup because due to my experiments I'm appearing as Just Another User than I expected?

The mapping between WikiNames and login user ids must not necessarily be human-readable. It is just the TWiki code who needs it.

Separate between an TWiki-internal list of all users and the user visible TWikiUsers list

I've found similar thoughts in the Codev web but unfortunately forgot to note the link.... The idea of creating a separate Users web has its charme and is strongly favoured by my imaginary colleague, Mr. Web Preferences.

A related idea are the UserList features (which I had missed until 06 Oct 2005) introduced in Dakar. On first glance they seem to have gotchas which could prevent this solution from replacing the TWikiUsers list:

  • What happens to your installed user base? I doubt that you can automatically upgrade existing registered users into the form based topics.
  • When I had upgraded from Cairo to Dakar, even the new registrations wouldn't appear in the user lists. The reason was pretty simple: I had adapted NewUserTemplate to fit our needs, and UpgradeTwiki was polite enough to keep my version in place.
  • Also no earlier than 06 Oct 2005, I've discovered the LDAP plugin, which does exactly what I intended to hack in (with a much smaller scope, but in less than 20 lines). However, I've yet to figure out how to coerce the plugin's output formatting abilities to produce something which fits the user list form.

I think it would be a good move in the direction of privacy protection if a user has a choice whether we publish that he has been using our TWiki. Even if someone writes some topic in his well-hidden corner of our TWiki he might want to do that unnoticed. Don't force them to adopt Wiki culture - let them learn by themselves from good examples.

Make registration optional

With all that in place, the registration is an optional step, but no longer required: As soon as a user enters a page, TWiki gets his login user id from $ENV{REMOTE_USER}. If this login user id is all new to TWiki:

  • TWiki can obtain the real name and mail address from LDAP. If your corporate directory is set up correctly, then you just know that the mail address is correct before you send the confirmation email.
  • TWiki can do its bookkeeping to map the login user id to the WikiName, be it in the TWikiUsers list or elsewhere.
    • However, I wouldn't do so if a user comes just for reading.
  • TWiki can create a personal home page for the user (like it does today during registration).
    • However, I wouldn't do so if a user comes just for reading, and I can't if I did not do the bookkeeping.
    • I wouldn't even include the user's mail address there, but offer a link to the appropriate LDAP query instead.
    • BTW: I like the idea of locking down personal home pages. Not for technical or wiki-cultural reasons, but for ease of acceptance by non-wikians: It might increase their confidence if they receive their home with the doors closed and the offer to invite whom they want. Don't force them to adopt Wiki culture - let them learn by themselves from good examples. Oh. I've said that already.

It is obvious that the current registration process is by no means superfluous: If you have a TWiki in the internet, or if you don't have the necessary intranet services at hand, then there is no alternative to what's currently in place. And even in a fully functional intranet a user might want to be registered as a user. So at least we need a couple of new configuration options to enable automated registration.

Future ideas

  • If login user id and WikiName are separated: Who says that there's always an 1:1-relation between them? TWikiGuest, for example, should be open for every login user id. I could imagine a situation where a HTTP-authenticated user wants to "log out", if only for testing whether the access control he just put on his topic really works. This would, of course, require that session bookkeeping is in place and overrides the normal $ENV{REMOTE_USER} -> WikiName algorithm.

Appendix

References

-- HaraldJoerg - 06 Oct 2005

Harald, your assessment and needs appear to closely mirror my own. On our intranet I want version control tied to individual authors. I don't care if they have home pages or personal preferences, and judging from those that make pref changes my users don't either. So, for us, we don't need registration, we rarely need authorisation and we don't need authentication (inside of twiki). All that is already taken care of in the environment (a Windows Active Directory domain). We don't even need login names converted WikiNames (though it would be nice to click jhsmith and see the ldap info). It is sufficient to know that jhsmith was the author of rev1.14 and that she corrected some typos and added the latest minutes.

-- MattWilkie - 11 Jan 2006

In our corporate intranet, I got this setup running based on RegistrationOnDemandHack. Viewing the pages is authenticated transparently (i.e. without asking for userid and password). Registration is done automatically, but only if someone actually edits something. The automatic registration creates a WikiName from the Windows userid with a (currently hardcoded) LDAP query. The user home page is drastically reduced since there is no point in collecting data there which are readily available from our corporate LDAP. Moreover, the colleagues are accustomed to look for personal details in the corporate LDAP, and not in my TWiki. I'd guess that the patch in RegistrationOnDemandHack won't work with the current Dakar SVN releases - I'm running something Beta-3-ish.
I plan to rebase RegistrationOnDemandHack when Dakar is released.

-- HaraldJoerg - 12 Jan 2006

InterfacingToExternalAccessControlListManagers

-- AndyGlew - 14 Apr 2006

CategoryFightTheFlab

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r5 - 2006-04-14 - AndyGlew
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.