nameid-format:unspecified for relying party

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

nameid-format:unspecified for relying party

Baron Fujimoto
We have an SP that requires the NameID to be encoded with nameid-format:unspecified.

Currently, our IdP appears to return nameid-format:transient by default. E.g.:

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

We still retain legacy V2 configurations from our upgrade to V3. We have the following uncommented in saml-nameid.properties:

idp.nameid.saml2.legacyGenerator= shibboleth.LegacySAML2NameIDGenerator
idp.nameid.saml1.legacyGenerator= shibboleth.LegacySAML1NameIdentifierGenerator

And this definition in attribute-resolver.xml:

    <resolver:AttributeDefinition xsi:type="ad:TransientId"
            id="transientId">
        <resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier"
                nameFormat="urn:mace:shibboleth:1.0:nameIdentifier" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID"
                nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
    </resolver:AttributeDefinition>

Our saml-nameid.xml includes:

        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
            p:format="rn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"
            p:attributeSourceIds="#{ {'principal'} }" />

The SP's documentation instructs:

"Paste [this] inside the shibboleth.RelyingPartyOverrides elements to override the default configuration for the Shibboleth Identity Provider"

    <bean parent="RelyingPartyByName" c:relyingPartyIds="sp.foo.bar">
    <property name="profileConfigurations">
        <list>
            <bean parent="SAML2.SSO"
             p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified" />
        </list>
    </property>
    </bean>

"The nameIDFormatPrecedence parameter instructs the IDP to send the SAML name ID attribute in the unspecified format"

"Turn off assertion encryption in the Shibboleth Identity Provider by setting the encryptAssertions parameter to false."

    <bean parent="RelyingPartyByName" c:relyingPartyIds="sp.foo.bar">
        <property name="profileConfigurations">
            <list>
                <bean parent="SAML2.SSO"
                    p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"
                    p:encryptAssertions="false" />
            </list>
        </property>
    </bean>

However, I'm not familiar with shibboleth.RelyingPartyOverrides in our configs, so attempted the following in our relying-party.xml:

    <RelyingParty id="sp.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>

But this does not appear to having the desired effect. The SP reports the error "'NAME_ID' not found in SAML response" so perhaps the these RelyingPartyOverrides do not belong in the relying party entry?

Any suggestions would be appreciated.

--
Baron Fujimoto <[hidden email]> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: nameid-format:unspecified for relying party

Boyd, Todd M.
Your saml-nameid.xml appears to have a typo:

        p:format="rn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"

Should be:

        p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"

It's missing the "u" at the beginning of "urn".


-Todd


-----Original Message-----
From: users <[hidden email]> On Behalf Of Baron Fujimoto
Sent: Wednesday, June 27, 2018 4:20 PM
To: Shib Users <[hidden email]>
Subject: nameid-format:unspecified for relying party

We have an SP that requires the NameID to be encoded with nameid-format:unspecified.

Currently, our IdP appears to return nameid-format:transient by default. E.g.:

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

We still retain legacy V2 configurations from our upgrade to V3. We have the following uncommented in saml-nameid.properties:

idp.nameid.saml2.legacyGenerator= shibboleth.LegacySAML2NameIDGenerator
idp.nameid.saml1.legacyGenerator= shibboleth.LegacySAML1NameIdentifierGenerator

And this definition in attribute-resolver.xml:

    <resolver:AttributeDefinition xsi:type="ad:TransientId"
            id="transientId">
        <resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier"
                nameFormat="urn:mace:shibboleth:1.0:nameIdentifier" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID"
                nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
    </resolver:AttributeDefinition>

Our saml-nameid.xml includes:

        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
            p:format="rn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"
            p:attributeSourceIds="#{ {'principal'} }" />

The SP's documentation instructs:

"Paste [this] inside the shibboleth.RelyingPartyOverrides elements to override the default configuration for the Shibboleth Identity Provider"

    <bean parent="RelyingPartyByName" c:relyingPartyIds="sp.foo.bar">
    <property name="profileConfigurations">
        <list>
            <bean parent="SAML2.SSO"
             p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified" />
        </list>
    </property>
    </bean>

"The nameIDFormatPrecedence parameter instructs the IDP to send the SAML name ID attribute in the unspecified format"

