Shibboleth Developers

[Walter Hoehn <>]

My understanding is that the "Holder of Key" confirmation method would 
not be used in scenarios where an SP queries an IdP on behalf of a 
user, but rather when a user queries the IdP directly and then presents 
the resulting assertions to an SP.  With this general flow, especially 
if there aren't strict constraints on time validity and replay, the SP 
needs a way to ensure that the assertion is actually describing the 
bearer... and not someone else.

As described in the grid scenarios that Steven pasted, the IdP can 
respond to queries using identifiers pulled from certs used in client 
authentication the an SP.  The only work here is to map these 
identifiers back into the internal identifier that the AA uses during 
processing.  At an implementation level, this is handled by the 
NameMapper feature in the AA and is configured by adding <NameMapping/> 
elements in the origin.xml.  Since this functionality is abstracted, it 
is easy to add new mapping methods (probably 15 minutes work for me).  
I think this is what you need, but could you describe the use case in 
more detail.

David's point about fishing is well taken.  We have discussed adding 
authZ regarding which SPs can use which NameMappings, but haven't 
implemented it yet.  I think this is on the 1.3 TODO list.

-Walter


On Nov 1, 2004, at 10:15 AM, David L. Wasley wrote:

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature