Shibboleth Developer's Meeting, May 24, 2013

...

Refactoring idp-attribute-filter-api, looks like a return to v2, with some differences. Not sure why v3 diverged originally, let us avoid design regressions.

Be deliberate when changing API artifacts. Special svn notifications ?

Continue to refactor "MatchFunctor" to "Matcher" and its evaluatePolicyRule(AttributeFilterContext) to matches(AttributeFilterContext).

Q : "What does a Matcher do?"
A : " A Matcher matches might (1) match an attribute filter context ) and it gets matching values (for and/or (2) get values of an attribute in the context)"attribute filter context which match the Matcher.

As mentioned in Javadoc, a base AbstractMatcher class could require concrete implementations to provide just getMatchingValues(), since a default matches() implementation could iterate over the Attributes in the AttributeFilterContext and return true the first time getMatchingValues() returns a non-empty set. Not optimal, of course.

So, MatchFunctor might exist in the schema only.

As mentioned on a previous dev call, for consistency, I thing "filtering" should be refactored to "filter" in Java class and package names, and the AttributeFilteringEngine should become AttributeFilter. To match the AttributeResolver maybe AttributeFilterer is more appropriate, but no.

Readlock on AttributeFilterService.filterAttributes() ?

Change the schema too ?

Topics

Decisions

Coding convention : getLdapUrl or getLDAPURL ?

...