"Turn off assertion encryption in the Shibboleth Identity Provider by setting the encryptAssertions parameter to false."

    <bean parent="RelyingPartyByName" c:relyingPartyIds="sp.foo.bar">
        <property name="profileConfigurations">
            <list>
                <bean parent="SAML2.SSO"
                    p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"
                    p:encryptAssertions="false" />
            </list>
        </property>
    </bean>

However, I'm not familiar with shibboleth.RelyingPartyOverrides in our configs, so attempted the following in our relying-party.xml:

    <RelyingParty id="sp.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>

But this does not appear to having the desired effect. The SP reports the error "'NAME_ID' not found in SAML response" so perhaps the these RelyingPartyOverrides do not belong in the relying party entry?

Any suggestions would be appreciated.

--
Baron Fujimoto <[hidden email]> :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: nameid-format:unspecified for relying party

Baron Fujimoto
Doh! That's twice now recently that I've had the list point out my stupid typos. *sigh*

Unfortunately however, despite correcting the typo, it doesn't seem to have had any effect. It still returns

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

saml-nameid.xml:

    <util:list id="shibboleth.SAML2NameIDGenerators">
        <ref bean="shibboleth.SAML2TransientGenerator" />

        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
            p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"
            p:attributeSourceIds="#{ {'principal'} }" />
    </util:list>

Is there anything  that should be set for this in saml-nameid.properties?

"principal" is defined in attribute-resolver.xml with:

    <resolver:AttributeDefinition xsi:type="ad:PrincipalName"
            id="principal" >
        <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID"
                nameFormat="urn:oid:0.9.2342.19200300.100.1.1" />

On Wed, Jun 27, 2018 at 09:25:41PM +0000, Boyd, Todd M. wrote:

>Your saml-nameid.xml appears to have a typo:
>
> p:format="rn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"
>
>Should be:
>
> p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"
>
>It's missing the "u" at the beginning of "urn".
>
>
>-Todd
>
>
>-----Original Message-----
>From: users <[hidden email]> On Behalf Of Baron Fujimoto
>Sent: Wednesday, June 27, 2018 4:20 PM
>To: Shib Users <[hidden email]>
>Subject: nameid-format:unspecified for relying party
>
>We have an SP that requires the NameID to be encoded with nameid-format:unspecified.
>
>Currently, our IdP appears to return nameid-format:transient by default. E.g.:
>
>    <saml2:Subject>
>        <saml2:NameID
>            Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
>            NameQualifier="https://example.edu/idp/shibboleth" SPNameQualifier="sp.foo.bar">AAd...dII</saml2:NameID>
>    </saml2:Subject>
>
>We still retain legacy V2 configurations from our upgrade to V3. We have the following uncommented in saml-nameid.properties:
>
>idp.nameid.saml2.legacyGenerator= shibboleth.LegacySAML2NameIDGenerator
>idp.nameid.saml1.legacyGenerator= shibboleth.LegacySAML1NameIdentifierGenerator
>
>And this definition in attribute-resolver.xml:
>
>    <resolver:AttributeDefinition xsi:type="ad:TransientId"
>            id="transientId">
>        <resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier"
>                nameFormat="urn:mace:shibboleth:1.0:nameIdentifier" />
>        <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID"
>                nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
>    </resolver:AttributeDefinition>
>
>Our saml-nameid.xml includes:
>
>        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
>            p:format="rn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"
>            p:attributeSourceIds="#{ {'principal'} }" />
>
>The SP's documentation instructs:
>
>"Paste [this] inside the shibboleth.RelyingPartyOverrides elements to override the default configuration for the Shibboleth Identity Provider"
>
>    <bean parent="RelyingPartyByName" c:relyingPartyIds="sp.foo.bar">
>    <property name="profileConfigurations">
>        <list>
>            <bean parent="SAML2.SSO"
>             p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified" />
>        </list>
>    </property>
>    </bean>
>
>"The nameIDFormatPrecedence parameter instructs the IDP to send the SAML name ID attribute in the unspecified format"
>
>"Turn off assertion encryption in the Shibboleth Identity Provider by setting the encryptAssertions parameter to false."
>
>    <bean parent="RelyingPartyByName" c:relyingPartyIds="sp.foo.bar">
>        <property name="profileConfigurations">
>            <list>
>                <bean parent="SAML2.SSO"
>                    p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"
>                    p:encryptAssertions="false" />
>            </list>
>        </property>
>    </bean>
>
>However, I'm not familiar with shibboleth.RelyingPartyOverrides in our configs, so attempted the following in our relying-party.xml:
>
>    <RelyingParty id="sp.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>
>
>But this does not appear to having the desired effect. The SP reports the error "'NAME_ID' not found in SAML response" so perhaps the these RelyingPartyOverrides do not belong in the relying party entry?
>
>Any suggestions would be appreciated.
>
>--
>Baron Fujimoto <[hidden email]> :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
>--
>For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
>To unsubscribe from this list send an email to [hidden email]
>--
>For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
>To unsubscribe from this list send an email to [hidden email]

