nameID selection in v2 legacy mode

[Cantor, Scott]

On 12/28/15, 6:11 PM, "users on behalf of Andrew Morgan" <users-bounces at shibboleth.net on behalf of morgan at orst.edu> 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

Yes.

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

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