nameID selection in v2 legacy mode
morgan at orst.edu
Mon Dec 28 18:11:20 EST 2015
On Mon, 28 Dec 2015, Cantor, Scott wrote:
> 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
> 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?
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.
However, I'd be perfectly happy to send a transientID in the old format.
> 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
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
I don't see where I can set the Storage Service for it (in-memory would be
>> 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 was blocking transientID in v2 to force NameID selection. I didn't
realize at the time that I was doing it the wrong way. It made sense in
v2 because NameID were just attributes with special encoding. I
understood how to control attribute release. I wasn't aware of the actual
Should I remove all of my transientID handling in attribute-filter.xml?
>> 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.
Ah, my bad for copying some stale configuration. The resolver originally
encoded as persistent, but I pasted in a transient encoding that I was
using later when earlier steps failed. My original configuration (that
didn't work) was using a persistent encoding.
>> 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.
Good! That makes sense, so I can tell them they are crazy to ask for a
different NameID format.
>> 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.
Thanks for clarifying all this.
More information about the users