Function use in the IdP

[Rod Widdowson]

> it's probably easiest to just add a new scripted
> Function<MessageContext, Object> and be done with it.

I've just added this.  Or more accurately, I have widen the base
implementation and added more factory methods to generate targeted
ScriptedPredictaes for PRC and for MessageContext

> I
> hope to have details for injectable Functions in OpenSAML and
> Predicates in both by Monday at the latest.

It turns out that this was quite easy. I grepped OpenSAML looking for
setters for Functions which took as inputs neither MessageContexts nor a
PRC.

It turns out that there are only three, all in metadata processing:

	SignatureValidationFilter can take an injected Function<XMLObject,
Set<String>>.  This is used "for extracting dynamic trusted names from
signed metadata elements.".  It strikes me that anyone who wants to override
PKIX in JavaScript deserves everything they get, but I suppose we might
provide such a function?

	FunctionDrivenDynamicHTTPMetadataResolver can take an injected
Function<String, String> to construct the URL from the provided EntityID.
It strikes me that this might usefully be scripted, however we already
provide the TemplatedRequestURLBuilder (which is the third consumer of an
inject Function<String, String>) and so we may have this base covered?

Moving finally on to Predicates, as far as I can see the only use (apart
from metadata aggregator) of Predictate<T> in a setter, where T is not a PRC
is in attribute consent, where we inject a Predicate<Attribute>.  This
setter is not exposed in the user configuration, rather it is hard wired in
system.  It seems to me that while it might be interesting to allow scripted
selection of attributes, at this stage in our discovery of how consent will
work we are better off keeping everything hidden (and thus unsupported) in
system.

Rod