RFC: Detaching user name from email, LDAP and Single-Signon
Christian Robottom Reis
kiko at async.com.br
Fri Apr 9 19:58:57 UTC 2004
On Fri, Apr 09, 2004 at 06:05:44AM -0700, Joel Peshkin 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.
This field name is something like "other_id" or "external_auth_id"? So
the "external" authentication mechanism can use it to map the external
id to a Bugzilla id?
Somehow I think this fits in another table, separate from profiles, but
perhaps I'm being impractical.
> >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.
What if it's an entire LDAP identifier?
> >>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 ....
[snip - Joel goes on about having profile updated from the single signon
system]
Why isn't this done in User.pm? I discussed this with bbaetz and
justdave a while back and the feeling I got was that profile queries and
updates should be handled in the User module.
> 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.
Yeah, it sounds okay. I keep trying to fit NIS into the picture
conceptually because it's a simple way to do a reality-check. From NIS
we could grab the realname and identifier (which matches email) quite
easily for this; writing the NIS module wouldn't actually be half as
hard.
> 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.
Something like we the can_edit() method we have, today?
> >>4) Detaching user identifier from email
Perhaps this can just be covered by allowing user display to be
configurable (a "display realname, email or both" radiobutton), without
needing to require additional complexity. I can't come up with a
non-contrived use case for this.
Take care,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331
More information about the developers
mailing list