--
Baron Fujimoto <[hidden email]> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: nameid-format:unspecified for relying party

Baron Fujimoto
Still stuck with this. Our deployment is an upgrade from V2 to V3, and I've noted in the upgrade docs

<https://wiki.shibboleth.net/confluence/display/IDP30/UpgradingFromV2#UpgradingFromV2-TheOldSystem>

    [...]
    After upgrading such a system, SPs that were receiving a Name Identifier in particular formats may end up receiving a transient format. This is a clear sign that the original V2 configuration was not correct. Cleaning this up ahead of time will prevent this problem from occurring.

    This problem is particularly common in cases in which the "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" Format was used. The only proper way to configure use of that Format in either V2 and V3 involves the use of the nameIDFormatPrecedence attribute in the relying-party.xml file, so if you don't see this in your configuration, an upgraded system will not produce that type of identifier when you expect it to.

But we don't use deny rules in our attribute filters to supress non-desired formats, so I'm not sure this is applicable.

The SP's metadata does not include <NameIDFormat> elements, so I think this means the IdP should configure a precedence of formats to use with an SP based on a relying party override using the nameIDFormatPrecedence attribute.

If this can't be accomplished with an entry like:

    <RelyingParty id="sp.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>

The vendor's docs suggest an override with the following:

    <bean parent="RelyingPartyByName" c:relyingPartyIds="sp.foo.bar">
        <property name="profileConfigurations">
            <list>
                <bean parent="SAML2.SSO"
                      p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"
                      p:encryptAssertions="false" />
            </list>
        </property>
    </bean>

However, if I add this to relying-party.xml, the IdP throws ans exception:

"The prefix "c" for attribute "c:relyingPartyIds" associated with an element type "bean" is not bound."

So this appears to be a namespace issue? The namespace in our relying-party.xml is:

<RelyingPartyGroup xmlns="urn:mace:shibboleth:2.0:relying-party"
                   xmlns:saml="urn:mace:shibboleth:2.0:relying-party:saml"
                   xmlns:metadata="urn:mace:shibboleth:2.0:metadata"
                   xmlns:resource="urn:mace:shibboleth:2.0:resource"
                   xmlns:security="urn:mace:shibboleth:2.0:security"
                   xmlns:samlsec="urn:mace:shibboleth:2.0:security:saml"
                   xmlns:samlmd="urn:oasis:names:tc:SAML:2.0:metadata"
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:schemaLocation="urn:mace:shibboleth:2.0:relying-party classpath:/schema/shibboleth-2.0-relying-party.xsd
                                       urn:mace:shibboleth:2.0:relying-party:saml classpath:/schema/shibboleth-2.0-relying-party-saml.xsd
                                       urn:mace:shibboleth:2.0:metadata classpath:/schema/shibboleth-2.0-metadata.xsd
                                       urn:mace:shibboleth:2.0:resource classpath:/schema/shibboleth-2.0-resource.xsd
                                       urn:mace:shibboleth:2.0:security classpath:/schema/shibboleth-2.0-security.xsd
                                       urn:mace:shibboleth:2.0:security:saml classpath:/schema/shibboleth-2.0-security-policy-saml.xsd
                                       urn:oasis:names:tc:SAML:2.0:metadata classpath:/schema/saml-schema-metadata-2.0.xsd">

What should be added for "c" here, and are their other entries that whould be included?

Any other tacks to follow or suggestions to debug/troubleshoot this?

On Wed, Jun 27, 2018 at 02:23:29PM -1000, Baron Fujimoto wrote:

