NameID and EpTID in V3

[Cantor, Scott]

On 1/20/15, 4:07 PM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:



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

Not exactly. In SAML 1.1, there's no way to express this type of 
identifier fully except by using an Attribute. There is nothing outside of 
Shibboleth, SSP, and maybe eduserv stuff that would understand that. And I 
didn't build anything into the NameID generation layer to support that, so 
if people are stuck on SAML 1.1, and need to pass the EPTID attribute, the 
"old" way is still the way.

In SAML 2.0, the right way to send this data is in the NameID. If you 
really had some reason for sending a different NameID, you could, but 
again, I didn't include that except as a compatibility feature.

Sending it in the Subject is intended to be done with the new subsystem. 
The two subsystems use the same code underneath (some of which you worked 
on), so that the same data will be generated either way with the computed 
case.

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

Well, it's horrendously confusing, but maybe a bit less so now that the 
old SAMLxStringNameID encoders are essentially deprecated.

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

That's not related to how the IDs are handled. It's just the 
recommendation period, and no, the recommendation is to *only* send the 
NameID in the Subject. That's always been the recommendation.

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

There's a dedicated generator for Persistents, commented out. You don't 
use the AttributeSourcedGenerator.

-- Scott