[Question or BUG] Attributes name_format is always URI if they are unspecified from idp, even if specified in sp conf options

Even if I configure an sp as follow

            'requested_attribute_name_format': saml2.saml.NAME_FORMAT_BASIC,
            'name_format': saml2.saml.NAME_FORMAT_BASIC,

the AuthnResponse.assertions[0].attribute_statement[N].attribute[N] name_format will be urn:oasis:names:tc:SAML:2.0:attrname-format:uri by default.

I saw also this: https://github.com/IdentityPython/pysaml2/blob/master/src/saml2/config.py#L245

It seems that requested_attribute_name_format is used only for metadata production, I got it, but name_format what is it for? If the IDP response have unspecified attributes identifiers format as follow

 <saml:AttributeStatement>
      <saml:Attribute Name="spidCode">
        <saml:AttributeValue xsi:type="xs:string">9ebc256045-9a08-3196-66e1-ce9522c4a04c</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="name">
        <saml:AttributeValue xsi:type="xs:string">Morell</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="familyName">
        <saml:AttributeValue xsi:type="xs:string">Guy</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="fiscalNumber">
        <saml:AttributeValue xsi:type="xs:string">TINIT-THATHEX</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="email">
        <saml:AttributeValue xsi:type="xs:string">[e-mail]</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>

in this case the SP will try to match these with a URI format (urn:oasis:names:tc:SAML:2.0:attrname-format:uri) and not with ‘name_format’ specified in conf (‘urn:oasis:names:tc:SAML:2.0:attrname-format:basic’).

Is there any additional implementation considerations about this issue or should we think it as a bug?

[c00kiemon5ter]

Hello everyone,

there is no name_format. What there is though is name_form. This is probably what you are looking for. https://github.com/IdentityPython/pysaml2/blob/61f51b0/example/idp2/idp_conf.py.example#L104 https://github.com/IdentityPython/SATOSA/blob/0ddf568/example/plugins/frontends/saml2_frontend.yaml.example#L49

What the spec says, is that if one does not define a value for the NameFormat attribute of the Attribute element, then consumers should assume that the value is urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified.

When we set a configuration option we are doing the opposite; we are the producers and we are setting the value that we want. Having NAME_FORMAT_URI as the default is a convention of the library; it has nothing to do with a violation of the spec. NAME_FORMAT_URI is widely used, and that is why it is the default value of the NameFormat attribute for the Attribute elements when those are produced.

The bug is that even when we consume an Attribute element with no NameFormat attribute, the assumed NameFormat is NAME_FORMAT_URI. This is wrong and we should change it (this will be a breaking change.)

Here are the two test cases. They articulate the wanted behaviour. I think this is what we should aim for. Do you agree? If you disagree would you think that even for producing the Attribute element we should default to unspecified?

import saml2
import saml2.saml


# this is working and I think we should preserve this behaviour
def test_attribute_producer_should_default_to_uri():
    attr = saml2.saml.Attribute()
    assert attr.name_format == saml2.saml.NAME_FORMAT_URI


# this fails, as the assumed `NameFormat` is NAME_FORMAT_URI - we must fix this
def test_attribute_consumer_should_default_to_unspecified():
    attr_str = """
      <saml:Attribute Name="uid" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:AttributeValue xsi:type="xs:string">test</saml:AttributeValue>
      </saml:Attribute>
    """
    attr = saml2.create_class_from_xml_string(saml2.saml.Attribute, attr_str)
    assert attr.name_format == saml2.saml.NAME_FORMAT_UNSPECIFIED

[c00kiemon5ter]

fixed by #704