Function use in the IdP

[Brent Putman]

On 11/15/14 4:16 PM, Rod Widdowson wrote:
>> I
>> hope to have details for injectable Functions in OpenSAML and
>> Predicates in both by Monday at the latest.

Correct me if I'm wrong, but:  Isn't this thread about scripted versions
of Functions and Predicates, for use in things like the attribute
resolver?   If not, then I'm not 100% clear how/where these would be
used, so perhaps you can clarify.

But:


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


All 3 of the uses of Functions above are really configuration-time
things, not really changeable or pluggable at runtime.

In the case of the MetadataResolver one, you literally can't change it
after the resolver is inited, the setter enforces that.  For the
Template- (and MetadataQueryProtocol-) request URL builders, the
functions are constructor args, so you'd have build a new one URL
builder - but then you can can't inject it into the resolver because of
the afore-mentioned resolver setter.

The signature validation filter doesn't technically have such a
restriction enforced in code, but it wouldn't be safe to change it.  In
checking: The only reason that that filter isn't an initializable
component is historical - none of the filters are.  Maybe we should
change that.  But the point is, you can't safely change it in a runtime
script.

So, you'd only change any of these by tweaking the configuration.  I'm
not seeing how scripting is of relevance there.  But correct me if I'm
misunderstanding.

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20141117/029fa24c/attachment.html