RFC: Detaching user name from email, LDAP and Single-Signon

[Joel Peshkin]

Gervase Markham wrote:

> Joel Peshkin wrote:
>
>> 1) Add a field to profiles containing a (varchar(128)) identifier.  
>> This field should be added to the profile before any of the 
>> authentication systems start to use it.
>
>
> So this field would be accessed by Auth modules and used as a 
> correlator to relate Bugzilla accounts to accounts in Something Else? 
> And it would be opaque to the rest of Bugzilla?

Correct.

> Is 128 enough?
>
  It would often be an employee ID number (generally less than 16 
chars), but I could imagine it being a GUID of some sort as well.  Once 
this is a varchar, there is no additional cost until we hit 255 
characters, so 128 seems like a good round number. Beyond 255, it starts 
making a problem with indexing.

>> 3) Single Signon
>>    Most single signon systems have a way to pass variables to a CGI 
>> containing the equivalent of fields from LDAP.  The single signon 
>> module would accept the variables from the webserver and handle them 
>> in a similar manner to LDAP, using a durable identifier to locate the 
>> profile and auto-updating the email address and realname if it 
>> detects a change.
>
>
> We may want to provide convenience functions for Auth module owners to 
> update profile information, so they all don't have to reimplement that 
> code. Ideally, in fact, Auth module authors would not have to write 
> Bugzilla database access code at all.
>
Agreed.  The functions ( Bugzilla/Auth/Util ??) would need to ....
    Given a subset of {identifier, email, realname}....
    If identifier is defined and matches an existing profile record,
          if email is defined,
               update email in profile (throw an error if the email 
matches a different record)
          if realname is defined,
               update realname in profile
          return userid
    If identifier is defined and does not match any existing profile record
          if email is defined and matches an existing profile record,
              update the profile's identifier
              if realname is defined,
                  update realname in profile
          if email is defined and does not match any existing profile 
record,
              insert a new profile (with a random or impossible cypted 
password)
          return userid

This would cover normal user login, cases where a user known to the auth 
system first logs into bugzilla, and cases where a user is created in 
bugzilla before the first time they ever log in themselves.

At least in my site, internal users and daemons could hit an alternate 
URL and bypass the single-signon, so we would try the Auth/SSO first, 
then fall back on standard DB auth.  That means that the Auth modules 
should also configure some variables like user->realname_from_auth, 
user->email_from_auth, and user->external_auth.  Editprefs would use 
those to decide to supress the editing of realname and email and logout 
and useful-links would use those to supress the logout link.

>> 4) Detaching user identifier from email
>>     Once the system begins to maintain an identifier other than 
>> Realname or Email, it becomes possible to build configuration options 
>> to use that identifier in lieu of email addresses in presentation and 
>> selection of users.
>
>
> Maybe I've misunderstood, but why would we ever want to display the 
> string "o=Mozilla Foundation,cn=Asa Dotzler" instead of an email 
> address or real name?
>
Beats me, but someone wrote bug 51188, and I believe that there have 
been requests to use something else.  I don't know of a scenario I like 
either.