Function use in the IdP

[Rod Widdowson]

There is a todo item to look and see whether we could usefully add any more
scripted Functions or Predicates.

I picked this up as an opportunity to get to poke into some corners of the
code where I haven't been recently.  It actually turns out that this
involved a lot of reading, so I'll just start with one corner: those parts
of java-identity-provider which can have an injected Function.

We start by knowing that there is a ScriptedFunction which implements
Function<ProfileRequestContext, Object>.  

Before we go any further I'd like to suggest that we give this a mandatory
constuctor argument, being a Class.  Then we can test the output of the
script against that class and output a more helpful error message than an
arbitrary ClassCastException at some later stage during processing.

Anyway, armed with ScriptedFunction we can immediately ignore every injected
Function which takes any type of Context as input, since we know how to
navigate contexts to get to the ProfileRequestContext. 

This cuts down the search significantly and leave us with these 4 areas:

1) Services:  To build a Service you need a Function<ApplicationContext,
ServiceableComponent< ?>.  This code is so very specialized and to do with
Spring that if you need this Function you are already writing Java and so it
can be ignored.

2) Webflow:
net.shibboleth.idp.profile.context.navigateSpringEventToViewLookupFunction
implements Function<Event,String>.  There is no way anybody would want to
script this fundamental navigation mechanism.  Or would they?  Advanced
error handling?

3) Attribute Consent and Interceptor &c :  Primarily this uses Functions to
calculate hashes: 
   Function<Collection<IdPAttributeValue<?>>, String> hashFunction
   Function<String, String> hashFunction
It also uses Functions for display purposes: Function<IdPAttribute, String>
It feels like all three of these might be useful if available Scripted, but
I'd defer to Tom for that.

4) This only leaves us with RelyingPartyContextLookupById which implements
Function<Pair<MultiRelyingPartyContext,String>, RelyingPartyContext>.  I
don't see this used anywhere but I could vaguely imagine some Action whose
configuration builds such a Pair.  But would not such a configuration be
working from a ProfileRequestContext anyway, and we have a plug point to
replace this further up?

Next up will probably be OpenSAML, I know already that there is a rich set
of classes for getting SAMLObjects out of various things and also mining
SAMLObjects for other Objects, but until I emerge at the end of that spelunk
I'm not sure what the recommendation will be.

/Rod