<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 10/21/16 3:43 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A5BB9D@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<pre wrap="">I found the relevant classes in the SOAP client and see the general gist of it,</pre>
</blockquote>
<br>
FYI, I just checked in the similar HTTP metadata resolver (batch and
dynamic) changes per OSJ-142, so that's another couple of examples,
and probably closer to what you'd have if you aren't resolving from
a context tree, etc. They just take an injected parameters
instance. Shortly I'll see if I can do up the HTTPResource per
JSE-16.<br>
<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A5BB9D@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<pre wrap=""> my question I guess is whether I need to do anything in the short term for 3.3 to make any of that stuff usable from Spring, or whether it's at least theoretically possible to do with brute force?</pre>
</blockquote>
<br>
All you really need to do as far as code is:<br>
<br>
1) have an available instance of HttpClientSecurityParameters
(injected, resolved, whatever)<br>
<br>
2) marshall the params to the per-request HttpClientContext that you
build, with the support method like so:<br>
<br>
<tt>HttpClientSecuritySupport.marshalSecurityParameters(context,
httpClientSecurityParameters, true);<br>
</tt><br>
3) Immediately after you invoke the client execute(), invoke the
support method that sanity checks that the TLS trust engine eval was
actually done, if applicable, like so:<br>
<br>
<tt>HttpResponse response = httpClient.execute(request, context);</tt><tt><br>
</tt><tt>HttpClientSecuritySupport.checkTLSCredentialEvaluated(context,
request.getURI().getScheme());</tt><tt><br>
</tt><br>
Technically #3 is optional, but since there is "distance" between
the component that wields the params and the wiring support that
utilizes them (below), it's probably always a good idea as a sanity
check against what is wired in the HttpClient. Unfortunately there's
no way to introspect the client and determine directly.<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A5BB9D@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<pre wrap="">
If I just inject HttpClient and an instance of HttpClientSecurityParameters as an API, can I assume it's possible to wire in a TLS trust engine and a certificate to validate without a lot of extra wiring?</pre>
</blockquote>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A5BB9D@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
</blockquote>
<br>
Yes, pretty much. The trust engine goes into the parameters
instance that you would inject.<br>
<br>
The only wiring or other requirement is that you have to be using an
instance of HC that is configured with the TLS socket factory(s)
that support those custom context parameters.<br>
<br>
I just typed that requirement into the resolver Javadocs, so I'll
just cut/paste here:<br>
<br>
<br>
<tt> /**</tt><tt><br>
</tt><tt> * Set an instance of {@link
HttpClientSecurityParameters} which provides various parameters to
influence</tt><tt><br>
</tt><tt> * the security behavior of the HttpClient instance.</tt><tt><br>
</tt><tt> * </tt><tt><br>
</tt><tt> * <p></tt><tt><br>
</tt><tt> * For all TLS-related parameters, must be used in
conjunction with an HttpClient instance </tt><tt><br>
</tt><tt> * which is configured with either a:</tt><tt><br>
</tt><tt> * <ul></tt><tt><br>
</tt><tt> * <li></tt><tt><br>
</tt><tt> * a {@link
net.shibboleth.utilities.java.support.httpclient.TLSSocketFactory}</tt><tt><br>
</tt><tt> * </li></tt><tt><br>
</tt><tt> * <li></tt><tt><br>
</tt><tt> * {@link
org.opensaml.security.httpclient.impl.SecurityEnhancedTLSSocketFactory}
which wraps</tt><tt><br>
</tt><tt> * an instance of {@link
net.shibboleth.utilities.java.support.httpclient.TLSSocketFactory},
with</tt><tt><br>
</tt><tt> * the latter likely configured in a "no trust"
configuration. This variant is required if either a</tt><tt><br>
</tt><tt> * trust engine or a client TLS credential is to be
used.</tt><tt><br>
</tt><tt> * </li></tt><tt><br>
</tt><tt> * For convenience methods for building a </tt><tt><br>
</tt><tt> * {@link
net.shibboleth.utilities.java.support.httpclient.TLSSocketFactory},
</tt><tt><br>
</tt><tt> * see {@link
net.shibboleth.utilities.java.support.httpclient.HttpClientSupport}.</tt><tt><br>
</tt><tt> * </ul></tt><tt><br>
</tt><tt> * If the appropriate TLS socket factory is not
configured and a trust engine is specified,</tt><tt><br>
</tt><tt> * then this will result in no TLS trust evaluation
being performed and a </tt><tt><br>
</tt><tt> * {@link ResolverException} will ultimately be thrown.</tt><tt><br>
</tt><tt> * </p></tt><tt><br>
</tt><tt> * @param params the security parameters</tt><tt><br>
</tt><tt> */</tt><br>
<br>
<br>
The schema parsers for the metadata resolvers already do this
internally. And we already have a pre-wired socket factory bean
'shibboleth.SecurityEnhancedTLSSocketFactory' in global-system.xml.<br>
<br>
There's an additional requirement for having the right kind of
X509KeyManager in the TLS socket factory if you want to do
per-request client TLS via the credential slot in the parameters,
but we don't actually have any examples of that at the moment. <br>
<br>
</body>
</html>