<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 4/22/14 11:29 AM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CF7C014A.4D40B%25cantor.2@osu.edu" type="cite">
<pre wrap="">On 4/22/14, 9:42 AM, "Rod Widdowson" <a class="moz-txt-link-rfc2396E" href="mailto:rdw@steadingsoftware.com"><rdw@steadingsoftware.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Thus it seems to me that the only sensible use of a <sec:TrustEngine>
inside
relying-party.xml is as (legacy) input to <metadata:SignatureValidation>.
</pre>
</blockquote>
<pre wrap="">
Yeah, unless we build a service around the trust engines I guess, so we
can get at them in those message handler beans and actions. From a
compatibility standpoint, there's not much point to that because the
current config that would have overridden the runtime trust handling was
those policy rules, and if we don't support those, there's no
compatibility with having made such changes anyway.
</pre>
</blockquote>
<br>
<br>
Sounds right to me.<br>
<br>
<br>
<br>
<blockquote cite="mid:CF7C014A.4D40B%25cantor.2@osu.edu" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Unfortunately it doesn't mean that I don't have to be able to parse all
variants since I'm guessing that it's perfectly acceptable to have
arbitrarily complex trust engines associated with a metadata filter.
</pre>
</blockquote>
<pre wrap="">
Yeah, I think so.
</pre>
</blockquote>
<br>
Yes, I think so too.<br>
<br>
<br>
<blockquote cite="mid:CF7C014A.4D40B%25cantor.2@osu.edu" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">OTOH if we do want to define all trust engines inside relying-party.xml
then
it should not be too difficult to teach the beans inside
security-beans.xml
to lookup up trust engines via a Service. However I will note that in V2
these trust engines are all contained below the <!-- DO NOT EDIT BELOW
THIS
POINT --> mark.
</pre>
</blockquote>
<pre wrap="">
Yeah, see above. I think it doesn't really buy us anything but we do have
to settle on where to put those trust engine beans as consumed by the
security handler beans in terms of what people would be able to change
safely.
</pre>
</blockquote>
<br>
<br>
<br>
I *think* this may be the "thing that Chad wanted to with splitting
out the security stuff to its own Spring (parent) context, and that
none of us can remember". It was essentially about making
TrustEngines visible to things that were in v3 going to live in
different layers. I think we've abandoned that idea. If we need to
support common access to the same trust engine beans, etc, sounds
like we indeed are leaning to a Service model.<br>
<br>
<br>
<br>
<blockquote cite="mid:CF7C014A.4D40B%25cantor.2@osu.edu" type="cite">
<pre wrap="">
My inclination is that we'll do it with native Spring in a user-space file
that wouldn't generally get touched, but could in edge cases, and we'll
feed a fixed bean ID into the handlers. The handler beans in
security-beans.xml are meant to be hands off because if you want to
customize that, you'd override the subflow being invoked and be
responsible for your own beans (by copying from that file probably).
</pre>
</blockquote>
<br>
<br>
Not having to repeat the config for that case would be nice, but if
it's too hard to support, then I suppose the duplication isn't
really a big deal. But thinking to the next step/question: all the
trust engine beans for the message handlers essentially have to get
injected with a MetadataCredentialResolver or
MetadataPKIXValidationInformationResolver, which in turn take either
a MetadataResolver or a RoleDescriptorResolver. Where does that
come from in the new layout, and is that a problem?<br>
<br>
<br>
<br>
</body>
</html>