Attribute mapping on new SP3 install

Peter Schober peter.schober at
Wed May 15 07:37:56 EDT 2019

* HCUK eLearning <daveperryatwork at> [2019-05-15 12:54]:
>         <saml2:Attribute FriendlyName="eduPersonScopedAffiliation"
>             Name="urn:oid:"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
>             <saml2:AttributeValue>Staff at
> </saml2:AttributeValue>
>         </saml2:Attribute>

Including the scoped affiliation in the example was helpful (since the
logs show that this was processed successfully by the SP): It's scope
is all lower-case (which I'd always recommend for sanity) -- though
the affiliation value is not, which I'd suggest to also lowercase.

>         <saml2:Attribute FriendlyName="eduPersonPrincipalName"
>             Name="urn:oid:"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
>             <saml2:AttributeValue>70012521 at
> </saml2:AttributeValue>
>         </saml2:Attribute>

Here the scope is not all lower-case, which is the mistake.

> 2019-05-15 10:32:04 WARN Shibboleth.AttributeFilter [1] [default]: removed
> value at position (0) of attribute (eppn) from (
> 2019-05-15 10:32:04 WARN Shibboleth.AttributeFilter [1] [default]: no
> values left, removing attribute (eppn) from (

And so attributes with a scope of "" are being
filtered out.

> From the IdP Metadata:
> <shibmd:Scope regexp="false"></shibmd:Scope>

The only explanation for the SPs behaviour -- and the solution to that
mystery -- is that this is wrong: The scope in metadata is all

Contextual remark going forward: If keeping the casing of the scope
consistent within the LDAP direcory is difficult maybe you should
through away the scope from LDAP when loading it into the IDP and add
it consistently again within the IDP?


More information about the users mailing list