Shibboleth Developers

[Von Welch <>]

------- start of forwarded message -------
From: "Von Welch" 
<>
To: 

Subject: More detailed Grid scenarios
Date: Mon, 22 Dec 2003 13:18:32 -0600


Below, in greater detail, are three possible ways I could see Shib
integrated into a basic Grid use case. All three use a basic model of
the user authenticating to a target service and then the target
service contacting a Shib AA for attributes it uses for authz.

The differences in the cases are:
#1: No session or privacy, user subject name is only identifier
#2: No privacy, but handle is used to establish a session
#3: Handle used for session, sort-term X.509 credentials used for
    privacy.

Basically, the level of feature support increases from scenario #1 to
#3 as does the level of complexity.

I think the question to be answered here is "Is there a particular
level that makes the most sense or can this just be made a
deployment-time decision?"

Von

--------------------

A note on Delegation: My assumption is that the user is doing full
delegation of rights to any process running on their behalf. Any such
process is given a proxy certificate (bound to new private key) by the
user. (This can be repeated, a process can delegate to another process
by issuing a proxy certificate from its proxy certificate, etc.)

--------------------

Alternative #1: Credential Pull Model, No Privacy

In this model, there is no session concept.

* 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). Through this authentication the target service established the
subject name of the user.

* Target service consults local configuration which maps the subject
name of the user to a particular Shib attribute authority (AA). (This
mapping is probably done on wildcards using components of the subject
name, but could also be done via pointer contained in non-critical
extension in user's certificate.)

* (Getting into details of how Shib AA works that I don't know, so
making guesses here...) 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
certificate & private key.

* Target service presents user subject name and requests attributes
for user.

* Shib AA consults ARPs to determine target service's right to access
attributes for user. Delivers list of attributes to target service
over SSL-encrypted link (don't see any need for signing of
attributes).

* Target service uses attributes along with local policy to make
access control decisions..

--------------------

Alternative #2: Session based model with Handle as WAYF, No Privacy

* User (or process running on the user's behalf with delegated
credentials from the user) authenticates to a local authority. This
authority establishes a handle for the user which is entered into Shib
AA configuration as a handle normally would.

* Handle is placed into signed authn assertion along with user's
subject name. Lifetime of handle and authn assertion is set equal to
lifetime of user's credentials (probably with some administratively
set maximum). Authn assertion is returned to user.

* User generates new proxy certificate from current credentials,
including the authn assertion as a non-critical X.509 extension. (This
step is really a hack to keep from having to deal with the authn
assertion as a separate hunk of bits in terms of credential management
and in the protocol).

* User authenticates to target service with proxy certificate chain
containing authn assertion.

* Target service scans certificate chain used by user to authenticate
and finds authn assertion. (Authenticate of user's possession of
private key during tells target service user owns authn assertion
embedded in chain.)

* Target service checks subject name in authn assertion to verify
user's ownership of authn assertion and verify user's right to assert
handle.

* Target service checks signature on authn assertion with local copy
of aa's certificate to verify integrity of assertion.

* Target service determines the appropriate AA for the user. (Probably
something in authn assertion.)

* Target service contacts the Shib 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 certificate
& private key.

* Target service presents handle and requests attributes for user.

* Shib AA consults ARPs to determine target service's right to access
attributes for handle/user. Deliverslist of attributes to target
service over SSL-encrypted link (don't see any need for signing of
attributes).

* Target service uses attributes along with local policy to make
access control decisions.


--------------------

Alternative #3: Temporary credential model with privacy

* User (or process running on the user's behalf with delegated
credentials from the user) authenticates to a local authority. This
authority establishes a handle for the user which is entered into Shib
AA configuration as a handle normally would.

* Local authority creates new short-term proxy certificate for user
with handle as subject name (or more likely encoded as part of subject
name - e.g. as common name). Proxy certificate contains a non-critical
X.509 extension with pointer to AA. Proxy certificate is delegated to user.

* User authenticates to target service with proxy certificate from
local authority.

* Target service determines the appropriate AA for the user from
extension in proxy certificate.

* Target service contacts the Shib 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 certificate
& private key.

* Target service presents handle/subject name for user and requests
attributes for user.

* Shib AA consults ARPs to determine target service's right to access
attributes for handle/user. Delivers list of attributes to target
service over SSL-encrypted link (don't see any need for signing of
attributes).

* Target service uses attributes along with local policy to make
access control decisions.



------- end of forwarded message -------