Developers of Sympa

[John-Paul Robinson <address@concealed>]

OK. Here it goes -- :)

I've attached the patch file that covers all the changes I made to Sympa 
(including adding some new template files for new web pages) to get 
Sympa to be the core application for the VOSP environment for MyVOCS 
(http://webapp.lab.ac.uab.edu/syampa) in preperation for the recent 
Spring 2005 Internet2 Member Meeting.

The changes centered around wwsympa.fcgi.  There were a few library 
files that needed some additional code (Auth.pm, Conf.pm, List.pm).  The 
primary changes to wwsympa.fcgi were in adding new steps to the initial 
login process for users authenticated by an identity provider to supply 
and validate their email address when their federation is listed as not 
supplying reliable email addresses in the configuration file.

This change was needed to solve the problem of Sympa needing a valid 
email address and distinction between identity and email attributes in 
Shibboleth. In order to operate effectively with Shibboleth, 
applications should distinguish between a user's identity and other 
attributes. Specifically, the InQueue federation IdP's are not required 
to be authoritative (or even supply) an email address for users.  In 
this case, the user is the authority for the email attribute and Sympa 
needs to prompt the user for their email and request validation.

Once a user has supplied and validated their email address, Sympa will 
record the Idp to email address mapping in a new table called netidmap 
(defined in create_db_netidmap.mysql).   On subsequent visits, the user 
can authenticate themselves via their IdP and Sympa will cross reference 
their IdP supplied identity to their locally stored email address.

Because Sympa currently uses the email address as the identity of the 
user internally, there were no changes made to Sympa that would impact 
this operation.  The only place where the IdP supplied identity has any 
meaning is during the login process.  In all other places the normal 
operation of Sympa continues.  This means that the user will see the 
"identity" listed by Sympa after login as whatever email address they 
associated with their IdP supplied identity.

These changes are controlled in the configuration file via a few new 
options for auth.conf.  This is my current auth.conf entry for InQueue:

generic_sso
        service_name       InQueue Federation
        service_id         inqueue
        http_header_prefix HTTP_SHIB
        email_http_header  HTTP_SHIB_PERSON_EMAIL
        force_email_verify 1
        internal_email_by_netid 1
        idp_identity_header REMOTE_USER
        idp_name_header HTTP_SHIB_ORIGIN_SITE

I introduced the options "force_email_verify" which triggers the email 
attribute collection if set, "internal_email_by_netid" which causes the 
email too be looked up in the new table (instead of say ldap), 
"idp_identity_header" which supplies the user's identity attribute 
according to the IdP and the "idp_name_header" which allows Sympa to 
also record the IdP with the users identity and email, since the IdP is 
needed to ensure uniqueness.

I think I'll start the thread with this highlevel description and we can 
delve into code details and other questions on follow-ups.

I'd like to thank the entire Sympa developer team for all your help in 
developing this feature.  Let me know if I you have any questions or 
suggestions for additional improvements to the patch.

Sorry it took so long to post the patch.  I was dreding moving my 
changes from my installed directory (where I coded them -- time crunch 
:( ) back to the original source dir.  This turn out not to be hard. :)

Thanks,

~jpr

Olivier Salaün - CRU wrote:
> Hi John-Paul,
>
> John-Paul Robinson wrote:
>
> > I'm finally getting around to cleaning up the source mods I made for the I2 
> > demo.  I had done those mods against the installed wwsympa.fcgi, so now I'm 
> > working on a diff against the actual sources.
> >  
> Good news.
>
> > I want to check and make sure I understand the build process.  The sources include generic tags/pre-process vars for install dirs and other configure defines.  Is it true that all the substitution of these values occurs only during the make install via subst.pl?   
> >  
> That's right, we are doing a preprocess. At the "make install" time, 
> every --MYVAR-- variable is instanciated.
> Because of these variables, when working on Sympa's code, it's better to 
> work on "sources" and then run a "make install".
>
> > Also, I made my mods against 5.0b1.  I know 5.0 has been released.  I recall 
> > that the thing that was holding up 5.0 were some translation issues.  Where 
> > there other changes that would impact a diff of 5.0b1 wwsympa.fcgi against a 
> > 5.0 version.  I'm willing to submit a 5.0 diff if that will help.  I'm not 
> > assuming my code would be used as-is, so this issue may be irrelavent.
> >  
> There have been some changes but the diff command should adapt to 
> changes. If not, we will end up applying the patch manually. Here are 
> some recomendations to create the patch :
>
>    1. Do a diff between the 5.0b.1 and your modified version (not
>       between 5.0 and your version)
>    2. Run the diff comand with the "-c" option to provide a contextual
>       diff that should adapt to changes in the code
>    3. You can also set the "-bB" option of diff to ignore the
>       added/removed spaces/empty lines
>
> If you have to source trees, you should run the diff this way :
> % cd /usr/local/src ; diff -cbB sympa-5.0b.1 sympa-extended > your.patch

Attachment: jpr-sympa-5.0b.1.patch.gz
Description: application/gunzip