Implement wildcard support in attribute filter

I have done this so I’m resolving it. I’m assigning this to scott so he can check it does what he expects. In particular it is worth eyeballing the new test (because it’s weird)

This behavior can (of course) be changed but….

The use case is that an SP may want to allow any and all “ordinary” decoded attributes into the SP without having to enumerate them in a policy saying “just allow everything for that attribute”. The old SP does that with a wildcard in an attribute rule’s ID.

If policies don’t apply to a request, then that’s ok, they didn’t apply so whatever their rules were doesn’t matter.

I would argue if a policy fails and we can tell that, that probably ought to be fatal or possibly we just treat that as “preventing” this option from applying at the end. So it would only apply if all the policies at least “worked”, whether they applied or not.

If this is just not workable, then we can just not do it. But I don’t want to do wildcards again, that was a hack.

So basically we are saying a big switch

• Behave like now (only explictly allowed attributes and their values are included) or

• For every input attribute:

  • If it has been subject to an AttributeRule inside an AttributeFilterPolicy where the Requirement rule was met.

    • Include all the attribute values we allowed (like now)

    • And remove the attribute from the set if there are no values associated (like now)

  • Otherwise include all the attribute values.

    • Note that this means that its quite possible that an attribute will be full released if a Policy rule returns FALSE (on indeed fails)

I think my problem is that I don’t understand the use case.

I don’t think this should be anywhere in the XML at all, that’s the whole problem. The multiple policies and all make that untenable IMHO.

I think we should do what I thought up, add a flag about it to the filter context and have the caller control the default behavior. I add fields to contexts in minor updates all the time.

Of Note

• The code will easily support multiple <DefaultFilterPolicy> elements, Does that make sense?

• The code will easily support <PolicyRequirementRule> inside <DefaultFilterPolicy>. Does that make sense?

• We will be adding a method to the API level class AttributeFilterWorkContext I am not sure whether the version rules allow us to do this.

  • We can program around it in the API code by having a WorkContextEx which extends the work context and looking for it.

• We will be adding a new object DefaultFilterPolicy (and possibly a shared-with AttributeFilterPolicy base class) to the api tree. I am not sure in my head whether the version rules allow us to do that

  • We can fix that by making them impl for 5.2 and moving them back out to API in 6.0