Attributes and Predicates

[Cantor, Scott]

> 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").

Along with Encoders too. That solves the problem of needing to encode things with custom names for a particular vendor, without having to duplicate more configuration and do discrete attribute release policies just for that case.

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

We can, but I would note that what you typically *really* want is to indirect the access to particular *data*, not the contexts. For example, a predicate to evaluate the identity of the SP/RP is something that we need, and the real indirection there is to that name, not to the context from which it is read.

In other words, you can plug in a function to read the RP identity from the ARC, or from the RPC if that's somehow "better" in some isolated case. But it's really getting that identity that we want to make pluggable. This is easy to do with function composition.
 
> 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?

I'm open to it, but I didn't want to have to reopen the whole can of worms around having all that custom code in the filter engine. Over time I think it will largely drop away in favor of reimplementation on top of predicates, but that isn't crucial right now.

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

Meaning it just wraps the use of a predicate? That's fine.

-- Scott