>Doh! That's twice now recently that I've had the list point out my stupid typos. *sigh*
>
>Unfortunately however, despite correcting the typo, it doesn't seem to have had any effect. It still returns
>
>    <saml2:Subject>
>        <saml2:NameID
>            Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
>            NameQualifier="https://example.edu/idp/shibboleth" SPNameQualifier="sp.foo.bar">AAd...uTM</saml2:NameID>
>    </saml2:Subject>
>
>saml-nameid.xml:
>
>    <util:list id="shibboleth.SAML2NameIDGenerators">
>        <ref bean="shibboleth.SAML2TransientGenerator" />
>
>        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
>            p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"
>            p:attributeSourceIds="#{ {'principal'} }" />
>    </util:list>
>
>Is there anything  that should be set for this in saml-nameid.properties?
>
>"principal" is defined in attribute-resolver.xml with:
>
>    <resolver:AttributeDefinition xsi:type="ad:PrincipalName"
>            id="principal" >
>        <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID"
>                nameFormat="urn:oid:0.9.2342.19200300.100.1.1" />
>
>On Wed, Jun 27, 2018 at 09:25:41PM +0000, Boyd, Todd M. wrote:
>>Your saml-nameid.xml appears to have a typo:
>>
>> p:format="rn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"
>>
>>Should be:
>>
>> p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"
>>
>>It's missing the "u" at the beginning of "urn".
>>
>>
>>-Todd
>>
>>
>>-----Original Message-----
>>From: users <[hidden email]> On Behalf Of Baron Fujimoto
>>Sent: Wednesday, June 27, 2018 4:20 PM
>>To: Shib Users <[hidden email]>
>>Subject: nameid-format:unspecified for relying party
>>
>>We have an SP that requires the NameID to be encoded with nameid-format:unspecified.
>>
>>Currently, our IdP appears to return nameid-format:transient by default. E.g.:
>>
>>    <saml2:Subject>
>>        <saml2:NameID
>>            Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
>>            NameQualifier="https://example.edu/idp/shibboleth" SPNameQualifier="sp.foo.bar">AAd...dII</saml2:NameID>
>>    </saml2:Subject>
>>
>>We still retain legacy V2 configurations from our upgrade to V3. We have the following uncommented in saml-nameid.properties:
>>
>>idp.nameid.saml2.legacyGenerator= shibboleth.LegacySAML2NameIDGenerator
>>idp.nameid.saml1.legacyGenerator= shibboleth.LegacySAML1NameIdentifierGenerator
>>
>>And this definition in attribute-resolver.xml:
>>
>>    <resolver:AttributeDefinition xsi:type="ad:TransientId"
>>            id="transientId">
>>        <resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier"
>>                nameFormat="urn:mace:shibboleth:1.0:nameIdentifier" />
>>        <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID"
>>                nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
>>    </resolver:AttributeDefinition>
>>
>>Our saml-nameid.xml includes:
>>
>>        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
>>            p:format="rn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"
>>            p:attributeSourceIds="#{ {'principal'} }" />
>>
>>The SP's documentation instructs:
>>
>>"Paste [this] inside the shibboleth.RelyingPartyOverrides elements to override the default configuration for the Shibboleth Identity Provider"
>>
>>    <bean parent="RelyingPartyByName" c:relyingPartyIds="sp.foo.bar">
>>    <property name="profileConfigurations">
>>        <list>
>>            <bean parent="SAML2.SSO"
>>             p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified" />
>>        </list>
>>    </property>
>>    </bean>
>>
>>"The nameIDFormatPrecedence parameter instructs the IDP to send the SAML name ID attribute in the unspecified format"
>>
>>"Turn off assertion encryption in the Shibboleth Identity Provider by setting the encryptAssertions parameter to false."
>>
>>    <bean parent="RelyingPartyByName" c:relyingPartyIds="sp.foo.bar">
>>        <property name="profileConfigurations">
>>            <list>
>>                <bean parent="SAML2.SSO"
>>                    p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"
>>                    p:encryptAssertions="false" />
>>            </list>
>>        </property>
>>    </bean>
>>
>>However, I'm not familiar with shibboleth.RelyingPartyOverrides in our configs, so attempted the following in our relying-party.xml:
>>
>>    <RelyingParty id="sp.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>
>>
>>But this does not appear to having the desired effect. The SP reports the error "'NAME_ID' not found in SAML response" so perhaps the these RelyingPartyOverrides do not belong in the relying party entry?
>>
>>Any suggestions would be appreciated.
>>
>>--
>>Baron Fujimoto <[hidden email]> :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
>>--
>>For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
>>To unsubscribe from this list send an email to [hidden email]
>>--
>>For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
>>To unsubscribe from this list send an email to [hidden email]
>
>--
>Baron Fujimoto <[hidden email]> :: UH Information Technology Services
>minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

