TWiki has historically employed two user identities for users; the login name and the wiki name.

Login names are the names provided to the auth system, whatever that is. Once a user is authenticated, their login name is mapped to a wiki name for display and other interactions.

It's an unfortunate fact that several different login names may map to a common wikiname. For example, you might choose to have several users from a single customer, each of whom logs in using their own login identity, but they all map to a single corporate identity (wikiname) for that customer. It would be great for wikinames to be unique, but that's not always possible or even desireable.

So the login name has always been kept around, so that an individual can be uniquely identified. TWiki used to use the login name in logs, in RCS histories, in meta-data, and in a variety of other places. This created some issues where login ids (especially those from windows domains) broke TWiki, because they contain UTF-8 chars, or other characters that it throws a wobbly at.

To solve this ongoing issue I recently recoded the core to make a clear distinction between three types of user id:

• login names - as discussed above, user to log in. Each user is assumed to have only one login id.
• wikiname - used to display a user, generated by the user mapping module. A single wikiname may be mapped to from multiple login ids.
• canonical user ids (UIDs) - a new concept, this is a string that uniquely identifies a user, in the same way as the old user object was able to do. This id has the advantage that it is guaranteed 7-bit ascii, guaranteed unique, and safe to use everywhere in the core.

Further, my code changes have disambiguated users and groups so that there are no assumptions about group names being wiki names, etc. So there is actually a fourth type of id:

• group ids - identify groups

Currently group ids are not mapped to wikinames by the user mapping module, but there's no good reason for that. Note that most of my changes were documentation; the reality is that most TWiki installations will not see any differences (as long as you only use alphanumeric login ids, the UID is just the login name).

So far all this has been internal to the core, and should not be visible to users in any way. However there is one class of user who maybe has to know about it - the plugin author.

The TWiki::Func API is defined to work in terms of wikinames - for example, when you check access permissions, you pass a wikiname to Func. However as pointed out above, wikinames may not be unique. For permissions, where TWiki ACLs are defined in terms of wikinames, this isn't really a problem (though it will become one if we ever want to use an external ACL system). The big problem is that we recently introduced the Func Users features into the API, which allow plugins to do good things like find the members of user groups etc. These methods currently work in terms of wikinames - but it this such a good idea? If you iterate over the members of a group you will only get one wikiname for all the login ids that map to that wikiname.

Taken together these problems suggest that the Func API should focus on the UID as the only reasonable way to identify a user, in the same way as the core does. but I want to hear what other plugin authors think first. We have to settle this before the next release.

BTW in terms of the existing (released) Func API I think the only change that might be required would be the deprecation of checkAccessPermissions in favour of a different interface.

-- Contributors: CrawfordCurrie - 05 Apr 2007

Discussion

I totally fail to understand how you can have a secure TWiki if you allow different people with different logins to have the same wikiname.

All the access control is using wikinames. So if I have a ALLOWTOPICVIEW = JohnSmith I will assume there is only ONE John Smith. OK I may have more than one John Smith in the company but then they need to register with different wikinames (middle initial, nickname, etc).

Otherwise pages that are supposed to be editable or visible to one person suddenly becomes visible to more people. Even worse if we suddenly allow people to register with a non-unique wikiname.

So can you guys please explain how security will work allowing non-unique wikinames?

Changing access rights to using login name instead of wikiname would be very non-compatible and would break everything in existing TWikis.

-- KennethLavrsen - 06 Apr 2007

My initial reaction to this problem was the same as yours. But then Sven made some very good points:

There are 2 alternative root effects that we can strive for.

1. TWiki User names, as displayed (ie the WikiName ) is the most important thing in an organisations identification system.
2. Wiki names are derived from an organisations existing identity and authorisation system.

I posit that 2 is the more reasonable (wrt adoption, and acceptance), and that it is normal in a large enough group to have 2 JohnSmith's both of whom quite reasonably expect to be displayed as JohnSmith.

