Shibboleth Developers

[Von Welch <>]

Here's the Grid use case we agreed as being most reasonable during on
last discussion a month or so ago.  It's one of the three I originally
proposed. I've added some more detail and fulled out the preconditions
of the use case.

Von

====================

Setting the stage - preconditions for use case:

a) There exists some mechanism for canonicalizing a X.509 subject name
that Grid middleware and the Shib AA service agree on.

b) Shib Attribute Authority is aware of X.509 subject names for (some of,
at least) its users.

c) There is no session concept in this model. By that I mean nothing
like the current handle which essentially lets the AA know that the
user has contacted a target resource in the recent past.

d) There is a standardized X.509 extension indicating how a relying
party may contact one (or more?) AAs services which can issue
attributes for the subject inthe X.509 certificate of which the
extension is a part.

====================

The use case: Use connects to a Grid resource using standard Grid
credentials, clients, protocols. Resource contacts a Shib AA which is
authoritative for the user and makes an access control decision based
on one or more attributes (or lack there of) from the AA.

Steps:

1) User acquires Grid credentials (Proxy Cert or EEC and associated
private key) through a normal mechanism - e.g. proxy certificate
generated from long-term X.509 credentials or certificate from
KCA. These credentials MAY have a non-critical X.509 extension which
indicates one Shib AAs which are authoritative for the user.

2) The user (or process running on the user's behalf with delegated
credentials from the user) authenticates to target service with normal
Grid credentials (EEC or Proxy Certificate and associated private
key). 

3) Through this authentication the target service established the
subject name of the user (as well as a information about Shib AA which
can speak about the user, if contained in their credentials).

4) Either through information contained in the user's credentials or
through some local policy, the target service consults local
configuration which maps the subject name of the user to a particular
Shib AA.

5) The target service contacts the AA over a SSL protected
channel. Local, trusted copy of certificate of Shib AA is used to
verify that the correct AA is being communicated with. Target service
performs mutual authentication with shib AA using it's own X.509 EEC &
private key. From this authentication Shib AA acquires subject name of
target service.

6) Target service presents user subject name and requests some set of
attributes (possibly all) for user.

7) Shib AA consults ARPs to determine target service's right to access
attributes for user (based on its subject name from
authentication).

8) Shib AA delivers list of attributes to target service over
SSL-encrypted link. Link integrity checking allows attributes to be
unsigned.

9) Target service uses attributes along with local policy to make
access control decision(s).