Item5470: Case-sensitive login name in LdapContrib causes Bad Wikiname

Issues concerning case-sensitivity and wikiname generation using LdapContrib

The following issues seem to be related, and are negatively affecting authorization. We are running TWiki v4.2.0 with LdapContrib, LdapNgPlugin, NewUserPlugin, and others.

1. Case-sensitive login name in TWiki, not in LDAP

A single user can have numerous topics for his/her name, based on the case variation within a login name.

For example, Mickey Mouse (givenName=MICKEY; sn=MOUSE) is a user. His loginName is mickey.mouse. Mickey's login name (mickey.mouse) is NOT case sensitive. When Mickey logs in using different patterns of capitalization, the following wiki names result:

• login: mickey.mouse
  • wikiname: mickeymouse
• login: Mickey.Mouse
  • wikiname: MickeyMouse
• login: Mickey.mouse
  • wikiname: Mickeymouse
• login: MiCKey.moUSe
  • wikiname: MiCKeymoUSe
• login: MICKEY.MOUSE
  • wikiname: MICKEYMOUSE

2. Improper wikiname syntax

Aside from the case-sensitivity issue stated above, even when we force all upper caps or lower caps in our login name, the wikiname that is created within the cache is always upper case, which results in a bad wikiname that's difficult to read. Here's an example of a user entry within our cache file:

cn=shiva.goudarzi, cn=employees, cn=users, dc=woozer, dc=com 
U2DN::shiva.goudarzi
shiva.goudarziDN2U::cn=shiva.goudarzi,cn=employees,cn=users,dc=woozer,dc=com
shiva.goudarziDN2U::cn=shiva.goudarzi,cn=employees,cn=users,dc=woozer,dc=com
shiva.goudarziW2U::SHIVAGOUDARZI
SHIVAGOUDARZIU2W::shiva.goudarzi
shiva.goudarzi@woozer.comU2EMAILS::shiva.goudarzi
cn=shiva.goudarzi,cn=employees,cn=users,dc=woozer,dc=comU2DN::shiva.goudarzi
SHIVAGOUDARZIU2W::shiva.goudarzi
shiva.goudarziDN2U::cn=shiva.goudarzi,cn=employees,cn=users,dc=woozer,dc=com
shiva.goudarziDN2U::cn=shiva.goudarzi,cn=employees,cn=users,dc=woozer,dc=com

3. Case-sensitivity results in multiple wikinames for the same person

Mickey Mouse, whose login name is mickey.mouse, now has five names attributed to him (as shown in the example of #1).

Shouldn't the cUID prevent this occurrence?

NOTES:

• Configuration settings for both environments can be found here: http://twiki.org/cgi-bin/view/Main/ShivaGoudarzi
• Issue #2 occurs within our test environment (TWiki v4.1.2) as well; however, with the TWiki:Plugins.RequireRegistrationPlugin, which does not function in the latest release, users can be prompted to register a real wikiname, which bypasses the bad wikiname in the cache. We no longer want users to register; instead, we want the wikiname to generate automatically (in correct format).

• Related Topics: TWiki:Support.WikiNameBackwardsAndInCaps, TWiki:Support.TWikiUserMappingDisabledRegistration, TWiki:Support.LdapAuthenticationCaseSensitivityBug, Bugs.Item4205

UPDATE

We resolved the bad wikiname generation by modifying the code of LdapContrib.pm:

Lines 833-848:

if ($this->{normalizeWikiName}) {
      $this->writeDebug("XXXXX: wikiName before normalize: $wikiName");
      $wikiName .= $this->normalizeWikiName($value);
      $this->writeDebug("YYYYY: wikiName after normalize: $wikiName");
    } else {
      $wikiName .= $value;
    }
  }
  $wikiName ||= $loginName;
  if (defined($wikiNames->{$wikiName})) {
    $this->writeDebug("WARNING: $dn clashes with wikiName $wikiNames->{$wikiName} on $wikiName");
    $this->writeDebug("WARNING: trying renaming the wikiName $dn to $dn + $loginName ");
    $wikiName .= $loginName;
    $this->writeDebug("WARNING: ZZZZZ new wikiName is $wikiName");
    #return 0;
  }

