Attribute mapping sometimes failing in SP 3

[Spencer Thomas]

Given the stanzas below from attribute-map.xml, I would expect either of those attributes to be mapped to “persistent-id” for transmission to the protected application.

    <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" id="persistent-id">
        <AttributeDecoder xsi:type="NameIDAttributeDecoder" formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="true"/>
    </Attribute>

    <Attribute name="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" id="persistent-id">
        <AttributeDecoder xsi:type="NameIDAttributeDecoder" formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="true"/>
    </Attribute>

Instead, I *sometimes* see errors such as this in shibd.log

2020-04-10 11:26:04 INFO Shibboleth.AttributeExtractor.XML [1040] [default]: skipping unmapped SAML 2.0 Attribute with Name: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

But not always, because there are transactions that do include a “persistent-id” value.  Given that the two Attribute elements above are the only ones that can produce “persistent-id”, I suppose there is some difference between the way in which the attributes are presented that is keeping them from being mapped for some IDPs.

Here are messages from shib.log for one that fails
2020-04-10 11:26:04 INFO Shibboleth.AttributeExtractor.XML [1040] [default]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:0.9.2342.19200300.100.1.1
2020-04-10 11:26:04 WARN Shibboleth.AttributeDecoder.NameID [1040] [default]: AttributeValue was not of a supported type and contains no child elements
2020-04-10 11:26:04 INFO Shibboleth.AttributeExtractor.XML [1040] [default]: skipping unmapped SAML 2.0 Attribute with Name: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
2020-04-10 11:26:04 INFO Shibboleth.SessionCache [1040] [default]: new session created: ID (_f7f0f68b8adcfd59e592b32f2399c32e) IdP (xxx) Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (x.x.x.x)

And one that succeeds (with no errors preceding the “new session created” log):

2020-04-10 15:38:35 INFO Shibboleth.SessionCache [1050] [default]: new session created: ID (_d641f839e8e4bf906911c60216510d27) IdP (xxxx) Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (x.x.x.x)

I suspect the AttributeDecoder error is why it’s not mapping.

So questions:

  1.  Can I get shibd to log the full attribute values to help with diagnosis?
  2.  What do I need to suggest to the IdP admin so they can provide the attribute in format that works?
  3.  OR, how do I change the attribute mapping so it will work for them?

Thanks.


--
Spencer Thomas
Technical Architect / JSTOR and Artstor
ITHAKA<https://www.ithaka.org/> / 301 E. Liberty St, Suite 250, Ann Arbor, MI 48104
Email: Spencer.Thomas at ithaka.org<mailto:Spencer.Thomas at ithaka.org>
Voicemail: 734-887-7004




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200410/660e11a6/attachment.html>