nameid-format:unspecified for relying party

[Cantor, Scott]

> Ultimately, I was able to produce something that appears to work. It still
> doesn't seem to be in accordance with the documentation at
> <https://wiki.shibboleth.net/confluence/display/IDP30/ArcGIS+Online>
> documentation though.

I don't know what to say to that except that I guess I don't feel like I should be spending my time creating it if people aren't going to use it. It takes a lot of time that I could be better spending on something more useful.

> Empirically, we appear to require both an appropriate relying party entry:

That's because you're still trying to use that Format, but it isn't even being used because that isn't how you're passing them the data. You should get the same result without it.

> Without the nameid-format specified here, the SP appears to pick up a value
> that looks like a transient id.

Yes, because that's the only way to trigger that Format. Other Formats are possible to handle with metadata.

> And an attribute-resolver definition:

That's the V2 mechanism for producing NameIDs and is deprecated, and that encoder also doesn't produce an actual NameID, it builds a SAML Attribute whose AttributeValue has a NameID element stuffed inside it. I would not expect ArcGIS to understand that, but anything's possible. You most assuredly shouldn't do it, and it has no relationship to the nameIDFormatPrecedence property and the Format selection logic. That's why you're still getting a transient ID in the subject.

> The SP also seems to expect an attribute specifically called NAME_ID, of type
> SAML2NameID, else it complains that no NAME_ID is found.

They may *support* that weird approach but they don't require it. If you keep sending them a transient ID, then no, they're not going to handle that alone and they apparently have some kind of support for attribute access that I didn't run across. I would never deploy a NameID-valued Attribute anyway, so that's not at all a practical alternative that would be "better" than just producing a NameID in the Subject.

> Where the SP appears to use the NameID from the <AttributeStatement>
> and ignores the one in the <Subject>. None of configuration changes in the
> course of experimentation seem to have had any effect on the Subject
> NameID, though I'm not sure if that is expected.

Selecting a Format is only half the work, there has to something in place that provdies that Format either in the resolver in the deprecated fashion or in the saml-nameid.xml config.

-- Scott