The other, less social reason, is that for distributed identity and auth systems (OpenID being the most obvious) there is only one guaranteed unique thing - the login-name. All other informations (Firstname, Lastname etc) are set from a non-authoritative, personal perspective.

Same issues exist in bigger corporations.

So, I'm trying to get TWiki into a state where it will be transparently integratable into the existing systems, rather than be 'yet another identity'

To this end, it becomes necessary to not only separate login (the unique thing) from the display, but also from the user's home topic, if they / their admins choose to have one.

If TWiki goes to the less flexible route of insisting that the WikiName is unique, then there are user groups out there that we cannot support - those that want to integrate a TWiki to add to their existing systems (most do not want yet another registration system, nor to manage TWikiUser groups).

-- SvenDowideit - 04 Apr 2007

I'm not inventing anything new here; TWiki has always been able to map multiple logins to a single wikiname.

• No, sir. The traditional user mapping manager which is part of TWiki is TWikiUserMapping.pm, which is relying on a topic like Main.TWikiUsers. TWiki's registration in released versions makes sure that wikinames are unique, and "adding" a new login to an existing wikiname in TWikiUserMapping.pm would simply overwrite the old login name, not create an additional one. TWiki has been able to accomodate alternate user mapping managers, one of them, LdapUserMapping, is available as an extension recently. But like TWikiUserMapping, LdapUserMapping is mapping a wikiname to one single login name in its hash, so any subsequent entry could at best overwrite the old one. -- HaraldJoerg - 06 Apr 2007
• %BLUE* Nevertheless, TWiki has always been able to map multiple logins to a single wikiname. That fact that you cannot register multiple login names to a single wikiname using the registration code does not negate this. An admin can easily edit TWikiUsers and manually add a mapping line for any number of login ids to a single shared wikiname, and the rest of TWiki will happily use it. Oh, and note that LdapUserMapping is actually the module that started all this; Micha was forced to compromise on the implementation to accomodate TWiki's interfaces. I really don't think he would have chosen to implement it that way!

Nothing in the TWiki documentation, or code, requires a 1:1 relationship between login names and wikinames. It was a design choice of many years ago to do access controls and groups using wikinames instead of login ids. Peter is probably the only person who can tell us why that choice was made, but the fact is it doesn't really matter; that's the way it works.

• I can't believe that you can not tell why that choice was made for access control. Login names can be cryptic things like ia005692 or 1239-677824, whereas a wikiname is something can click on, and see with some confidence whether the person at the other end of the link would be the person to whom you'd like to grant access. -- HaraldJoerg - 06 Apr 2007
• As I said, it doesn't matter.

Right now we have already started integrating with external auth resources, and we have already encountered - and only partially solved - the problem of groups that are specified in an external system in terms of login names.

• TWiki supports external auth resources as long as it supports Apache login. What's new is that with LdapContrib it is possible to use external resources for groups. -- HaraldJoerg - 06 Apr 2007
• Right. And we would hope to be able to integrate with other types of access control provider.

Consider the scenario where two users, gbush and gwbush both map to the gestalt wikiname GeorgeBush. The LDAP server specifies presidents as a group that contains the login name gwbush but not gbush. If we were to map that gwbush to a wikiname, then TWiki would see the presidents group as containing GeorgeBush. Unfortunately this would cause TWiki evaluate gbush as also belonging to that group, because he has the same wikiname, and the USA would find itself being governed by an unelected president, god forbid. Since externally provided groups are specified in terms of login names, TWiki has to respect that and also work in terms of login names, and not wikinames.

