<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 6/18/14 4:06 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CFC769A1.5005B%25cantor.2@osu.edu" type="cite">
<pre wrap="">I realized I still have a pair of basic trust engines hardwired in one of
the Spring files, and I'm loading those into the message handlers that are
doing the authentication work.</pre>
</blockquote>
<br>
You're talking about these in idp-conf, right?:
system/conf/global-system.xml and
system/flows/saml/security-beans.xml<br>
<br>
<br>
<blockquote cite="mid:CFC769A1.5005B%25cantor.2@osu.edu" type="cite">
<pre wrap="">
Brent, I see the SignatureValidationParameters class still has a slot for
a trust engine, but I don't think the handlers would see it, they're using
the one that's set on the handler. </pre>
</blockquote>
<br>
<br>
Yeah, I hadn't removed it yet, even though IIRC we had tentatively
decided to probably not use it at least for the signature-evaluating
message handlers.<br>
<br>
I had thought that it might be nice to provide in the handlers
support for that, and if it's not set, use the one set directly on
the handlers as currently. But I didn't think it was a priority,
since it's unlikely it would get used by anyone.<br>
<br>
<br>
<blockquote cite="mid:CFC769A1.5005B%25cantor.2@osu.edu" type="cite">
<pre wrap="">Plus of course there's no such
parameter set for the TLS client case.
</pre>
</blockquote>
<br>
Right, there's no cert trust engine defined anywhere on the current
security params, nor resolver, etc. <br>
<br>
<blockquote cite="mid:CFC769A1.5005B%25cantor.2@osu.edu" type="cite">
<pre wrap="">
I'd kind of prefer to set the engine using the SecurityConfiguration
somehow, because the natural place to define the engine(s) is inside the
relying-party context where the rest of the security config is done.</pre>
</blockquote>
<br>
Yes, seems natural. Am I inferring then that you think the
preferred way would be to switch gears and use the
SignatureTrustEngine on the SignatureValidationParameters? I'm sure
that's doable in the signature handlers, but in looking at them it's
not as trivial as I'd hoped, because of the way the generic
TrustEngine-oriented superclasses are written.<br>
<br>
Btw, what's the difference between the SecurityConfigurations
defined in system/conf/security-config.xml and
system/conf/relying-party-system.xml? Just noticed that they have
the same bean id (shibboleth.DefaultSecurityConfiguration).<br>
<br>
<br>
<blockquote cite="mid:CFC769A1.5005B%25cantor.2@osu.edu" type="cite">
<pre wrap="">
Should that be our goal here, or should I just find a way to define them
elsewhere?
</pre>
</blockquote>
<br>
<br>
I could go either way I guess. Standardizing on the
SignatureValidationParameters and having it live with the other
security config does make a certain kind of sense. Of course, in
reality, as we had already discussed, it's probably unlikely anyone
would ever use anything other than the global ones based on
metadata.<br>
<br>
<br>
</body>
</html>