Shibboleth Developers

["RL 'Bob' Morgan" <>]

Olivier:

Thanks for doing this work and coming to us with these issues, we
appreciate it.  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).

1.  History shows that it's easy to get confused about the relationship
between authentication identifiers (ie userids) and the various forms of
email address that might be maintained by IT infrastructure services, so
it's important to be precise about exactly what data items are used for
what.

2.  I would think that the basic model of a list manager, regarding
subscriber-users, would be that a user can have (and manage) many
subscriptions, each subscription consisting of an email address subscribed
to a particular list (and other per-subscription info, of course).  The
point is that as a user the email address I use to subscribe to list A
need not bear any relation to the email address I use to subscribe to list
B; but the listmanager interface should let me manage all of these via my
single authentication identity via the web interface via web SSO.

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.

4.  It is an interesting question whether the system should permit a
particular set of subscriptions for a user to be managed both via the
web-signon method and the traditional password-in-email method.  This
depends on whether the organization is looking for web-based list
management to provide just convenience, or improved security.  In our
deployment the elimination of password-in-email in as many cases as
possible was a goal, so we don't create list-specific passwords for
web-authenticated users/subscriptions.  Other places might choose
differently.

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

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.

 - RL "Bob"