Scoped attribute not passing SP filter

Peter Schober peter.schober at
Thu Feb 21 08:16:24 EST 2013

* Joep Driesen <Joep.Driesen at> [2013-02-21 14:07]:
> 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>
> </saml2:Attribute>
> 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>
> </saml2:Attribute>

OK, so what makes a scoped attribute lies with the SP's decoding
rules (since the scope is provided "inline" as part of the xsi:string
value, not as seperate "scope" XML attribute). And you're already
using a ScopedAttributeDecoder in the map.

> I'm not quite sure which class I should set to DEBUG on the SP side. If already tried 
> log4j.category.Shibboleth.AttributeFilter=DEBUG
> and
> log4j.category.OpenSAML.MessageDecoder=DEBUG
> but neither made the value of the NewAttribute show up in the logs.

  log4j.rootCategory=DEBUG, shibd_log, warn_log

should be a safe bet, 2nd line in /etc/shibboleth/shibd.logger
But we already have the XML above, so you could only be looking for
other steps in the process,

More information about the users mailing list