Scoped attribute not passing SP filter

[Peter Schober]

* Joep Driesen <Joep.Driesen at icts.kuleuven.be> [2013-02-20 11:34]:
> <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" />

Btw, don't do that. WHatever you invent is not assigned in the
urn:mace:dir:attribute-def namespace. You can't just make up values
there.

> 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>

That's already part of the default attribute-policy.xml, right?

> <afp:AttributeRule attributeID="NewAttribute">
>             <afp:PermitValueRuleReference ref="ScopingRules"/>
> </afp:AttributeRule>

You did also map the attribute name used on the wire to "NewAttribute"
in the attribute-map.xml, yes? (Otherwise you'd have an "unmapped"
WARN in the SP's log.)
-peter