[ogsa-authn-bof] SAML-Grid Name Mapping Framework

[Nate Klingenstein]

Tom,

> A third scenario---the scenario of most interest, in fact---involves
> attribute push, where the X.509 certificate contains attributes and
> other artifacts of authz.  Of course VOMS is the most prevalent
> example of attribute push in grids.  While VOMS pushes X.509 attribute
> certificates, however, we propose pushing SAML attribute assertions.

I agree, there's a variety of additional information that can come  
out of the SAML environment that may be of interest to the grid.   
Attributes and authz decisions are the most obvious; another piece of  
information may be the LoA and method of the initial authentication.   
I'm trying to constrain the conversation to the name identifier at  
this point in time to make sure that we can focus on getting  
commonality there first.  Do you think that's reasonable?

> I don't think anything but the entityID is needed since I'm assuming
> the existence of metadata at the Grid SP.  A logical place for the
> entityID is the Subject Information Access extension.

This is true so long as there is a consistent primary or default way  
that each IdP/DS wants to be contacted by the grid SP's.  I'm not  
sure whether that's a fair assumption or not; in SAML-based requests,  
there's an optional AssertionConsumerServiceURL(e.g. SHIRE in  
Shibboleth 1.x parlance) which may differ from the default associated  
with an entity ID.  I think it would be nice to preserve that  
flexibility if possible, but that may be too complex at this point in  
time.

>> 2. a SAML Subject
>
> There are no less than three possibilities:
>
> 1. A fully formed SAML Subject might be added to the Subject Alt  
> Name extension.
> 2. A SAML Subject might be extracted from an X.509-bound SAML  
> assertion.
> 3. A SAML Subject might be fabricated on the fly using the Subject DN
> of the certificate in a NameID having Format X509SubjectName.
>
> To query, the Grid SP might check these three options in turn.  See
>
> https://spaces.internet2.edu/display/GS/GridSP
>
> for details.

Option #3 is interesting because it's a subject that is potentially  
different from the identifier that has been originally sent by the  
IdP, which may have been an attribute, persistentId, etc., unless we  
want to make every IdP talking to a grid gateway release a special  
name identifier, which seems to be a big challenge.  We need to  
assume the IdP is able to recognize the X509SubjectName and associate  
it with the right identity back at the IdP, which means a tighter  
coupling between the translation service/grid CA and the IdP.  I  
don't know if I'm comfortable with #3 for that reason.

I'd add an option #4 as a programmatic mapping between an x.509  
subject name and a SAML subject name.  That would imply a standard  
place in the SubjectDN where any given identifier and its type would  
be placed (e.g. CN=ndk at internet2.edu/urn:oid:1.3.6.1.4.1.5923.1.1.1.6  
or CN=<opaqueAlphaNumericString>/urn:oasis:names:tc:SAML:2.0:nameid- 
format:persistent) which means the IdP can speak its own language and  
the grid only has to handle DN's.

The important thing to me is to ensure that an x.509 credential  
created by any given SAML gateway can be parsed the same way by any  
given grid SP to result with the same SAML subject.

Do you feel we can constrain this list of options at this point in  
time and select one that seems most reasonable?  Is the  
SubjectAltName already reserved for other purposes in some grid  
deployments?  What would #1 and #2 mean for DN-based ACL's?

> We don't necessarily see attribute push and attribute pull as mutually
> exclusive.  We might restrict the amount of pushed information for
> privacy reasons, for instance.

In addition to what you mention, in cases where there's a desire to  
do the ID-WSF style identity reconciliation, it's quite likely both  
will be needed.  This is why I see the Liberty DS as such a useful  
box for this purpose; it ensures the grid SP only needs to be aware  
of one identifier and one endpoint/entityID to use to get "more  
information about this identity."

Sorry my responses always include so many questions...
Nate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-authn-bof/attachments/20070219/b70b9460/attachment.htm