<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 2/5/14 9:58 PM, Cantor, Scott wrote:<br>
</div>
<blockquote cite="mid:CF186053.85F1%25cantor.2@osu.edu" type="cite"><br>
<pre wrap="">
I assumed because they were interfaces exposed via ProfileConfiguration
that the point was for the profile actions to consume those interfaces.</pre>
</blockquote>
<br>
No, not at all. The point of having on the ProfileConfiguration was
to hold the RP/profile-specific settings, if any. These get
combined with (lets say, this is TBD) library defaults and
configured IdP global defaults (which themselves are *also*
represented by other instances of -Configurations), and other inputs
(e.g. metadata-based algo stuff where appropriate). All goes into a
mixing bowl (the -Resolver) which produces a -Parameters instance
that actually gets used at runtime. I realize that that is not
really clear, because that combining/resolution process and
components is the stuff that we don't have yet. (Some of that TBD
stuff might be general enough to go into OpenSAML, but a lot of the
concrete impl is probably IdP-specific, in terms of the -Resolver
impls and using IdP-defaults and ProfileConfiguration and so on).<br>
<br>
<blockquote cite="mid:CF186053.85F1%25cantor.2@osu.edu" type="cite">
<pre wrap="">
I don't really grasp the difference between the -Configuration interfaces
and the -Parameters classes, which seem like they overlap.</pre>
</blockquote>
<br>
Yes, the properties are similar and overlap because the idea is that
the -Parameters are mostly produced from, amongst other things, the
-Configuration (+ other inputs like metadata + logic).<br>
<br>
<br>
<blockquote cite="mid:CF186053.85F1%25cantor.2@osu.edu" type="cite">
<pre wrap="">
Whatever we do, what I'm going for is that the actions shouldn't have to
call into any further code to derive the signing/encryption settings to
use. </pre>
</blockquote>
<br>
Exactly, that's exactly what the -Parameters are for. Those are the
things that the actions know about, nothing else. The actions
consume the computed -Parameters which are resolved in the above TBD
way. There will of course be one or more Actions which invoke the
-Resolver(s) to produce the -Parameters. That's conceptually
similar to what we do for example with metadata - we have one
Action/MessageHandler which resolves the metadata *once* and then it
gets consumed by other components. Same general idea.<br>
<br>
<br>
<blockquote cite="mid:CF186053.85F1%25cantor.2@osu.edu" type="cite">
<pre wrap="">That should be what's exposed on the
ProfileConfiguation.getSecurityConfiguration().get*() methods. So that's
how I thought those interfaces were meant to work, that those were the
*effective* options to use.</pre>
</blockquote>
<br>
No, literally the other way around. -Parameters represent the
derived/computed *effective* values that are used by runtime
components. -Configuration represents the "static" config (and
there would likely be more than one "level" of a -Configuration) .
-Configuration(s) combined with resolution/computation/derivation
logic in a -Resolver produces a -Parameters instance.<br>
<br>
Honestly, I thought the choice of the terms "parameters" and
"configuration" was intuitive, but I guess not. :-)<br>
<br>
<br>
<pre wrap="">
</pre>
<blockquote cite="mid:CF186053.85F1%25cantor.2@osu.edu" type="cite">
<pre wrap="">They seem
to have the same fields, just one an interface and one a class.</pre>
</blockquote>
<br>
And the reason for the class/interface difference is that:
-Parameters are effective values produced by a resolver. It's just
a simple bean that holds values, so it really doesn't make sense to
have an interface.<br>
<br>
-Configuration on the other hand is going to appear in many places
in the actual system. The nature of those is/was unknown in advance
(to me at least), so it made more sense to have an interface to
avoid being locked into assumptions about how those will actually be
implemented. For example, the ProfileConfiguration one may in fact
just be a simple bean (in our Basic- impl style) that gets populated
in some way, but the OpenSAML library default one might be a
different impl that just has hardcoded defaults, or that reads from
a classpath resource, etc.<br>
<br>
<br>
<br>
<blockquote cite="mid:CF186053.85F1%25cantor.2@osu.edu" type="cite">
<blockquote type="cite">
<pre wrap="">
2) explicitly reconceive Decrypter as an instance-per-use class that is
constructed with DecryptionParameters.
Still thinking on it, but slightly leaning at the moment to #2, since
it's more parallel with the way the Encrypter works as a instance-per-use
component (at least the SAML subclass does).
</pre>
</blockquote>
<pre wrap="">
I would generally prefer #2, and I guess I assumed it since that's how I
coded the action for the time being.</pre>
</blockquote>
<br>
<br>
Ok. I would at least for the time being change the code to use
DecryptionParameters just to avoid confusion. <br>
<br>
<br>
<blockquote cite="mid:CF186053.85F1%25cantor.2@osu.edu" type="cite">
<pre wrap="">
</pre>
<pre wrap="">
I don't think in practice you see much call for different validation
behavior per relying party. I've never supported that in the SP and it's
never really come up.</pre>
</blockquote>
<br>
Yeah, that's mostly what I thought. I was only considering it
because it was a logical consequence of the way the -Parameters had
been defined. As I mentioned in the MessageContext notes, it was
just an idea to support a dynamic TrustEngine, which I think takes
only a couple lines of code.<br>
<br>
<br>
<blockquote cite="mid:CF186053.85F1%25cantor.2@osu.edu" type="cite">
<pre wrap=""> It's the generation side (signing/encryption) where
there's substantial need for variability.</pre>
</blockquote>
<br>
Yes, of course.<br>
<br>
<br>
<br>
</body>
</html>