NameID and EpTID in V3

Rod Widdowson rdw at steadingsoftware.com
Tue Jan 20 11:07:50 EST 2015


I'm just trying to get my mind straight about what our recommendations for
users will be in V3.  I think that I may just be splitting hairs, but my
brain has been polluted by the V2 way of doing things and shows a startling
desire to explode when I think about this for too long.

In V3 we have separated NameID from attributes and having read through the
doc and configs I'm pretty much convinced that this will makes it easier for
everyone. 

IIRC, since a long time ago the recommended way to ship EpTID around is as a
<saml2:NameID>.  Of course the value in this NameID is not necessarily (and
usually isn't) the same as the NameID in the <saml2:Subject>. 

The standard way of doing this is to code up a SAML2NameID attribute and
source it from a suitable connector.  This is also fine.

My question is what will our recommendations be for people who want to use
stored IDs.  

Am I correct to assume that in this case the usual expected behaviour is
that the two NameIDs be the same (to allow a one shot invalidation of a
user)?   

If so what do we think our recommended configuration? It will obvious *not*
be the "SAML2StringNameID" encoder, but will we recommend that the NameID be
set up as shibboleth.SAML2AttributeSourcedGenerator (using the same
attribute we plug into the SAML2NameID attribute) or as a
shibboleth.ComputedPersistentIdGenerator, using the same PersistentIdStore?
Does this matter?

/Rod



More information about the dev mailing list