Function use in the IdP

[Cantor, Scott]

On 11/11/14, 5:26 PM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:



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

I'm more in favor I think of having an alternate constructor, because 
making it required sort of adds complexity to deployer use of the scripted 
option, when the target there is people trying to avoid Java code. I 
appreciate that it does add safety, but it's not as though people should 
be doing scripts without a little testing, and once they work they work. 
The feedback should be pretty immediate if it's wrong.

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

I don't think I follow that, exactly. I guess it's generic, yes, but if 
the surrounding code is being told to call a function with some kind of 
FooContext, that's going to be the value passed into the function's 
apply() method, not a PRC. Or are you suggesting we modify the existing 
function code to check the type and walk the tree as needed to get to the 
PRC?

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

No, don't think so, it's already built to let the user customize that 
using the configuration.

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

The MRP stuff is mostly just speculative at this stage, other than where I 
used it in logout, so I wouldn't worry about it much.

-- Scott