Shibboleth Developers

["RL 'Bob' Morgan" <>]

On Thu, 9 Oct 2003, Olivier Salaun - CRU wrote:

> Any technical document that describes the changes that have been done to
> Mailman to support pubcookie ?

Attached.  This was written up as an example of how to apply a "webiso"
(eg pubcookie, CAS) to an app.

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

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"

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

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.

Take my directory entry here at the UW.  It says:

  mail: 


Though this is in fact my institutionally-provided email address, and it
also looks like my institutional principal name, in fact this string is
just the value that I entered into our employee-self-service
directory-info-update page, and it could have been anything.  We permit
our users to put almost anything in there (I think we require an "@", and
do some charset-checking on the domain name), since the address they want
to advertise for receiving email might be on a departmental server, or on
hotmail, or whatever.  I suppose it would be possible to do the same kind
of check that list-manager servers do, ie send a secret to the entered
addess and require it to be provided to accept the update, but this would
be a major change to what is now a simple direct-data-entry interface.
But at this point users can put in anything they want.  And I think this
is what most sites do, for the same reasons (others please chime in here,
this is just my guess).

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

You really need to think about the distinction between email address and
authentication identity.  There are universities out there where the
"enterprise userid" and the "enterprise email address" are completely
unrelated, since they're run by different parts of the organization.
There are universities out there without any centrally-supported email at
all.  (There are those without central authentication, but we'll ignore
those because they are by definition unable to participate as a Shibboleth
origin.)

What Shibboleth, or any authentication system, provides as the thing to be
used by applications to uniquely identify the user is an authentication
identity.  This is the thing that the application has to use to index into
its database of users.  In the case of Shib, as I mentioned, we offer two;
I suggest that as a first pass Sympa rely on eduPersonPrincipalName
(EPPN), which is by default provided to a web-based app (via Apache) as
good old REMOTE_USER (rather than getting into the more complex space of
eduPersonTargetedID).  But let me stress the point again:  this is not
necessarily an email address.  And if Shib did supply an email address to
Sympa, it should not be relied upon for

This is a profound difference from the traditional email-based method of
authenticating to a list manager, where the user's email address is all
you have, and it is established as an authentication identifier via the
sending-a-secret loop.  In the brave new world of relying on an
authentication system, the authentication identifier is the thing, and it
might not be an email address.

So is there a use for a Shib-supplied email address attribute, with the
existing "address the user wants to use" semantic?  Sure, but only as a
default value.  It's worth noting that there might be multiple values
provided via this attribute, since some sites permit users to enter more
than one (a bad practice in my opinion, but people do it).  In this new
world, I would think the system should permit the authenticated user to
enter several email addresses to be associated with their entry, to be
provided as a list to choose from when subscribing to a particular list.

As I mentioned, there is definite benefit in having the right info
provided to avoid the send-a-secret email verification loop.  This would
require the origin to send an email address with the semantic "the email
address under the control of this authenticated user".  We don't have an
attribute with this semantic now, but I think we should define one (or
pick one from some existing schema if it exists).  Sympa might also
provide configuration so that if a site did have this semantic on an
existing attribute (eg the traditional "mail" attribute) that this could
be noted in the Sympa config and the attribute used for this purpose.

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

As I explain above, I think doing what you describe above is essential to
properly supporting Shib.  I really really don't want to see practice
established with misuse of the existing "mail" attribute.

 - RL "Bob"
Goal statements:

- as distriubted, mailman maintains an authentication database
  of its own, comprising user email addresses and membership
  passwords. we wanted to augment mailman's built-in
  authentication system with pubcookie-based authentication.

- more specifically, we want UW users (list owners or list
  members) to authenticate via our weblogin/pubcookie service.
  non-UW users continue to use mailman's built-in authn system.

User interface changes:

- where mailman originally asked users to "log in" using an
  email address and membership password, we now provide a
  choice: UW users can authenticate using our pubcookie-based
  "weblogin" service, and non-UW users can authenticate using
  mailman's original email address and password method.

- users must self-select which kind of authentication is
  appropriate for them.

- if a UW user has already authenticated, there is a variation
  on the log-in interface: the login button becomes a logout
  button and the user's identity is filled in where appropriate.

- when we know that an authenticated mailman resource can only
  be used by UW users (e.g. some list administration features),
  the only log-in option is to authenticate via the
  pubcookie-based weblogin service.

- additionally, a "logout" link has been added to list
  administration pages that require authentication via the
  pubcookie-based weblogin service.

Configuration changes:

- pubcookie uses a "container" approach to target-side
  application integration and configuration, meaning it contains
  an application and blocks requests to protected resources
  until a user has been authenticated.

- mailman, however, does not want to be deployed within such a
  container. authentication is handled when and where it is
  required. therefore, in order to minimize changes to mailman,
  we needed to pass pubcookie-based authentication information
  into mailman without actually putting mailman itself in a
  pubcookie-protected container.

- so we configured a separate location of /mailman/uw/ to
  require authentication via pubcookie. there is no mailman code
  in this location.

- we created a "stub" application at /mailman/uw/login that (1)
  takes the authentication information from pubcookie (i.e.
  REMOTE_USER) and sets a SHA1 encrypted and encoded cookie
  named "mmuid", and (2) determines where the user was trying to
  go and redirects them back to it now that they have been
  authenticated.

- the "mmuid" cookie is scoped to /mailman/ so that it's
  available to the entire mailman application. this is how we
  communicate external authentication information from the login
  "stub" to the rest of the mailman application when it's
  needed.

- for logout, we configured a /mailman/uw/logout/ so that
  requests to this location engage pubcookie's per-application
  logout mechanisms that help users to manage their application
  sessions and to keep mindful of their current single sign-on
  session with the weblogin service.

Mailman changes:

- mailman was modified to look for the "mmuid" cookie prior to
  invoking the existing WebAuthenticate() function. if present,
  the cookie is decoded and the UW NetID is extracted. we then
  use the UW NetID to get per-list email addresses for that
  user. this process is essentially a translation from UW NetID
  to mailman email address. once the email address is established,
  authorization checks can proceed as they would otherwise.

- if the user has logged in using an email address and 
  membership password, mailman's original cookie base
  authentication continues unchanged.

- modifications have been made to ensure that authentication for 
  the ListAdmin or SiteAdmin roles comes via the "mmuid" cookie.
  authentication for ListModerator and User can come from either
  authentication mechanism. this implements a local policy that
  all list administrators must be UW users.

- we added a module to encapsulate much of the localization, and
  added a database to hold the list/email data for each UW
  NetID. the database in particular is just a stopgap
  implementation.

- additional policy refinements were made to MailList.py

- we did not modify the mechanics of mailman's authenticating
  email system, which sends out confirmation notices and handles
  the replies. however, we did add the UW NetID datum in order
  to create the new account (or whatever)  correctly. there are
  small code changes all over the place that help to hand around
  this additional datum.

- mailman doesn't make its cookies "secure", out of the box. we
  changed it so that both kinds of session cookies would be
  marked "secure" and made changes to ensure that URLs presented
  by mailman use "https" instead of "http". it guesses when to
  do that, based on how the current page was accessed and on
  whether the destination will likely need SSL.