Scoped attribute not passing SP filter

Joep Driesen Joep.Driesen at
Thu Feb 21 08:07:12 EST 2013

> Turn the IdP's (or the SP's, since you seem to control both?) logging
> up to DEBUG and look at the actual XML representation of the attribute.
> (Or disable encryption, then you can grab it from the browser in
> transit, e.g. using Olav's SAML tracer plugin for Firefox).
> Any PHP at the SP won't give you additional info compared to the SP's
> log files.
> Also the SP's Session handler at /Shibboleth.sso/Session already has
> all that info readily available in your browser (other than that the
> same as above applies here, of course).
> -peter

I only directly control the SP, though I am in constant contact with the IdPs administrator.
We already looked at the IdP logs and the result was:

<saml2:Attribute FriendlyName="NewAttribute" Name="" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
         <saml2:AttributeValue xmlns:xs="" xmlns:xsi="" xsi:type="xs:string">000000000 at</saml2:AttributeValue>

It looks exactly the same as the other scoped attributes in the log, which do work:

<saml2:Attribute FriendlyName="eduPersonPrincipalName" Name="urn:oid:" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
         <saml2:AttributeValue xmlns:xs="" xmlns:xsi="" xsi:type="xs:string">00000000000000000 at otherscope</saml2:AttributeValue>

I'm not quite sure which class I should set to DEBUG on the SP side. If already tried 


but neither made the value of the NewAttribute show up in the logs.


More information about the users mailing list