Lines 971-979:

my $wikiName = '';
  foreach my $part (split(/[^$TWiki::regex{mixedAlphaNum}]/, $name)) {
    my $partName = lc($part);
    $wikiName .= ucfirst($partName);
#    $wikiName .= ucfirst($part);
   }

  return $wikiName;
}

We continue to experience the login name case sensitivity issue, which prevents a login name from mapping to the appropriate wikiname stored in LdapContrib's cache.db file.

Based on comments in Support Web and on LdapContrib's developer page, the mapping issue seems to be affecting others as well.

-- ShivaGoudarzi - 21 Apr 2008

Case-sensitive login is a bug resulting from LdapContrib's interaction with TWiki. We changed the LdapContrib.pm file to fix the problem.

-- ShivaGoudarzi - 03 Jul 2008

The loginName should only be relevant generating the wikiName if LdapContrib was not able to read the wikiNameAttributes from your LDAP directory, in your case givenName, sn. So the error must be there. I've looked at that part and made sure that this code is correct, and added appropriate warning messages to show that this case happened, the fallback to deriving the wikiName from the loginName.

I am going to test this before creating a new beta release.

WARNING: In any case: don't use TWiki-4.2.0 and try to integrate into your LDAP strategy. The user code in TWiki-4.2 is too broken (see Item5118). We are working on a solution to get you a fixed TWiki-4.2.x.

-- MichaelDaum - 04 Jul 2008

The error does not come from not being able to read the attributes; it clearly does, as the cache.db file shows givenname, middlename, surname wikinames, which by the way, were not in proper wiki syntax, until we made code adjustments. I think many large organizations may not have user information in proper caps within LDAP--sometimes they might have users in all caps, or no caps, or a mixture. Our code modification takes these different scenarios into account. We're asking that you permanently add our code for proper wikiname syntax in the LdapContrib extension, so that future upgrades would not be problematic for us.

As for the issue with case-sensitive login style, where authentication was possible, but wikinames were not being sought from the cache.db file, we see the following: TWiki translates the period in login name as '_46'. LdapContrib's cache.db saves login name with period. User mapping agent searches the cache.db using login name 'shiva_46goudarzi' to find the corresponding wikiname. The cache.db stores the correct form of the login name (shiva.goudarzi), but mapping agent fails to read it, causing TWiki to create a wikiname based on login name used (which depends on the capitalization of the login name). We modified LdapContrib.pm to translate '_46' back to '.' which resolved the issue. But these modifications will make future upgrades to LdapContrib messy.

We'd like you to add our modifications to the extension, so that we can continue using it for eternity.

-- ShivaGoudarzi - 07 Jul 2008

I've already added your improved normalizeWikiName() In addition I added appropriate warning messages when deriving a WikiName has to fall back to using the LoginName. That has been done silently ... which obviously is no good idea. Your modifications (first lower-casing a part name and then upper-casing its firtst letter) is fine. Alas, the _46 part is not. That's an error in TWiki-4.2.0 that needs to be resolved there. Note, that most LdapContrib users still run a TWiki-4.1.2 and the code must stay compatible with that release, which is nearly impossible.

With regards to your upgrade/downgrade path: I will add your normalizeWikiName() patch, I will not add the _46 hack to LdapContrib. Have a look at the fixes at Item5118. This is trying to hotfix TWiki-4.2.0 for the upcoming TWiki-4.2.1 release. In the goal is: LdapContrib will support TWiki-4.1.2 and TWiki-4.2.1 onwards, skipping support for TWiki-4.2.0. So best for you is either to downgrade to TWiki-4.1.2 now or wait for TWiki-4.2.1 and use the next LdapContrib release that will contain part of your work.

Let's stay in contact so that I know if things work out for you on future releases of all the components that you are using.

-- MichaelDaum - 08 Jul 2008

Fixed in LdapContrib 4.10

-- MichaelDaum - 09 Nov 2010