• This scenario implies that you do not have home topics for your users - another deviation from what is currently documented for TWiki. With the example for LDAP, it is just an indicator of a broken user mapping manager, or a broken LDAP setup. LDAP usually builds groups based on "distinguished names" (DN) and not on logins. If this is an external group - who says that this group shares a common server to login to? -- HaraldJoerg - 06 Apr 2007
• LDAP, yes. Other systems (for example, a large computer manufacturer's single sign-on) build them in terms of login names. It's hard to make assumptions about this, which is why this functionality really needs to be isolated in the user mapping.

In the same way access controls that are specified in terms of wikinames work fine as long as there is a 1:1 mapping between login names and wikinames, but as soon as that becomes an N:1 mapping, big holes appear. Right now no-one is asking to integrate with any system that manages ACLs outside of TWiki, but it's an obvious thing to do and has been requested in the past.

Note that the core already operates exclusively in terms of login names, but this topic relates solely to the TWiki::Func interface which currently operates in terms of wikinames.

• Not in what is released as TWiki 4.0, nor TWiki 4.1. The core operates in terms of user objects, and explicitly shows wikinames as RCS authors (where many login names fail for syntactical reasons) and in the access logs. -- HaraldJoerg - 06 Apr 2007
• Sorry, I didn't mean to imply any released code; I meant the code in subversion

So, here are the choices:

1. We can dictate that wikinames are unique for every login name. If we do this, we need to code mechanisms to maintain this uniqueness.
   • The current TWiki registration process has this mechanism. -- HaraldJoerg - 06 Apr 2007
   • Correct. There is no problem if you are using the TWikiUserMapping. The problem only comes if you are not
2. We can maintain compatibility with old TWiki releases and keep the N:1 mapping. In this case we have to fix the Func interface to support it.

-- CrawfordCurrie - 06 Apr 2007

To make any actual use of the focus on login names - or canonical names - they need sooner or later to pop up at the user interface (for example if you want to grant exclusive access to gbush who is not in any group you know of). This brings all the chaos with characters in login names which have a meaning to TWiki, cryptic login names, organisations changing their login scheme,.... Allowing many people to share their wikiname needs adjustments in TWiki documentation (access control, notification, statistics), but TWiki has made no progress with respect to PluggableDocumentationArchitecture. Sorry, but this is just half-eaten stuff which should be completely confined to the installations running those user managements, with appropriate definitions of the interfaces between TWiki and the extensions.

-- HaraldJoerg - 06 Apr 2007

I still didn't get an answer to how the access rights will work with an N:1 mapping. Today you cannot register on TWiki with two different login names and same wikiname. The code prevents that. It tells you that you are already registered and refuses to register you again. If it did not work that way we might as well ask for another CVE number right away.

If some of you implemented code that allows two login names to have same wikiname for a client then I will not hope that he or his users follows this topic unless you also rewrote the code to use login name instead of wikiname for all access rights.

Today TWiki bases access rights on wikinames and with that fact I cannot see how anyone can implement a secured system that allows two different people with different login names to have same wikiname.

This topic may address a Func thing but the original bug item that this comes from assumes that it is OK with N:1 and I cannot see that this can ever be OK with TWiki using wikinames for access rights.

For reference the bug item the N:1 vs 1:1 discussion comes from is Bugs:Item3838

-- KennethLavrsen - 07 Apr 2007

Harald and Kenneth make some strong points. Let's try and summarise here. Please realise that I am not strongly in one camp or the other; I am trying to facilitate an open and useful discussion on this problem. My fence-sitting is so pronounced that I spent a lot of time refactoring the core code so that it's easy to fall one way or the other with minimal effort.

Harald's key point is that any user mapping engine must be able to make the mapping from a login name to a unique wikiname in order to be able to qualify as a TWiki user mapping. That approach would have several advantages:

1. It keeps the core code simple, as the wikiname can be used as a unique identifier for the user everywhere. We would be able to dump the login name really early on in the process.
2. It keeps the UI simple, as all user interaction is in terms of the wikiname
3. TWiki's existing built-in groups and access control mechanisms work that way, so it follows the principle of least resistance
4. It's easy to document clearly (not to be underestimated!)

On the con side:

1. It forces user mappings to map members of groups defined in terms of single-sign-on entities (login IDs or DNs) back to wikinames. But as this is well isolated in the user mapping module, it shouldn't be a problem. Should groups also be mapped to unique wikinames? Currently they are not.

Right now I can't see any really good argument for N:1. We need a response from the other side of the argument. Sven? Peter?

-- CrawfordCurrie - 07 Apr 2007

I'm still unable to understand why there seems to be a strong desire to shut out some popular forms of user identification from TWiki. The reason that I am pushing the code in this direction is simple: the experience that I gained doing the JoomlaUsersContrib (defines users and groups, which I had hoped to make releasable via this work) the beginnings of the OpenIdUserContrib, work done by Michael on LDAP users and groups, and future UserContribs. For an interesting reality check, see LdapContribDev - Stephane has an example that does not fit cleanly into 'best practice' do you really think its reasonable for us to demand they change their setup so twiki works? CC has also been forced to patch the core to support client SSO systems for the same reasons

The simple reality is that many organisations do not have policies enforcing display name uniqueness over the entire organisation (there are lots of non-unified Windows Domain servers configured to serve only the local division). I am not worried about those that do, as they will be automatically supported by any auth system that is flexible enough to cater for the more complex case.

Harald, as the strongest voice against the code I have, and am trying to write, how many UserContribs do you currently support? And for how many do you have no control over their policy?

As I am constantly trying to get people to understand, WikiName needs to be downgraded to a display artifact related to a user - NOT EVERYONE WANTS USER TOPICS CC clarification: so TWiki should not require them, nor should it require the display name to be a wiki word

Also note, that I have no intention to change the way TWikiUserMapping works, I am trying to expand the range of user, group and auth systems that TWiki is capable of supporting - hopefully we can figure out something wrt the only true issue, how to handle the plugins.

-- SvenDowideit - 07 Apr 2007

from an IRC conversation i just had with Kenneth:

<Lavr> Sven. One the UserIdentifiersInPlugins what I need to understand - maybe more from you than "poor CC" - is how you see access rules working if they are based on wikinames and wikinames are not unique.
<Lavr> What I need to understand is how you intend to solve that issue.
<sven__> the 'usermapper' is responsible for both group and user management
<sven__> when you use TWikiUserMapper, wikinames and group definitions work as they do today
<sven__> no change
<sven__> ie 1:1:1 login:UID:displayname
<sven__> where displayname happens to be a TWikiTopic that we call wikiname today
<sven__> ie, i intend to solve nothing, because its not an issue. its part of the definition of a twiki topics based user mapping
<sven__> the reason for the change, is to make it possible for other user mappers to use their native idioms and constraints, rather than trying to tell your LDAP admin to run it the twiki way
<Lavr> That part I get. But what is then the intended way to use access rights? You would need to use the login name in ALLOWTOPICCHANGE for example?
<sven__> (the N:1 that cc brought up, is because twiki in 4.1 actually does not have 1:1 mapping in the code
<sven__> if you use openid (for eg)
<sven__> then you simply do not have anything else
<sven__> ie, twiki can either let you set it with loginname, UID, or you're totally and utterly ficked
<Lavr> 4.1 has 1:1 with the default mapping given by the registration process. You cannot register two user IDs with same WikiName.
<sven__> yes
<sven__> you can
<sven__> and trust me on this
<sven__> you don't use rego to do it, thats all
<sven__> one of the 'joys of twiki' is that you can subvert any process that we don't enforce at a later stage
<Lavr> OK. Do we agree. A normal user (non-admin) cannot create a user in TWiki with same WikiName as existing user?
<sven__> i'd be willing to say that no-one has looked hard to find an exploit to doit
<sven__> but actually
<sven__> as the mapping is on the TWikiUser topic...
<Lavr> Yes. The whole security today hangs on the access to TWikiUsers.
<sven__> mmm, i guess my dbstore and then dbusermapper and using apache auth_mysql will provide comfort to alot of people
<Lavr> Sven. Maybe if you add to UserIdentifiersInPlugins how the access rights are used. Ie. that with default user mapper and registration process you cannot register twice with same wikiname. And access rights are given by using wikinames. And with alternative user mapping, registration in TWiki is not used at all, and you set access rights using the unique login name instead. Then I think people will feel confortable.

Part of the misunderstanding may be because Crawford and I see that TWikiUserMapper in its 4.1 state, does not enforce 1:1 login:wikiname mapping. This is currently only done at registration time. There is no expectation to do N:1 in TWiki topic based group and user definition.

Going forward though, there is a real need to allow other Usermappers to work out their own requirements with respect to those relationships, and thus how to define access lists, and how Display names get created. The UID becomes necessary for this reason too.

ok, some examples:

• in TWikiuserMapping, we can assume loginname and displayname are unique, and that there is a 1:1 mapping. Thus, we have the luxury of deciding how UID is created. I'd suggest UID == displayname, which happens to be a twiki topic - thus is the WIKINAME we've come to love.
• in some un-named site that uses UNIX auth, the loginnames are unique, but the elements (firstname lastname) that are used to create the displayname are not unique - In this PAMUath case, we may decide that the 100,000 users that have been defined make it undesirable to change the auth system to cater for TWiki, so we use the simple text loginname to derive our UID
• in openID, the only unique thing is login name again (a url to your openid providor), but sadly, a url is a poor contender to use in the RCS log, so we write our mapper to make a UID, and set displayname from whatever the user has set up on their openid (if any)

So, I think the common option becomes clear - topic access definition lists would be made using UID's, where UID's in TWikiUserMapping is just like today. If its possible, we would encourge using a UID that is WikiName like, but uniqueness to the login is rather more important in these examples.

For me, the N:1 thing is a distraction, more important for me, is the need to be able to create usermappings where the displayname is not a twiki topic. For some TWiki's its more appropriate to have a display name like Sven Dowideit , and no topic, and for other's being able to have the display name be a link to the user's web site makes more sense. Forcing all TWiki installations to work like twiki.org simply does not fit all organisations.

-- SvenDowideit - 07 Apr 2007

In the current SVN implementation we still need to uniquely identify users, right? That's what Crawford has been inventing his "canonical user id" for. So what's the problem if this unique, "canonical user id" would simply comply to the specification of a WikiName?

I do not demand it to be FirstnameLastname, if that helps. But I require that this "canonical" name has the following properties:

1. can be used in access control: I consider any approach which would make it impossible to grant or revoke individual access as broken.
2. can be used as RCS author: The RCS author name is used as handle to show authors of previous versions. Just for the records: The current SVN implementation fails to do that for purely numerical logins. I recall a Support topic about that where Cairo failed for such logins.
3. can be used as a link target: If I have to grant access individually, I want a method to identify to whom I will grant access. I require this to be in the form <anystring&gt.WikiName, so that skins distributed with TWiki can be made working by setting appropriate strings in the configuration for UsersWebName.

As I am constantly trying to get people to understand, the WikiName is being documented and used for access control, notification, RCS history, logging, and statistics. Thats more than just a "display artifact".

And finally, I do have concerns with deriving the "canonical user id" from the login name since during the last years I have seen many corporate sites change their login schemes (e.g. from NIS to active directory). If TWiki abandons its own naming scheme based on WikiName, such migrations are painful and lossy.

-- HaraldJoerg - 07 Apr 2007

Harald, from what I can see, nothing about what we're doing will stop you from doing what you want.

All I want, is to be able to do a hell of a lot more than that.

-- SvenDowideit - 07 Apr 2007

and we have no intention of losing the effect of WikiName for TWikiUserMapping. But I need you to recognise that for other twiki's its not appropriate, and so needs to be abstracted - so that they have the choice.

-- SvenDowideit - 07 Apr 2007

OK, the abstraction is in place and I for one don't intend to do any more on this, so discussion closed. Users will be identified in plugins by their wikiname alone, and plugins authors will have to pay the price.

-- CrawfordCurrie - 18 Apr 2007