nameid-format:unspecified for relying party

Baron Fujimoto baron at hawaii.edu
Mon Jul 2 17:34:04 EDT 2018


On Mon, Jul 02, 2018 at 08:54:33PM +0000, Cantor, Scott wrote:
>> Presumably there should be a way to do this with the legacy V2 relying-party
>> until then? We're still stuck with what may be amiss or how to better
>> troubleshoot it though.  Enabling DEBUG logging on some more specific
>> component?
>
>You do NOT need to support that format. There might be one or two services in the world that actually *care* that it's set to that ridiculous value. I think I ran into one in 15 years.
>
>Use a Format you *want* to use that's correct for the data being passed. It will work 99% of the time.
>
>In either case, and in either version, NameID Format selection is documented and is the same in both versions, relying-party syntax notwithstanding. NameIDPolicy in request, then NameIDFormat in metadata, then nameIDFormatPrecedence in relying-party.xml (this is spelled out in the documentation in both V2 and V3).
>
>If you insist on "unspecified", you need an override and nameIDFormatPrecedence, because that Format does not work with the first two mechanisms. If you don't use that Format, you can set it in the SP's metadata.
>
>That's it.

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

Just to make sure I'm interpreting this right, this is what our
resolvertest generates:

    <saml2:Subject>
        <saml2:NameID
            Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
            NameQualifier="https:/example.edu/idp/shibboleth" SPNameQualifier="foo.bar">AAd...Bww</saml2:NameID>
    </saml2:Subject>

So this <saml2NameID> nameid-format is the property in question, right?
Currently it's transient, and the SP insists on unspecified.

I'm not sure how to fake a NameID format in a resolvertest request, and
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).  I believe, as previously mentioned, option three,
nameIDFormatPrecedence in relying-party.xml.

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

    <RelyingParty id="foo.bar"
            provider="https://example.edu/idp/shibboleth"
            nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"
            defaultSigningCredentialRef="IdPCredential">
        <ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never" encryptNameIds="never" />
    </RelyingParty>

Based on the V2 documetation which states that the RelyingParty element
supports then nameIDFormatPrecedence attribute (a space delimited, ordered
list of name identifier formats).

<https://wiki.shibboleth.net/confluence/display/SHIB2/IdPRelyingParty>

Is this not the right way to do this using a V2 relying party config? If
so, how can I better determine why it is not working? Perhaps it is
falling back to the DefaultRelyingParty? What should I be seeing in the
logs to indicte whether it is using the RelyingParty id="foo.bar" or
perhaps the DefaultRelyingParty? If this is not the right way to configure
it for a V2 relying-party nameid-format, then I don't know what is the
appropriate documetation to reference. Pointers gladly accepted.

[*] <http://enterprise.arcgis.com/en/portal/latest/administer/windows/configure-shibboleth.htm>

-- 
Baron Fujimoto <baron at hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum


More information about the users mailing list