--
Baron Fujimoto <[hidden email]> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: nameid-format:unspecified for relying party

Rod Widdowson
> So this appears to be a namespace issue? The namespace in our relying-party.xml is:

You cannot mix and match V2 and V3 relying-party formats.  You want to schedule moving off the V2 format reasonable expeditiously -
if it isn't already it will be deprecated in the next minor release (3.4) and will be entirely unsupported in V4.

People have found that the relying-party syntax much more convenient to use.  

The details of doing the conversion are copiously documented.

/Rod

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: nameid-format:unspecified for relying party

Baron Fujimoto
On Fri, Jun 29, 2018 at 08:18:20AM +0100, Rod Widdowson wrote:

>> So this appears to be a namespace issue? The namespace in our relying-party.xml is:
>
>You cannot mix and match V2 and V3 relying-party formats.  You want to schedule moving off the V2 format reasonable expeditiously -
>if it isn't already it will be deprecated in the next minor release (3.4) and will be entirely unsupported in V4.
>
>People have found that the relying-party syntax much more convenient to use.  
>
>The details of doing the conversion are copiously documented.
>
>/Rod

Updating our legacy V2 configs to V3 is on our TODO list, particularly as
part of our eventual upgrade from 3.2.1. This is a more significant
undertaking than trying to get things working with this one new SP though
since it affects all current SPs we're configured to work with.

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?

--
Baron Fujimoto <[hidden email]> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: nameid-format:unspecified for relying party

Cantor, Scott E.
> 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.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: nameid-format:unspecified for relying party

Baron Fujimoto
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 <[hidden email]> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: nameid-format:unspecified for relying party

Cantor, Scott E.
On 7/2/18, 5:34 PM, "users on behalf of Baron Fujimoto" <[hidden email] on behalf of [hidden email]> 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


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: nameid-format:unspecified for relying party

Cantor, Scott E.
I got back into one of our ArcGIS SPs, and no, there is no field to set the NameID Format. It does not care, does not check, it takes whatever its given and just uses the value. Dumb as a rock, nothing special.

I also should say that I haven't gotten encryption turned on, and I haven't tested it for comment injection bugs. It's been on my list to get around to. It claims to allow encryption but the metadata is spits out has no key, so I don't know if it starts spitting one out if you check the encrypt assertions box or what. I suppose it must.

-- Scott



--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: nameid-format:unspecified for relying party

Cantor, Scott E.
Since both their documentation and the contributed page about ArcGIS were both wrong, I've gone ahead and just redone it with accurate information so far as I know. I have to document all these eventually for myself, so today's as good as any other when it's costing me wasted time correcting them anyway.

https://wiki.shibboleth.net/confluence/display/IDP30/ArcGIS+Online

I haven't used all their features but the original page somebody had done didn't get into the details I don't know about either, so until somebody actually tries encryption or their new multiple IdP federation support, this is about all there is to say.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: nameid-format:unspecified for relying party

Phil Pishioneri
In reply to this post by Cantor, Scott E.
On 7/2/18 7:13 PM, Cantor, Scott wrote:
> It claims to allow encryption but the metadata is spits out has no key, so I don't know if it starts spitting one out if you check the encrypt assertions box or what. I suppose it must.

We happen to be adding ArcGIS to our Shib IdP, too.

