Developers of Sympa

[Olivier Salaün - CRU <address@concealed>]

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 ?
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

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.
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 !

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.

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

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.  
  

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature