nameID selection in v2 legacy mode

Cantor, Scott cantor.2 at
Mon Dec 28 19:24:10 EST 2015

On 12/28/15, 6:11 PM, "users on behalf of Andrew Morgan" <users-bounces at on behalf of morgan at> wrote:

>When Xfinity identified the problem with their SP, they suggested we send
>a persistent NameID containing the EPPN.  We do that for a couple other 
>services, so I tried to implement that in the same way.

"Persistent" would mean a pairwise, opaque value, you would never use that format with something like EPPN unless you were very deliberately choosing to never support a targeted ID. Never, ever, ever use a single format to mean different things for different SPs. That is total madness. Push back, scream, kick, bite, but never do that.

>I don't need clusterable IDs because we do not support artifacts or
>attribute query.  How do I switch back to the old transientID format?  Is 
>it as simple as setting:
>idp.transientId.generator = shibboleth.StoredTransientIdGenerator


But they have a bug. I'll take the blame for the fact that "transient" has too few constraints on it in SAML (length, charset) but not allowing 256 bytes and any legal XML character is pretty much a non-starter for any SP.

>I don't see where I can set the Storage Service for it (in-memory would be 

It's not exposed at the moment, at least without just outright overriding a system bean.

>Should I remove all of my transientID handling in attribute-filter.xml?

I don't think there's anyway for those rules to affect anything now, but I would have to think about it. You'd have to have the new transient ID generator plugin disabled I think.

-- Scott

More information about the users mailing list