I tried enabling 'Encrypt Assertions' -- the metadata their config then
generates includes an encryption certificate (that's the only difference
I see with the box checked vs. not). However, their SP didn't like
getting the encrypted assertion (error: "Unable to login using Idp
Unable to validate SAML response"). And disabling encryption via
relying-party.xml (while the encryption box is still checked) works, so
they're not enforcing encryption when you ask for it.

I've had to disable encryption for now while awaiting an answer from the
vendor (to the question: why does their document show that you can
enable assertion encryption, then farther down tell you to explicitly
disable it?).

-Phil
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: nameid-format:unspecified for relying party

Baron Fujimoto
In reply to this post by Cantor, Scott E.
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" <[hidden email] on behalf of [hidden email]> 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 <https://wiki.shibboleth.net/confluence/display/IDP30/ArcGIS+Online> documentation though.

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

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

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"
            id="ArcGIS_NAME_ID"
            sourceAttributeID="uid">
        <resolver:Dependency ref="LDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2XMLObject"
            name="NAME_ID" />
    </resolver:AttributeDefinition>

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">
    <saml2:Issuer>https://idp.example.edu/idp/shibboleth</saml2:Issuer>
    <saml2:Subject>
        <saml2:NameID
            Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
            NameQualifier="https://idp.example.hawaii.edu/idp/shibboleth" SPNameQualifier="ArcGIS">AAd...oQT</saml2:NameID>
    </saml2:Subject>
    <saml2:AttributeStatement>
        <saml2:Attribute Name="NAME_ID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml2:AttributeValue
                xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">baron</saml2:AttributeValue>
        </saml2:Attribute>
        ...
    </saml2:AttributeStatement>
</saml2:Assertion>

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 <[hidden email]> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: nameid-format:unspecified for relying party

Cantor, Scott E.
> 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

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: nameid-format:unspecified for relying party

Tom Scavo
On Wed, Jul 11, 2018 at 11:01 PM, Baron Fujimoto <[hidden email]> wrote:

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

I don't know if it matters but that metadata is not schema-valid. The
<md:NameIDFormat> element is out of place. Also, its contents should
not be quoted.

Tom
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: nameid-format:unspecified for relying party

Cantor, Scott E.
In reply to this post by Baron Fujimoto
> 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?

Yes, as long as you're not trying to use the one "format that isn't a format" that people keep trying to use that's referenced in the subject line.

> Per your ArcGIS documentation this works as expected.

Being out of position in the metadata tends not to matter as much to the IdP if it's not schema validating, but I would be surprised that quoting it like that worked. That would be an interesting bug.

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

They are equivalent and if you get different results, there's some fact not in evidence that means it isn't using the configuration you think it is.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: nameid-format:unspecified for relying party

Baron Fujimoto
On Thu, Jul 12, 2018 at 01:23:17PM +0000, Cantor, Scott wrote:
>> 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?
>
>Yes, as long as you're not trying to use the one "format that isn't a format" that people keep trying to use that's referenced in the subject line.
>
>> Per your ArcGIS documentation this works as expected.
>
>Being out of position in the metadata tends not to matter as much to the IdP if it's not schema validating, but I would be surprised that quoting it like that worked. That would be an interesting bug.

Argh, sorry, that was an artifact of cutting and pasting various configs while composing the reply.
The actual metadata's NameIDFormat was not quoted. I've also corrected the order for the NameIDFormat element having now found this reference <https://wiki.shibboleth.net/confluence/display/CONCEPT/MetadataForSP> (I didn't find examples of it in situ on the other documentation pages referencing NameIDFormat I'd been using).

>> 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].
>
>They are equivalent and if you get different results, there's some fact not in evidence that means it isn't using the configuration you think it is.

Ok, I suspected that, so that's a useful confirmation. Any suggestions on what to look for to troubleshoot it?

Logs seem to indicate it picks up the relying party entry:

DEBUG [net.shibboleth.idp.relyingparty.impl.DefaultRelyingPartyConfigurationResolver:305] - Checking if relying party configuration arcgis.example.edu is applicable
DEBUG [net.shibboleth.idp.relyingparty.impl.DefaultRelyingPartyConfigurationResolver:307] - Relying party configuration arcgis.example.edu is applicable
DEBUG [net.shibboleth.idp.profile.impl.SelectRelyingPartyConfiguration:136] - Profile Action SelectRelyingPartyConfiguration: Found relying party configuration arcgis.example.edu for request

Relying party:

    <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 resolves and filters attributes:

