Shibboleth Developers

[Olivier Salaun - CRU <>]

RL 'Bob' Morgan wrote:

> Thanks for doing this work and coming to us with these issues, we appreciate it.  
Though we don't plan to deploy Shibboleth at a national level in the 
short term, we're really interrested in its architecture, one step 
beyond LDAP and local SSO services. There are many virtual campuses 
projects in France (all using Sympa) that will require ressources 
sharing between universities and we will shortly need more global 
authentication schemas. Shibboleth is certainly a possible answer to 
these issues.

> Let me make these comments, based somewhat on our experience here at UW 
> integrating mailman with our CAS-like web signon system (pubcookie, see 
> http://middleware.internet2.edu/webiso/ for many others).
>  
Any technical document that describes the changes that have been done to 
Mailman to support pubcookie ?

Actually, the new Sympa authentication backend that will support 
Shibboleth SSO should also work quite well with pubcookie since it also 
provides an Apache module.

> [...]
> 3.  I think that almost all deployments at large universities would need to 
> support both infrastructure-integrated web-signon authentication and more 
> traditional list-manager-specific email/password authentication; that is, 
> where the subscriber demonstrates ownership of an email address by being able 
> to produce secrets sent to that email address.  It's not realistic that 
> everyone will be able to sign in from some origin.
>  
I'm pleased to read this pragmatic point of view : there are always 
exceptions !
We've designed Sympa authentication setup with this in mind. The service 
administrator can define a list of authentication backends including 
LDAP, a Single Sign-on system or the internal Sympa DB. These backends 
are ordered and a regular expression (applied on email addresses) can be 
attached to it to determine what population of users is able (or not) to 
use it.

> [...]
>
> 5.  An obvious potential usability win offered by Shib supplying attributes to the list-manager is avoiding the confirm-sub-via-email loop that is required in the general list-manager today.  
Sympa allows to login globally on the web interface and to manage 
subscriptions (without authenticating for each list) as well as admin 
features for listmasters, listowners and modetators. Of course sensible 
admin features can be configured (on a per list and per operation basis) 
to require an authentication method that is stronger than passwords, 
like X509 certs. BTW it would be usefull that shib provides Sympa an 
attribute telling what authentication method was used to authenticate 
the user ; might be different than ID/password.

(Sympa does HTTPS client authN (easy you would say) and S/MIME authN ; 
it is also able to distribute encrypted messages. )

> This is where there is a likely misunderstanding of email-address use, however.  The standard LDAP/X.500 "mail" 
> attribute has the semantic "the email address to use to send to the person identified by this directory entry".  It 
> is entirely open whether that address is managed by infrastructure processes or by the user.  I think that in most cases at 
> large universities, this address can be set by the user to whatever they want.  Often we have a separate attribute for 
> "the email address for this person in the centrally-supported email service"; this attribute would be set by 
> provisioning processes and not by the user.  It is this second kind of address that the list-manager would need to get if it 
> wanted to be able to create a subscription immediately, without the confirm-via-email loop. But this attribute, and this 
> semantic, is not standardized.  It would be a big mistake to use the regular "mail" attribute in this way, especially 
> in the Shib-supported multi-origin scenario, since that would permit subcription abuse.  It may be that it is appropriate for 
> us Internet2 types to define a new attribute with the "official email address" semantic, for this purpose.
I'm very surprised ; but maybe I misunderstood you :
Are you supposing that we can't trust email addresses published in home 
organization's LDAP directory, ie some email box could not owned by the 
related user ? This is the only hypothesis made by Sympa...

When authenticating via Shib the list manager needs to get, directly or 
indirectly, AT LEAST one email address.

> 6.  Obviously a list-manager will require a permanent user-specific 
> identifier for users to manage subscriptions.  Shib offers (at least) two. 
> One is eduPersonPrincipalName, which is more or less a standard userid. The 
> other is targetedPrincipalName (approximately), which is intended to preserve 
> user privacy by permitting a different opaque userid for each
> target.  It would be appropriate for a fully-Shib-enabled Sympa to support 
> both in my view.
Sympa definately needs Shib to provide an email address attribute. I 
know shib can be configured to provide vague attributes to target sites 
( like  or student@xxx), enhancing privacy protection, but 
a mailinglist system will not work with too few attributes provided.

Concerning the use of PrincipalName in Sympa. Sympa currently uses an 
email address as a primary key and we wish to extend this, not only for 
Shib needs but to allow alternate email addresses use for every 
features. This is in our TODO but we consider it a separate job from 
supporting Shib SSO, though we could extend Shib support when it is done.

--
Olivier Salaun
Comite Reseau des Universites