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

[Nate Klingenstein]

OGSA-Authenticators,

Thanks for taking so much time out of your schedules to discuss the  
issue of mapping Shibboleth names to Grid names and vice versa.  This  
has been a very interesting thread, and I'd like to build on Tom's  
note in a new thread to get down to business.  I think we've  
collectively broken the problem down into a couple issues.

The first is simply mapping some information sent by a Shibboleth IdP  
to something that can be embedded in a grid credential.  This is  
important in two main scenarios: when authentication implicitly  
grants authorization, e.g. a list of names in an ACL, and the other  
is when we want to take something back out of that credential and use  
it to acquire additional information or credentials, e.g. attribute  
pull.  Both arise frequently and I don't believe they'll ever be  
eliminated.

The second, as Tom Barton points out, is what the scope of a grid  
identity/community is and the potential overlap of multiple  
identities.  This problem is not unique to the grid, and there has  
been a lot of time spent examining it by the Liberty Alliance, in  
particular.

The functionality he describes as missing is very similar to what's  
available through a combination of ID-FF, largely added to SAML 2.0,  
and ID-WSF.  They've created the concept of a personal discovery  
service(DS, same name but different from the Shibboleth 2.0 DS),  
which is a generalization of the AA in a sense.  It's a location  
where an individual's identities are indexed along with pointers,  
mappings, and rules.  The discovery service can provide some decision  
logic as to what information is available where and to whom it might  
be released.  I would suggest that the solutions already created by  
the Liberty Alliance can address the need Tom describes for this  
community as well, particularly as ID-WSF is a web service  
framework.  It would be excellent to embrace this.

The underpinnings required to support an ID-WSF-esque approach were  
noted by Tom Scavo.  For this sort of distributed mapping to be  
possible, there needs to be a definition of how a SAML-based  
identifier is stored in a grid X.509 credential.  This brings us back  
to the first problem.

I don't think the identifier that gets placed matters from a  
standardization perspective; we want to allow for any arbitrary  
attribute to be used.  However, the format of its storage is very  
important.  Individual grid SP's or credential services should be  
able to extract the same SAML identifier and source from a given  
certificate.  It then becomes the responsibility of the IdP or the DS  
to provide the right identifier for callbacks to itself and its  
friends.  If the IdP chooses to supply only persistentId's(e.g.  
ePTID), then this sort of identity association may not be possible.   
If it chooses to supply the same unique identifier(ePPN, a SWITCH  
integer, etc.), it should be possible, regardless of what that  
identifier looks like.  Deployer's choice.

To achieve that underpinning, I would like to converge on two  
things.  Quoting Tom. S, somewhere in the certificate, in the DN or  
in a certificate extension, two pieces of information are needed:

1. the IdP entityID (but I'd add the necessary addressing and  
protocol information as well, which may vary)
2. a SAML Subject

The notes from Christoph, Tom S., Stephen, David, and Von suggest to  
me we're not far apart on the first, but I don't think we've spent as  
much time talking about the second.

I'd like to look into and agree upon the nuts & bolts of those two  
pieces.  If someone could throw out a strawman, that'd be great; I'll  
do it myself in several days if nobody else can, but I'm utterly  
snowed under right now.

Again, thanks for all the great discussion, and I look forward your  
ideas on this too,
Nate.