Scoped attribute not passing SP filter

[Rod Widdowson]

Guess:  did you update the IdP's metadata at the SP to add in the extra
scope?

> -----Original Message-----
> From: users-bounces at shibboleth.net [mailto:users-
> bounces at shibboleth.net] On Behalf Of Joep Driesen
> Sent: 20 February 2013 10:34
> To: users at shibboleth.net
> Subject: Scoped attribute not passing SP filter
> 
> Hi Everybody,
> 
> We are trying to release a new scoped attribute from one of our
federations’
> IdPs.  To this end we added the following
> code to the IdPs attribute-resolver.xml:
> 
> <resolver:AttributeDefinition id="NewAttribute" xsi:type="Scoped"
> xmlns="urn:mace:shibboleth:2.0:resolver:ad"
>                               scope="kuleuven.be"
sourceAttributeID="SourceAttribute">
>         <resolver:Dependency ref="myLDAP" />
> 
>         <resolver:AttributeEncoder xsi:type="SAML1ScopedString"
> xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
>            
                       name="urn:mace:dir:attribute-def:NewAttribute" />
> 
>         <resolver:AttributeEncoder xsi:type="SAML2ScopedString"
> xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
>            
                       name="urn:mace:kuleuven.be:dir:attribute-
> def:NewAttribute" friendlyName="NewAttribute" />
> </resolver:AttributeDefinition>
> 
> We also updated the attribute-filter.xml to release the attribute, and
added
> a line to the metadata to enable this IdP to use the ‘kuleuven.be’ scope:
> 
> <EntityDescriptor entityID="IdPEntityID">
>        <IDPSSODescriptor
> protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol
> urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0">
>        <Extensions>
>        <shibmd:Scope regexp="false">otherscope</shibmd:Scope>
>        <shibmd:Scope regexp="false">kuleuven.be</shibmd:Scope>
>        </Extensions>
>       …
> 
> On the IdPs side, everything seems ok, the IdP release the attribute
correctly
> as we have confirmed by
> inspecting the logs.
> 
> Next we configured a test SP to receive this new attribute. Adding a rule
to
> the attribute-policy.xml:
> 
> <afp:PermitValueRule id="ScopingRules" xsi:type="AND">
>         <Rule xsi:type="NOT">
>             <Rule xsi:type="AttributeValueRegex" regex="@"/>
>         </Rule>
>         <Rule xsi:type="saml:AttributeScopeMatchesShibMDScope"
> xmlns:saml="urn:mace:shibboleth:2.0:afp:mf:saml"/>
> </afp:PermitValueRule>
> 
> <afp:AttributeRule attributeID="NewAttribute">
>             <afp:PermitValueRuleReference ref="ScopingRules"/>
> </afp:AttributeRule>
> 
> Now according to the SP logs, the attribute is successfully received. The
> problem is that it is filtered out by the SPs filtering policy:
> 
> 2013-02-20 11:19:16 DEBUG Shibboleth.AttributeFilter [3]: applying
filtering
> rule(s) for attribute (NewAttribute) from (IdPEntityID)
> 2013-02-20 11:19:16 WARN Shibboleth.AttributeFilter [3]: removed value at
> position (0) of attribute (NewAttribute) from (IdPEntityID)
> 
> It seems the scope is not properly applied. When I change the SPs filter
to
> only allow values containing an ‘@’, the attribute passes just fine. We
are
> releasing other attributes that are scoped with
> the ‘otherscope’ defined in our attribute-filter.xml, and these are also
> passing the SPs filter without a problem. I can’t find a difference
between
> the old attributes that work and the new attribute that doesn’t
> anywhere…
> 
> Can anyone spot any obvious errors here, or tell me other places I could
look
> for configuration mistakes?
> 
> Thanks!
> Joep