Shibboleth Developers

["RL 'Bob' Morgan" <>]

On Thu, 16 Oct 2003, Aumont - Comite Reseaux des Universites wrote:

> >We do.  SAML authentication statements contain an element that does this.
> >For example, when authenticating with the UW origin the target gets:
> >
> >  HTTP_SHIB_AUTHENTICATION_METHOD ==
> >     "urn:oasis:names:tc:SAML:1.0:am:password"
> >
> Great we will use it in Sympa authorization scenarios process and it
> will be possible for some operation (mainly listmaster admin operation)
> to require a particular authentication method (X509).

Yes, some sites would want to configure it this way (we wouldn't, though,
since we don't do client certificate authentication at my university).

> >You can "trust" them, but you have to understand what they mean.  And yes,
> >my point exactly is that in the general case there is no guarantee that an
> >email address listed for a user is under the control of that user.
> >
>     * This discussion started because some Shib designer says that users
>       have multiple email addresses and may want to subscribe with
>       "alternate email addresses". Right ?

I'm not sure how it started, but my impression of the goal here is to take
advantage, appropriately, of both Shib authentication and Shib-delivered
attributes.  Seems to me that all users have multiple email addresses and
an interest in using them; but if email-address is all you've got as an
identifier (i.e., the usual list-manager operation) then this just looks
like multiple users.  It's only when authentication identity is distinct
from email-address that "alternate email address" is a meaningful concept.

>     * A mailling list server should not allow anyone to subscribe to
>       anylist with an email address which corresponding mailbox is not
>       under his control . Right ?

Yes.

> Well, if email attributes herited by Sympa from Shib authentication are
> unverified email addresses , you will just have to configure Sympa in
> order to ignore these attributes. Sympa already allows alternate email
> adresses to be declared by the users.

Seems like it would be useful for an unverified-email-address attribute
delivered by Shib to be one way of declaring or establishing an alternate
email address, rather than making the user enter it.

> On this opposite, if email attributes herited by Sympa from Shib
> authentication are verified emails addresses, it will be possible to
> configure Sympa to accept any of those email addresses for subscription,
> unsubscription etc.
>
> It's just a matter of Sympa configuration to define what Shib attribute
> provide a trusted email address.

That sounds good.

 - RL "Bob"