Attributes and Predicates

Rod Widdowson rdw at steadingsoftware.com
Mon May 5 09:16:13 EDT 2014


Now that the discussions for relying-party are on their way to being
bottomed out I thought I should go back to case IDP-280.  This case is about
adding the required configuration to attribute-resolver.xml to allow
activation control of attribute and data connector definitions ("don't fire
up this LDAP connector for this sort of request").

The case has seen some discussion between Scott and myself and the bottom
line is that we really want to align this with the rest of the configuration
and allow the injection of a Predicate<ProfileRequestContext>.  As discussed
on Friday the profile configurations have control via such predicates, as do
several other elements.

The code is currently written in terms of a
Predicate<AttributeResolutionContext> and so my intention is to allow
injection of a Predicate<ProfileRequestContext> and have an injectable
Function<ProfileRequestContext, AttributeResolutionContext> to allow the
requisite composition.  

By injecting a Predicate<ProfileRequestContext> we make for commonality and
there is a good chance that deployers will be able to reuse much of the
code.

However in considering this it did strike me that there is currently no
ability to allow injection of a Predicate<ProfileRequestContext> into an
attribute filter.  If we believe that there will be commonality of
Predicates used across all areas configuration then it seems to wrong to not
allow such predicates in attribute filtering.  I imagine that we will not be
adding much, if any, new function in adding this since the filter language
is pretty rich; but surely it has to be a good idea to allow a user to use
one mechanism across an entire installation to do something?

To that end, I propose adding a new filter type to allow this sort of
configuration.

Thoughts?

/R



More information about the dev mailing list