Getting profile information rather than just authentication

[Howard Gilbert]

> Is there any SAML implementations out yet?

We expect that Yale will be working with the Shibboleth project of the
Internet 2 Middleware group. They have an OpenSAML implementation and use
SAML to vend essentially the type of information this thread is discussing.
This is a somewhat bigger issue and requires some background.

CAS is a Web based local single signon. Shibboleth is a cross-university
authentication and attribute system that doesn't have its own local signon.
In order to use Shibboleth, you have to first have a local system like CAS.
CAS, on the other hand, doesn't currently operate across institutions.

Since CAS was a local system, we never considered any other idea than to
give every server access to the unique network ID name of the user. The
Shibboleth designers, however, wanted a more anonymous system for use across
universities. While someone might logon to CAS as Joe Blow at Yale, he might
then want to use Shibboleth to connect to a service at UCLA as "some student
at yale.edu".

The Shibboleth designers were early LDAP advocates. However, to get
attributes from LDAP you have to know the unique identity of the person. So
Shibboleth was designed to transmit not the NETID, but a generated handle.
Since the handle wasn't in LDAP, when the remote service transmitted back a
query based on the handle, a Web Service provided by Shibboleth would find
the real NETID, query the LDAP directory (or database) and send back a SAML
message containing the subset of the LDAP attributes that the user wanted to
allow the remote service to see.

You can take the existing Shibboleth client-end code (the "Origin" in
Shibboleth terms) and put a CAS front-end on it. If the user accesses any
remote Shibboleth service, then he gets redirected to the local Shibboleth
origin code which, in turn, redirects him to CAS if he hasn't logged on yet.
You can do this today with existing CAS and Shibboleth code, but the remote
service has to use Shibboleth protocol and not server-side CAS protocol.
This must remain an option if two universities want to affiliate and one
uses CAS while the other doesn't. However, if two CAS using universities
want to affiliate, then Shibboleth can remain "under the covers". There are
two scenarios:

1) The user chooses to reveal his NETID to the remote server. CAS at one
institution talks to CAS at the other institution using Shibboleth protocol.
When the server side code asks for attributes, one of the attributes vended
over Shibboleth and SAML is the NETID (hey, it's an attribute just like the
others). The server side CAS application can receive this using a minor
extension to the current protocol. In case any existing application just
assumes that all CAS users are local, we would probably require the
application to use an extended call that indicates it is willing to accept
fully qualified remote netids. Then when CAS returns the netid, it would be
suffixed by the name of the remote institution ("joeblow @ xxxx.edu" instead
of just "joeblow").

2) Alternately, the application might request all the attributes for the
user, but prefer to use CAS protocol rather than changing over to
Shibboleth. CAS will talk to Shibboleth, get the attributes for the remote
(or local) user, and present them in a new formatted response to the query
where the server presents the ticket for validation. Now, instead of getting
just the NETID back, it will get the SAML attribute assertions.

CAS remains mostly unchanged, and Shibboleth remains completely unchanged.
However, what this means is that, if you want CAS to present attributes
instead of just a NETID, you will be configuring the attributes and
attribute release policy (what attributes you will allow each remote
application to view) using Shibboleth configuration files. Yale will not be
writing a new administrative interface or any code to duplicate the already
existing, perfectly good service.

This leaves one last point that neither current CAS nor Shibboleth handle.
SAML has three uses:

1) To make assertions about the identity of a user. This is the function CAS
currently supports though in other uses of SAML the identity could be
represented by a Kerberos ticket or PKI certificate.

2) To make assertions about the attributes of a user. This is a network
server that, given a principal name of a user, looks the user up in an LDAP
directory or database and returns things like "student", "undergraduate",
"junior", "math major", and so on. This is the sort of thing Shibboleth is
designed around.

3) To make assertions about the permissions of a user, by comparing the
attributes of the user to institutional policy. This is a centralized
network service that is part of the SAML architecture but is not part of
either CAS or Shibboleth, nor any other I2 or similar project. Currently
permission decisions are farmed out to each individual server (but currently
CAS also farms out the attribute lookup to every server frontend). It may be
that some central service can be coded that will handle 90% of the
requirements with 10% of the effort. Particularly to answer questions of the
form "this user is permitted to listen to digital assets in the online Music
Library".

Now for some disclaimers:

The Shibboleth people feel strongly that their protocol should not be bound
to any particular Web signon system. They will not be endorsing CAS,
although we will be endorsing them.

We will probably continue to distribute CAS all by itself for simple
installation. 

We will probably offer a CAS-Shibboleth combined distribution for easier
installation of CAS in a cross-institutional setting (or where anonymous
access or SAML attribute assertions are desired even within a single
institution). This will be more complicated to configure than simple CAS,
but will be easier to deploy than CAS and Shibboleth installed separately.

The Type 3 SAML permission assertion engine is a long term objective. Don't
expect it in 2004 if we have to write most of it ourselves. If we can find a
compatible project or product things may move quicker. This idea is neither
funded nor approved, while the CAS and Shibboleth work is under way.