Shibboleth Developers

["David L. Wasley" <>]

Please see below ...
-----
At 2:05 PM -0600 on 1/12/04, Von Welch wrote:

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

This model assumes, in Shibboleth terms, that the user's Origin 
Domain is the domain of the target service (step 1 above).  The twist 
is that the Origin Domain is not authoritative for at least some of 
the attributes of interest.

From a Shib point of view, the "target" in this case wants to be able 
to ask a particular AA at any point in time to release information 
about some entity.  There is an assumption that the target has an 
identifier of some sort for the subject that is recognized at the AA 
-- the cert Subject Name may or may not be that identifier, depending 
on how it was created.  So the subject identifier is the first 
problem. (+)

The second problem is simpler: a different API to the AA.  This would 
be a simple query interface where the asker is identified by means of 
a trusted cert (no mean feat but that's another story).  As with any 
query to the AA, there is default information that it will release to 
any asker but if the asker is "known" to the AA, then it may have a 
specific ARP to apply to the query.  Again the crux is the identifier 
by which the asker seeks to be recognized.

(+) I suggest that this problem be addressed by asking the GRID user 
to apply for GRID services using their "home org" EPPN.

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

Sounds like a Kerberos ticket ...

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

All this primarily to avoid a new API at the AA.  I think we've 
always known that a simple query API is needed so that needs to be 
designed anyway.  So the question is whether any of the other 
trust-related pieces of this scenario add something useful.

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

Looks the same as #2 but the query is done with a "handle" instead of 
an "EPPN."  Clearly the simple query API will need to be generalized 
through use of a tag(s) for the query data, much like any normal 
database query.

Questions for the Shib designers:

 - is the concept of "session" important WRT the simple query API? 
In other words, is there a concern that a query should be the result 
of a user action and not an arbitrary, random event initiated by the 
target?

 - is there any serious impediment to a simple query API for the AA?

Thanks,
        David