Shibboleth Developers

["David L. Wasley" <>]

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