<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 10:08 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CF18655B.8619%25cantor.2@osu.edu" type="cite">
<pre wrap="">On 2/5/14, 9:58 PM, "Cantor, Scott" <a class="moz-txt-link-rfc2396E" href="mailto:cantor.2@osu.edu"><cantor.2@osu.edu></a> wrote:
</pre>
<pre wrap="">
Correct me...
I think what you're saying is that the idea was that the
SecurityConfiguration.get*Configuration() interfaces are supposed to be
the static settings applied via the RelyingParty configuration (syntax
TBD).</pre>
</blockquote>
<br>
If I understand you: yes. The ones at that level essentially define
the RelyingParty/ProfileConfiguration-specific overrides of
security-related defaults defined elsewhere (defined at possibly at
multiple levels) - unless it's data/component where a default
doesn't make sense, in which case it's just the effective thing for
the RP/profile.<br>
<br>
<br>
<blockquote cite="mid:CF18655B.8619%25cantor.2@osu.edu" type="cite">
<pre wrap="">
Then some kind of Resolver thing takes that interface + metadata + ? and
produces a -Parameters object that contains the effective settings, and
that's what should be used to drive
signing/encryption/validation/decryption.</pre>
</blockquote>
<br>
Exactly. <br>
<br>
<blockquote cite="mid:CF18655B.8619%25cantor.2@osu.edu" type="cite">
<pre wrap="">
If so, my concern is partly in not having to derive those mid-stream
inside the profile actions (we should do it once, and then hang that off
the context somewhere),</pre>
</blockquote>
<br>
Yes, like I mentioned in the other note, same idea as we do for
metadata resolution. Do it once and store.<br>
<br>
<br>
<blockquote cite="mid:CF18655B.8619%25cantor.2@osu.edu" type="cite">
<pre wrap=""> and partly that the code looks kind of backwards
to me. I would think you'd want the final Parameters exposed via
interface, because then the resolver can produce an
implementation-specific object to expose them to the runtime.
</pre>
</blockquote>
<br>
That I don't really see. At that point a -Parameters is literally
just a bean of values. I mean, it could be an interface, sure, but
I don't really see any use case for multiple impls of -Parameters.
-Configuration on the other hand is totally unknown. There could be
many of them throughout a system, and each could be
wired/configured/bootstrapped in a totally different way, hence the
possibility of multiple impls.<br>
<br>
<br>
<blockquote cite="mid:CF18655B.8619%25cantor.2@osu.edu" type="cite">
<pre wrap="">
Whereas a lot of the current ProfileConfiguration classes are pretty much
just simple structure classes with get/set methods, which matches the
current -Parameters classes.</pre>
</blockquote>
<br>
The impls specifically on the ProfileConfiguration may in fact wind
up as just simple bean impls. But they're not the only impls or use
of that interface. I think the latter is the part that is throwing
you off. A given -Resolver specific to the IdP might consume for
example: 1) the RP-specific -Configuration from ProfileConfiguration
2) the IdP-wide default -Configuration 3) the OpenSAML library
default -Configuration. 4) metadata 5) other stuff TBD.<br>
<br>
Or another possible way to do it is that the ProfileConfiguration
one is not a simple bean; it incorporates knowledge of the others in
some sort of delegate-to-parent way and hands back the "closest"
level that has a value for a given property. Then the -Resolver
just combines that one smart -Configuration with metadata to produce
the effective -Parameters.<br>
<br>
Or maybe there's another yet another way. That uncertainty and
range of impl choices is the reason why it is an interface.<br>
<br>
<br>
</body>
</html>