nameid-format:unspecified for relying party

[Cantor, Scott]

On 7/2/18, 5:34 PM, "users on behalf of Baron Fujimoto" <users-bounces at shibboleth.net on behalf of baron at hawaii.edu> wrote:

> Until our attempts to interoperate with this new SP (ArcGIS[*], FWIW) we
> never had to deal with this before. As you said, it just worked.
> Apparently they are in the 1%?

No. We use ArcGIS and it most assuredly does NOT care what the Format is. No way, no how. And nothing you posted or said would provide any evidence that it does. Sending a transient ID obviously isn't going to work, that's not a Format issue, it's a "the account ID isn't in the XML" issue. They don't care what the Format is. Period. If they do, it's purely a matter of filling it into their configuration form, but I don't think they even ask that much. I got my access removed and need to get it back, so I can't check it at the moment first hand.

But I know for absolute fact I'm using two different Formats with two different instances of it, and neither one is that Format. I in fact have *no* usage of that Format, not a single one.

> Currently it's transient, and the SP insists on unspecified.

No, it doesn't. Their documentation is wrong. All vendor documentation is wrong. That is a working assumption that is true the vast majority of the time. I'm sorry for that, but it isn't my fault.
 
> I'm not sure how to fake a NameID format in a resolvertest request,

There is nothing to fake, the normal mechanisms for format selection are not request driven. That's an edge case, and not even an advisable one. Your problem is that your URN constant is wrong, which I point out below.

> their metadata does not include a NameIDFormat (though, given and example
> of what it should look like, I'm willing to hack on in for testing
> purposes).

You are inherently forced to create, manage, and maintain all cloud service metadata, because to do anything else is impossible, their metadata is garbage the vast majority of the time. And it can never, ever, be relied on remotely for various reasons.

So NameIDFormats are a trivial thing to manage when you create the metadata anyway, that's why it's the suggested way to do it, it's just the easiest way to get the result you want.

>  I believe, as previously mentioned, option three,
> nameIDFormatPrecedence in relying-party.xml.

That is only needed when using "unspecified", which you don't need, but...

> The V2 relying-party entry for this SP currently looks like:

That is not the constant in SAML for "unspecified", it's "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" and that's likely the sum total of your problem, two simple characters in the string not matching.

-- Scott