nameID selection in v2 legacy mode

[Andrew Morgan]

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

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

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

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

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.

 	Andy