nameid-format:unspecified for relying party
Baron Fujimoto
baron at hawaii.edu
Thu Jun 28 17:49:24 EDT 2018
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 <users-bounces at shibboleth.net> On Behalf Of Baron Fujimoto
>>Sent: Wednesday, June 27, 2018 4:20 PM
>>To: Shib Users <users at shibboleth.net>
>>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 <baron at hawaii.edu> :: 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 users-unsubscribe at shibboleth.net
>>--
>>For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
>>To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>
>--
>Baron Fujimoto <baron at hawaii.edu> :: UH Information Technology Services
>minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
--
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