Developers of Sympa

[John-Paul Robinson <address@concealed>]

Olivier Salaün - CRU wrote:
> Hi John-Paul,
>
> Could you first explain your hypothesis :
> Can we assume that the NetID is a stable information that will remain 
> the same every time this user logs in. Can we assume that no other user 
> will ever get the same NetID ?

Yes.

> Why your SSO doesn't provide the user's email address ? I can think of 
> many reasons including :
>
>    1. It doesn't have it
>    2. It could provide one but it should not be used as an identifier,
>       with associated privileges

I'm thinking mainly of option 1, though option 2 certainly applies.

> If your hypothesis cannot be changed, then Sympa should be able to 
> establish the connection between the NetID you provide and a verified 
> user email address. But there are a few changes to the 'generic_sso' 
> implementation that we should perform first :
>
>    1. store user_attributes somewhere else, as session data. Currently
>       Sympa does not handle sessions in a central location, they are
>       only stored on the client side (HTTP cookies) ; we've got to
>       change this architecture.

The session data change would be nice, though I don't think it would 
absolutely be needed to implement this.  But I agree, moving to sessions 
would be an "cleanliness" improvement over the cookies.

>    2. the association between email address and NetID should NOT be
>       stored among the session data ; otherwise the user would have to
>       register his email address every time he performs a login. It
>       would be an ergonomic disaster !

Absolutely agree.  My thinking was to either (mis)use an existing table 
column in user_table or just tack on an extra one, like "netid".  I 
kinda like the appeal of the new column for two reasons. First, it could 
possibly only impact the authn and registration code.  The authn code 
would do the netid-to-email mapping much like the current sso code does 
the netid-to-email via ldap mapping, except that it would use the sympa 
db instead of ldap. The registration code would need to have logic for 
a configuration option to trigger the prompting and verify of the email 
address when only a netid is presented.  Second, the new column should 
be invisible to the bulk of sympa logic, since the netid-to-email 
mapping via ldap is already functional.

> This work would also be strongly related to features extension regarding 
> alternate email addresses. Sympa currently has a very limited usage for 
> alternate email addresses. We wish to manage them in Sympa database and 
> associate exactly the same privileges to a user's alternate addresses. 
> The problematic is roughly the same : being able to use something else 
> instead of the user email address.

Yes, though I imagine this feature extension is more complex, since you 
would be making all of sympa aware of the "netid" concept.

> Eventually I suggest you fill our feature request form : 
> http://listes.cru.fr/mantis/

Gladly.

~jpr

> John-Paul Robinson wrote:
>
> > I'm trying to figure out different ways to leverage the attributes_user field 
> > in the users_table.  It's my understanding that this field is populated 
> > automatically during user registration via SSO with one or more CGI variables 
> > as defined in auth.conf via http_header_prefix. The documentation states 
> > these attributes can be leveraged for authz using user.attributes structure 
> > and in wwsympa templates.
> >
> > I'm toying with an idea of maintaining a mapping between a supplied attribute 
> > from the CGI environment and the email_user value.  If the email_http_header 
> > value is missing from the CGI during authn, then the user's email could be 
> > looked up via attributes_user.  This would operate similarly to the current 
> > mechanism of using LDAP to lookup the email address via the netid in 
> > do_sso_login().  The only difference is that the netid->email mapping would 
> > be self-contained within sympa.  The netid  would be stored in attributes_user 
> > and the do_sso_login() would search  this column to find the correct email_user.
> >
> > Of course, this relies on the mapping having been previously defined in sympa and introduces a small chicken-and-egg problem: if the user is not yet registered then there would be no mapping.  My thought is  that this could be solved in two ways.  One could be a simple fall through to another method like the ldap lookup.  Another could be a fall through to a alternate registration method, like user-supplied email address.  
> >
> > I'm particularly interested in the second option.  What I'm thinking is that 
> > if the mapping is absent (first time registration) the user could be authn'd 
> > and sympa has the netid but then prompts the user to enter their email 
> > address and follows the confirm-with-password steps before registration is 
> > completed.  To complete registration, sympa would store the netid in 
> > attributes_user and the user-supplied-password-confirm email address in 
> > email_user. This would give sympa the ability to accept a netid but rely on 
> > the user to supply the email address.
> >
> > This seems like it would be reasonably straight forward to implement and hook in 
> > neatly with the existing netid->ldap-email mapping.  It also seems to allow 
> > sympa to continue to use the email address as it's primary
> > internal identifier.
> >
> > What I'm not sure about is if this would have a significant impact on other parts of sympa's operation.  
> >