DEBUG [net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:206] - Attribute Resolver 'ShibbolethAttributeResolver': Final resolved attribute collection: [uid, ...]
DEBUG [net.shibboleth.idp.attribute.filter.impl.AttributeFilterImpl:108] - Attribute filtering engine 'ShibbolethAttributeFilter'  Beginning process of filtering the following 33 attributes: [uid, ...]
DEBUG [net.shibboleth.idp.attribute.filter.AttributeFilterPolicy:125] - Attribute Filter Policy 'ArcGIS'  Checking if attribute filter policy is active
DEBUG [net.shibboleth.idp.attribute.filter.policyrule.filtercontext.impl.AttributeRequesterPolicyRule:54] - Attribute Filter '/AttributeFilterPolicyGroup:ShibbolethFilterPolicy/PolicyRequirementRule:_14ef7b7c3bacb4f701263daa29d7cfdc': Found attribute requester: arcgis.example.edu
DEBUG [net.shibboleth.idp.attribute.filter.AttributeFilterPolicy:132] - Attribute Filter Policy 'ArcGIS'  Policy is active for this request
DEBUG [net.shibboleth.idp.attribute.filter.AttributeFilterPolicy:159] - Attribute Filter Policy 'ArcGIS'  Applying attribute filter policy to current set of attributes: [uid, ...]
DEBUG [net.shibboleth.idp.attribute.filter.impl.AttributeFilterImpl:167] - Attribute filtering engine 'ShibbolethAttributeFilter': 1 values for attribute 'uid' remained after filtering

Encodes filtered attributes and builds AttributeStatement:

DEBUG [net.shibboleth.idp.saml.profile.impl.BaseAddAttributeStatementToAssertion:229] - Profile Action AddAttributeStatementToAssertion: Attempting to add an AttributeStatement to outgoing Assertion
DEBUG [net.shibboleth.idp.saml.saml2.profile.impl.AddAttributeStatementToAssertion:174] - Profile Action AddAttributeStatementToAssertion: Attempting to encode attribute uid as a SAML 2 Attribute
DEBUG [net.shibboleth.idp.saml.saml2.profile.impl.AddAttributeStatementToAssertion:188] - Profile Action AddAttributeStatementToAssertion: Encoding attribute uid as a SAML 2 Attribute
DEBUG [net.shibboleth.idp.saml.attribute.encoding.AbstractSAMLAttributeEncoder:154] - Beginning to encode attribute uid
DEBUG [net.shibboleth.idp.saml.attribute.encoding.SAMLEncoderSupport:73] - Encoding value baron of attribute uid
DEBUG [net.shibboleth.idp.saml.attribute.encoding.AbstractSAMLAttributeEncoder:191] - Completed encoding 1 values for attribute uid
2018-07-12 10:53:36,142 - DEBUG [net.shibboleth.idp.saml.saml2.profile.impl.AddAttributeStatementToAssertion:118] - Profile Action AddAttributeStatementToAssertion: Adding constructed AttributeStatement to Assertion _04f66b8ab9ac05fe23f03c2ae7b885c1

But when it gets to DefaultNameIdentifierFormatStrategy:

DEBUG [net.shibboleth.idp.saml.profile.logic.DefaultNameIdentifierFormatStrategy:102] - No ProfileConfiguraton available (or not an AuthenticationProfileConfiguration)
DEBUG [net.shibboleth.idp.saml.profile.logic.DefaultNameIdentifierFormatStrategy:110] - No formats specified in configuration or in metadata, returning default

It says "No formats specified in configuration" and I wind up with the transient NameID format. Don't the DefaultRelyingPartyConfigurationResolver and SelectRelyingPartyConfiguration logs above show that it should be using the relying-party entry with id="arcgis.example.edu"? If so, is that the correct way to specify the nameIDFormatPrecedence? Not sure what else to look for.

--
Baron Fujimoto <[hidden email]> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: nameid-format:unspecified for relying party

Cantor, Scott E.
On 7/12/18, 11:06 PM, "users on behalf of Baron Fujimoto" <[hidden email] on behalf of [hidden email]> wrote:

> It says "No formats specified in configuration" and I wind up with the transient NameID format. Don't the
> DefaultRelyingPartyConfigurationResolver and SelectRelyingPartyConfiguration logs above show that it should be using > the relying-party entry with id="arcgis.example.edu"? If so, is that the correct way to specify the
> nameIDFormatPrecedence? Not sure what else to look for.

Me either, I don't really see anything there that fits. Either there's a bug or I'm not seeing something, but nobody has identified any bugs I can find in JIRA after all this time. If you're not on the latest version, then that's the next step.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]