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

<Attribute name="role"
    id="role" />
<Attribute name="urn:mace:dir:attribute-def:givenName"
    id="givenName" />

I receive a wire message containing:

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

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.


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"/>
  • 1
    Is the IDP passing you saml2 attributes and you are mapping 1?
    – Sum1sAdmin
    Jul 19, 2016 at 10:31
  • @Sum1sAdmin We're wanting to map SAML2, and the IdP claims SAML2, but its meta-data shows this 1.0 NameFormat uri. Which, to me, is odd. See update.
    – bishop
    Jul 19, 2016 at 13:24

1 Answer 1


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .