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

[Nate Klingenstein]

Tom,

I've been tying myself in knots all day trying to figure out how I  
want to respond to this.  It's a very interesting mail that may have  
changed my views on this subject.  Let me share with the list broadly  
why I'm so confused in hopes that someone clever can chime in.

>> 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?
>
> Yes, that is the interface between the campus and the grid.  Of all
> the properties we've discussed so far, the most important is the
> non-reassignment of the identifier, I think.  If you can guarantee
> that, the rest can (and probably should) be handled within the grid.

There is a variety of attributes and name identifiers that make this  
promise.  eduPersonPrincipalName is not one of them.  Discussion of  
persistence and reassignment will suck up vast amounts of time in the  
future, I'm sure, but let's avoid it for now.

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

>> (and #4, programmatic mapping)

There's a lot of different information in the SAML assertion that  
we're interested in.  Much of it would be difficult to express  
natively in x.509 in the absence of a universal credential  
converter.  I think it makes sense to provide as much of that  
information as possible to the grid SP or service, which probably  
means binding the SAML assertion(s) directly to the x.509 credential  
in an extension is part of a medium-term solution.

Ignoring #3 for now due to the problems Tom and I noted, let's look  
at #2 and #4.  What would be done with a SAML subject that's been  
inserted into the Subject or SubjectAltName?  I assume the subject DN  
would still be considered the primary key for a certificate and used  
for gridmap files.  I understand today that it's also used for a  
subsequent attribute pull from an IdP associated with the initial  
assertions using a metadata lookup, but I'm trying to look into the  
attribute push future.  In that world, I think that additional pulls  
that may be necessary are represented using ID-WSF EPR's that are  
embedded in SAML attributes.

I'm pretty sure this is where I get confused.  Let me go into  
hypothetical land for a moment, if you'll follow along. :D

I think of a NameIdentifier as a primary key to identity information  
stored at some endpoint.  Each endpoint decides what its own NameID's  
look like and what they mean.  Everything that the SP uses for authn/ 
z is an attribute, including ePPN, LoA, hair color, persistentId,  
etc.  NameID's and attributes may overlap, but are semantically  
distinct.  Access control is performed using attribute names and values.

In this context, a NameID only makes sense when it's paired with its  
EPR.  If I want to collect attributes from other identities  
affiliated with the identity at hand, I chase down NameID/EPR  
combinations asking for more stuff.  Making a nameID "primary" or  
using it on its own is meaningless.  They're only good for grabbing  
more ingredients for your attribute soup.

Please see section 2.3.5 of the Liberty ID-WSF DS Specification for  
an example of what I mean by NameID/EPR pair(the nameID in that case  
is in the EPR, but can also be in the surrounding token).  For  
details on how this relates to SAML, please see section 4.2.

http://projectliberty.org/liberty/content/download/875/6201/file/ 
liberty-idwsf-disco-svc-v2.0.pdf

I believe grid certificate Subject DN's are considered opaque, unique  
strings, and any individual grid CA mostly has to guarantee global  
uniqueness.  That may not leave much practical benefit to be gained  
from having a representation of a SAML-based name embedded in the  
native fields of a certificate issued by one of these gateways beyond  
to uniquify a DN.  The proposals put forth by all the implementors do  
this.  It's still probably worth formally requiring that a given  
gateway must map a SAML principal to the same DN every time so the  
subject DN is persistent for purposes of gridmap files.

Let me review how this hypothetical land works.  A user hits a grid  
CA carrying a SAML message full of assertions.  The grid CA pulls  
something out of those assertions, attaches it to some other DN  
components it chooses, and mints a new certificate that contains the  
assertions as an extension.  Proxying may happen.

The user may float to applications that rely on the unique DN and a  
gridmap, in which case we've supplied an authorized user with that  
unique DN and we're done.

The user may also float to an application with a grid SP, to which it  
still authenticates using the x.509 certificate.  The grid SP  
detaches the SAML assertions and parses them.  One or more of these  
assertions may in fact be ID-WSF EPR assertions, in which case the  
grid SP queries those EPR's using the associated NameID's as  
invocation identities for additional information.  The grid SP parses  
all the assertions it has, spits out all the attributes it can along  
with the unique DN and NameID's and possibly some other stuff, and  
hands it all to an access control mechanism.  The access control  
mechanism makes an arbitrarily complex decision and we're on our way.

In my hypothetical land, there's no real need to specify how anything  
is done in the x.509 cert except for requiring a unique, persistent  
DN and defining how SAML is bound to the x.509 credential.  There  
might also be a profile of existing SAML/ID-WSF/WS-Sec  
specifications.  Each application can decide whether it wants to rely  
on the DN, SAML NameID, or my DS' subsequent assertion from my secret  
identity #2 that my hair is green.  They're all just attributes.

My hypothetical land is a long ways away.  There may be things to  
converge on before then; namely, how we bootstrap this authentication  
into attributes now.  There's real divergence there, given GridShib  
does queries and wants to move towards attribute push, SLCS uses  
VASH, etc.  But that isn't really authentication and might fit better  
in an overall interoperability effort.

Hope this makes sense, and thanks for reading this far,
Nate.