fix: attrValueMapper fails to parse complex AttributeValue tags (#245)

[dfdeagle47]

Context

This fixes an issue where the attrValueMapper would fail to properly map the value for complex AttributeValue tags. This handles the case where the AttributeValue contains a nested NameID tag.

One such example is the eduPersonTargetedID that is used as an identifier in eduGAIN which can return an Attribute of the form

<saml2:Attribute FriendlyName="eduPersonTargetedID" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
  <saml2:AttributeValue>
    <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="https://idp.example-university.fr/idp/shibboleth" SPNameQualifier="https://www.service-provider.com/shibboleth">a6c2c4d4-08b9-4ca7-8ff9-43d83e6e1d35</saml2:NameID>
  </saml2:AttributeValue>
</saml2:Attribute>

Limitations

Note that in reality, the AttributeValue tags can be much more complex. The Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 uses the following schema for the Attribute tag:

<element name="Attribute" type="saml:AttributeType"/>
<complexType name="AttributeType">
  <sequence>
    <element ref="saml:AttributeValue" minOccurs="0" maxOccurs="unbounded"/>
  </sequence>
  <attribute name="Name" type="string" use="required"/>
  <attribute name="NameFormat" type="anyURI" use="optional"/>
  <attribute name="FriendlyName" type="string" use="optional"/>
  <anyAttribute namespace="##other" processContents="lax"/>
</complexType>

and the following schema for the AttributeValue:

<element name="AttributeValue" type="anyType" nillable="true"/>

which means it can take any type.

As pointed out in this issue, it is customary to use NameQualifier and the SPNameQualifier in addition to the actual value to create a unique identifier for the platform. That is why the AttributeValue is mapped to an object containing the attribute of the NameID tag as well as the string value for eduPersonTargetedID that is stored in the Value property.

Additional information regarding the fix

• The attrValueMapper is extracted to the SAML prototype to make it easier to test and it is renamed to attributeValueMapper to make it more explicit.
• Tests have been added to check that it correctly handles the use case where the AttributeValue contains a nested NameID tag.
• Previously, the attrValueMapper would return undefined for this use case. Now, it returns an object where Value is the nested string value and the tag attributes are properties of that object.

Related PRs and issues

This should close the following PRs (although the mapping is different):

• Fixing NameID value mapping #246
• Add support nested NameID in attribute value #249

This should close the following issue:

• attrValueMapper fails to parse complex AttributeValue tags #245

[dfdeagle47]

I still have to fix one issue before merging.

Edit: should be fixed now. I had an incorrect change in this PR because I'm trying to make it compatible for 0.35.x, but I added up making a separate commit on another branch starting from 0.35.0.

[cjbarth]

Since #245 is closed, should this be closed too @dfdeagle47 ?

[dfdeagle47]

@cjbarth

Since #245 is closed, should this be closed too @dfdeagle47 ?

Looks like it does, thanks for the update.

You might want to look at those PRs as well:

• Fixing NameID value mapping #246
• Add support nested NameID in attribute value #249

because they seem to be fixing the same issue.