nameid-format:unspecified for relying party

Baron Fujimoto baron at
Tue Jul 10 00:00:36 EDT 2018

On Mon, Jul 02, 2018 at 11:02:53PM +0000, Cantor, Scott wrote:
>On 7/2/18, 5:34 PM, "users on behalf of Baron Fujimoto" <users-bounces at on behalf of baron at> 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.

It seems that the vendor documentation is indeed wrong. Yes, not your fault, nor anyone but the vendor's. But even if that's a reasonable working assumption the majority of the time, such documentation is usually the starting point for those of us tasked with making these things work. And when it is wrong, the burden of proof for demonstrating that's the case falls on us.

The care and feeding of our IdP is just one of my responsibilities but I'm not steeping in IdP matters constantly; I don't have the deep expertise that affords me the ability to recognize or assert that provided references are defective without counterfactual support.

I understand that participation on the list is voluntary and no one is compelled to assist anyone here. That said, it's the best resource currently at our disposal. I try to RTFM and do my due diligence when seeking advice, but I'm very open to suggestions to improving our requests here. 

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

FWIW, this thread has been helpful. Aside from pointing out the errors in the vendor's documentation, it convinced me to not rely on their documentation for a solution.

Ultimately, I was able to produce something that appears to work. It still doesn't seem to be in accordance with the documentation at <> documentation though.

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

    <RelyingParty id="ArcGIS"
        <ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never" encryptNameIds="never" />

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

And an attribute-resolver definition:

    <resolver:AttributeDefinition xsi:type="ad:SAML2NameID"
        <resolver:Dependency ref="LDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2XMLObject"
            name="NAME_ID" />

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

And of course, an attribute-filter policy to release "NAME_ID".

This results in a resolver test like the following:

<?xml version="1.0" encoding="UTF-8"?>
<saml2:Assertion ID="_2fee1473c2d24c469141193d9694d1d8"
    IssueInstant="2018-07-10T03:38:18.856Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
            NameQualifier="" SPNameQualifier="ArcGIS">AAd...oQT</saml2:NameID>
        <saml2:Attribute Name="NAME_ID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                xmlns:xsi="" xsi:type="xsd:string">baron</saml2:AttributeValue>

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.

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

More information about the users mailing list