<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 11/15/14 4:16 PM, Rod Widdowson
wrote:
</div>
<blockquote cite="mid:000201d00119$69246f30$3b6d4d90$@com"
type="cite">
<blockquote type="cite">
<pre wrap="">I
hope to have details for injectable Functions in OpenSAML and
Predicates in both by Monday at the latest.
</pre>
</blockquote>
</blockquote>
<br>
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.<br>
<br>
But:<br>
<br>
<br>
<blockquote cite="mid:000201d00119$69246f30$3b6d4d90$@com"
type="cite">
<pre wrap="">
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?</pre>
</blockquote>
<br>
<br>
<blockquote cite="mid:000201d00119$69246f30$3b6d4d90$@com"
type="cite">
<pre wrap="">
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?
</pre>
</blockquote>
<br>
<br>
All 3 of the uses of Functions above are really configuration-time
things, not really changeable or pluggable at runtime.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
</body>
</html>