Regex in attribute-filter.xml

[Cantor, Scott]

> After upgrading our IdP to 3.2.1, we noticed some AFPs in the legacy
> attribute-filter.xml are not working as expected. For example, the following
> configuration releases eduPersonEntitlement values that begin with “abcde”
> in IdP2 but releases ALL entitlement values in the IdP3:

I don't believe that but I would need to see the overall policy.

However:

> And this configuration releases ALL values of eduPersonAffiliation rather
> than “employee” only:
> 
> <basic:Rule attributeID="eduPersonAffiliation" value=“employee”
> xsi:type="basic:AttributeValueString"/>

That doesn't mean what you think it means. You're not creating a value permit rule based on the employee value there. You're creating a rule that says "if the attribute contains the value employee, then release the value I'm evaluating". That value doesn't have to be employee. Typically that kind of rule is applied as a policy requirement condition, not as a value rule.

That is a mistake, and the IdP's behavior before was at best accidental and at worst actually wrong.

> We understand that following configurations work:
> 
>   <AttributeRule attributeID="eduPersonEntitlement">
>         <PermitValueRule xsi:type="ValueRegex" regex="^abcde.*$" />
>   </AttributeRule>

Isn't that what you posted above, just with the simpler function type expression? There's likely something more subtle going on given that your other example is just incorrectly applied.

>   <AttributeRule attributeID="eduPersonAffiliation">
>         <PermitValueRule value="employee" xsi:type="Value"/>
>   </AttributeRule>

That is most certainly NOT the same as what you posted above and doesn't mean the same thing.

> However, at UCLA we have over 700 AFPs and lots of them have
> configurations like above. We were wondering if there are ways to make the
> legacy configurations work while we make the changes.

I would say your rules are in fact wrong in a large number of cases then.

-- Scott