nameid-format:unspecified for relying party

[Baron Fujimoto]

On Tue, Jul 10, 2018 at 12:43:41PM +0000, Cantor, Scott wrote:
>> 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.

Since I had something that appeared to work before seeing that documentation, I was mostly operating along the lines of "if it ain't broke..." Your response was persuasive though that it probably was broke, or at least liable to break, so I am now using the documented method. Thank you very much for providing it.

Am I misunderstanding though that I should be able to specify the NameIDFormat via a RelyingParty override rather than specifying it in the SP's metadata?

Per your ArcGIS documentation this works as expected.

I have the following in saml-nameid.xml:

   <!-- SAML 2 NameID Generation -->
    <util:list id="shibboleth.SAML2NameIDGenerators">

        <ref bean="shibboleth.SAML2TransientGenerator" />

        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
            p:format="urn:oid:0.9.2342.19200300.100.1.1"
            p:attributeSourceIds="#{ {'uid'} }" />

    </util:list>

The attribute definition for uid in attribute-resolver.xml:

    <!-- uid -->
    <resolver:AttributeDefinition xsi:type="ad:Simple"
            id="uid"
            sourceAttributeID="uid">

        <resolver:Dependency ref="LDAP" />

        <resolver:AttributeEncoder xsi:type="enc:SAML1String"
                name="urn:mace:dir:attribute-def:uid" />

        <resolver:AttributeEncoder xsi:type="enc:SAML2String"
                name="urn:oid:0.9.2342.19200300.100.1.1"
                friendlyName="uid" />

    </resolver:AttributeDefinition>
    <!-- /uid -->

NameIDFormat specified in the ArcGIS metadata:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="arcgis.example.edu">
    <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">
        <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://arcgis.example.edu/portal/sharing/rest/oauth2/saml/signout"/>
        <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://arcgis.example.edu/portal/sharing/rest/oauth2/saml/signin" index="1"/>
        <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://arcgis.example.edu/portal/sharing/rest/oauth2/saml/signin" index="2"/>
        <md:NameIDFormat>"urn:oid:0.9.2342.19200300.100.1.1"</md:NameIDFormat>
    </md:SPSSODescriptor>
    <md:Organization xml:lang="en">
        <md:OrganizationName xml:lang="en">ArcGIS Enterprise</md:OrganizationName>
        <md:OrganizationDisplayName xml:lang="en">ArcGIS Enterprise</md:OrganizationDisplayName>
        <md:OrganizationURL xml:lang="en">https://arcgis.example.edu/portal</md:OrganizationURL>
    </md:Organization>
</md:EntityDescriptor>

However, if instead I do not include the NameIDFormat element in the metadata, but instead use a nameIDFormatPrecedence attribute in the ArcGIS relying-party entry such as:

    <RelyingParty id="arcgis.example.edu"
            provider="https://idp.example.edu/idp/shibboleth"
            nameIDFormatPrecedence="urn:oid:0.9.2342.19200300.100.1.1"
            defaultSigningCredentialRef="IdPCredential">
        <ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never" encryptNameIds="never" />
    </RelyingParty>

It generates a transient format NameID in the Subject once again. The documentation I'm using as references 
describes the RelyingParty nameIDFormatPrecedence attribute as "A space delimited, ordered list of name identifier formats" [1] and the logic (I think) to select the NameIDFormat [2][3].

[1] <https://wiki.shibboleth.net/confluence/display/SHIB2/IdPRelyingParty>
[2] <https://wiki.shibboleth.net/confluence/display/IDP30/UpgradingFromV2#UpgradingFromV2-TheOldSystem>
[3] <https://wiki.shibboleth.net/confluence/display/SHIB2/IdPNameIdentifier> 

I don't know what I'm missing, misuing, or misunderstanding here.

>> Empiricallyurn:oasis:names:tc:SAML:1.1:nameid-format:unspecified, 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.

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