nameID selection in v2 legacy mode
Cantor, Scott
cantor.2 at osu.edu
Mon Dec 28 17:39:29 EST 2015
On 12/28/15, 5:01 PM, "users on behalf of Andrew Morgan" <users-bounces at shibboleth.net on behalf of morgan at orst.edu> wrote:
>
>Anyways, I've been trying to force a different NameID value for their SP,
>but I always get some transientID.
You have me pretty confused with all the mixed and strange directives here.
What is your goal? A transient or not? A transient that looks like it used to? A non-transient ID with actual data in it?
If you want the old transients back and don't need clusterable IDs, you can just change the generation strategy it's using to the in-memory variant.
>and updated my filters to block transientID and release the NameID:
You don't ever need to block transient (before or now) and it has no effect in V3 anyway, transients always come from the new code, never the resolver, no matter what other settings are involved. It's one change that's universal.
>I removed the "unspecified" NameIDFormat from their metadata and even set
>an override in relying-party.xml:
Your override has a different format in it. Perhaps what you posted has some typo'd values. I was going by strictly what you posted. If you're clear about what you want, it's easier to describe how to do it.
>But I can't seem to get around the fact that their SAML request asks for
>transient:
That is mandated by SAML, yes, that can't be overridden. So that explains that.
>Am I stuck until they fix their SP? Thoughts?
I don't know exactly what the full scope of your requirements are. Changing the transient generation strategy might work, but only if you don't need them reversible across nodes (i.e. query support).
You can pretty much ignore the resolver and the idea of a custom NameID format here, their request precludes that.
-- Scott
More information about the users
mailing list