Shibboleth Developers

[Von Welch <>]

David,

 > WRT what's in the cert to find the AA, it might be inferred from the 
 > Issuer name but I would prefer it to be explicit as a sub-field of 
 > the SIA.  However, someone needs to draft a PKIX RFC on use of the 
 > SIA and include this as one of the "standard" options.  Any takers 
 > for this (I'll help)?

This is certainly something I see on my plate. Probably on the
backburner for a another month or two, but eventually something the
GridShib team will need to address. If someone else has a more urgent
need, I would shuffle it up on my pirority stack to help.

BTW, I agree with your feelings of making it explicit rather than
implied by the Issuer name (or Subject name).

Von

David L. Wasley writes (08:15 November 1, 2004):
 > Steven, Keith,  I assume that in the case Keith describes, the SP 
 > must perform the proof-of-possession step as part of accepting the 
 > x.509 cert.  If it doesn't, e.g. in some Grid scenarios, it is 
 > accepting that risk.
 > 
 > The AA must then "trust" the SP to be submitting a legitimate query - 
 > not just fishing.  In the "normal" User-HS mode, there is at least 
 > some reason to believe the actual User is, or was recently, on-line 
 > and maybe even trying to access the SP in question.
 > 
 > The other x.509 scenario is, of course, to rely on the HS to get the 
 > User's cert directly and do the PoP.  I tend to like this better, 
 > although I know it won't work for the Grid use case (as defined).
 > 
 > WRT what's in the cert to find the AA, it might be inferred from the 
 > Issuer name but I would prefer it to be explicit as a sub-field of 
 > the SIA.  However, someone needs to draft a PKIX RFC on use of the 
 > SIA and include this as one of the "standard" options.  Any takers 
 > for this (I'll help)?
 > 
 >      David
 > 
 > -----
 > At 9:18 AM -0400 on 11/1/04, 
 > 
 >  wrote:
 > 
 > >At 7:23 AM -0600 11/1/04, Keith Hazelton wrote:
 > >>Question about coming support in Shib AA for scenarios where user 
 > >>presents an X.509 cert to SP and the cert contains a useful subject 
 > >>identifier and a pointer to a corresponding IdP.
 > >>
 > >>Do I understand this centers on the addition of key holder token 
 > >>support to the Shib AA to complement the current bearer token (if 
 > >>my terminology is correct)?  What's the priority, timeline, etc.? 
 > >>Relevant to how we pitch Shib / PKI (user certs) here at UW-Madison 
 > >>in the near future.
 > >>
 > >>    Thanks in advance for any info, advice,  --Keith
 > >>
 > >
 > >I've pasted in down below a description of the grid-shib use case 
 > >that we all agreed on in feb 2004, and which I believe served as the 
 > >basis for the recent grid-shib nsg proposal.
 > >
 > >Basically, the client presents a classic X.509 subject (or proxy...) 
 > >cert to to the SP, the SP (using one of a variety of mechanisms) 
 > >locates the relevant AA(s), the SP queries the AA and presents the 
 > >cert instead of a handle.
 > >
 > >Is this close to the scenario you imagine?
 > >
 > >Supporting this use case does involve extending the AA, so that it 
 > >can answer queries about the user referenced by the cert (rather 
 > >than a handle). It doesn't use the Holder-of-Key confirmation method 
 > >that I think you're referencing. I don't think we've yet worked thru 
 > >the details of *exactly* how this would work.....
 > >
 > >Our current plan is to include this support in Shib v1.3, due in  march 
 > >2005.
 > >
 > >At 5:51 PM -0600 2/11/04, Von Welch wrote:
 > >>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).