Uploaded image for project: 'LDAP'
  1. LDAP
  2. LDAP-21

Let admins decide how the XWiki user id gets created


    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 9.0
    • Component/s: Authenticator
    • Labels:
    • Similar issues:


      LDAP directories are mostly case-insensitive (i.e. the case does not matter when doing a search, except for very specific attributes), however they are case-aware: values are stored with a certain case.

      Currently, when the LDAP authentication is activated, XWiki users get created based on the username provided on their first login. This introduces an ambiguity in user identification, hence potential bugs. Let's say that an LDAP group containing uid=asmith is mapped to an XWiki group, and Alice Smith has logged in with 'ASmith'. Will XWiki match 'ASmith' and 'asmith', and give her the expected rights? Even if it does, wouldn't it be preferable to let the administrator enforce a clear policy for usernames with respect to the login case?

      There are at least 2 aspects to be covered:
      1) Should a login succeed with a username case differing from the one stored in the LDAP directory (eg ASmith vs asmith)?
      2) If it does, should the LDAP value override the one provided by the user or should the first login be used?

      It seems reasonable to add an option for aspect 1), what do you think? As for aspect 2), is there any benefit in letting the user decide which case will be used? Shouldn't the LDAP value prevail in all cases, except when a local user with a different case exists already (in order to not break legacy wikis)?

      The configuration parameter could be named something like 'xwiki.authentication.ldap.UID_attr.ignore_case=true|false'?





            • Assignee:
              tmortagne Thomas Mortagne
              slauriere slauriere
            • Votes:
              0 Vote for this issue
              3 Start watching this issue


              • Created:
                Date of First Response: