Skipping unmapped SAML 2.0 attribute, even though name and nameFormat match

samlshibboleth

SP running Shibboleth 2.5.6. For one particular IdP, I have these attribute mappings:

<Attribute name="role"
    nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
    id="role" />
<Attribute name="urn:mace:dir:attribute-def:givenName"
    nameFormat="urn:mace:shibboleth:1.0:attributeNamespace:uri"
    id="givenName" />

I receive a wire message containing:

<AttributeStatement>
    <Attribute Name="role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Educator</AttributeValue>
    </Attribute>
    <Attribute Name="urn:mace:dir:attribute-def:givenName" NameFormat="urn:mace:shibboleth:1.0:attributeNamespace:uri">
        <AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">intraguest</AttributeValue>
    </Attribute>
</AttributeStatement>

Which logs:

Shibboleth.AttributeExtractor.XML : creating mapping for Attribute role, Format/Namespace:urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified
Shibboleth.AttributeExtractor.XML : creating mapping for Attribute urn:mace:dir:attribute-def:givenName
...
DEBUG Shibboleth.AttributeDecoder.String [1]: decoding SimpleAttribute (role) from SAML 2 Attribute (role) with 1 value(s)
INFO Shibboleth.AttributeExtractor.XML [1]: skipping unmapped SAML 2.0 Attribute with Name: urn:mace:dir:attribute-def:givenName, Format:urn:mace:shibboleth:1.0:attributeNamespace:uri

Why is givenName skipped, when its name and nameFormat match?

I note that the Format/Namespace comment is missing from the "creating mapping" log line for givenName, but I presume that's because the given nameFormat matches the default.

Update:

The IdP is a PingFederate source, whose metadata claims to SAML 2. Here is the relevant excerpt from the meta-data:

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="..." entityID="...">
    <md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:mace:dir:attribute-def:givenName" NameFormat="urn:mace:shibboleth:1.0:attributeNamespace:uri"/>
        <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"/>
    </md:IDPSSODescriptor>
</md:EntityDescriptor>

Best Answer

We were having the same issue. Apparently Shibboleth cannot mix the formats of SAML 1 and SAML 2. You have to use them as follows (https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAddAttribute):

  • SAML 1:
    • urn:mace:shibboleth:1.0:attributeNamespace:uri (default)
    • If you want to map an attribute with another format (but not a SAML 2 format), you have to specify it in the attribute mapping using the nameFormat attribute.
  • SAML 2:
    • urn:oasis:names:tc:SAML:2.0:attrname-format:uri (default)
    • urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified (default)
    • If you want to map an attribute with another format (but not a SAML 1 format), you have to specify it in the attribute mapping using the nameFormat attribute.

So the problem you are having is that you receive a SAML 2 message with an attribute using a SAML 1 format and that is not supported by Shibboleth, even if you explicitly tell Shibboleth to use the SAML1 format using the nameFormat attribute.

We solved the problem by asking the PingFederate IdP team to send us the attributes using the SAML 2 "urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" format (because that is apparently a format that is easy to support in PingFederate). In our attribute mapping, we do not use the nameFormat attribute because this format is a default of Shibboleth.

I hope this helps you solve the problem.