Wiring HTTP client security in Spring

[Brent Putman]

On 10/21/16 3:43 PM, Cantor, Scott wrote:
> I found the relevant classes in the SOAP client and see the general gist of it,

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.


>  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?

All you really need to do as far as code is:

1) have an available instance of HttpClientSecurityParameters
(injected, resolved, whatever)

2) marshall the params to the per-request HttpClientContext that you
build, with the support method like so:

HttpClientSecuritySupport.marshalSecurityParameters(context,
httpClientSecurityParameters, true);

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:

HttpResponse response = httpClient.execute(request, context);
HttpClientSecuritySupport.checkTLSCredentialEvaluated(context,
request.getURI().getScheme());

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.

>
> 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?

Yes, pretty much.  The trust engine goes into the parameters instance
that you would inject.

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.

I just typed that requirement into the resolver Javadocs, so I'll just
cut/paste here:


    /**
     * Set an instance of {@link HttpClientSecurityParameters} which
provides various parameters to influence
     * the security behavior of the HttpClient instance.
     *
     * <p>
     * For all TLS-related parameters, must be used in conjunction with
an HttpClient instance
     * which is configured with either a:
     * <ul>
     * <li>
     * a {@link
net.shibboleth.utilities.java.support.httpclient.TLSSocketFactory}
     * </li>
     * <li>
     * {@link
org.opensaml.security.httpclient.impl.SecurityEnhancedTLSSocketFactory}
which wraps
     * an instance of {@link
net.shibboleth.utilities.java.support.httpclient.TLSSocketFactory}, with
     * the latter likely configured in a "no trust" configuration. 
This variant is required if either a
     * trust engine or a client TLS credential is to be used.
     * </li>
     * For convenience methods for building a
     * {@link
net.shibboleth.utilities.java.support.httpclient.TLSSocketFactory},
     * see {@link
net.shibboleth.utilities.java.support.httpclient.HttpClientSupport}.
     * </ul>
     * If the appropriate TLS socket factory is not configured and a
trust engine is specified,
     * then this will result in no TLS trust evaluation being performed
and a
     * {@link ResolverException} will ultimately be thrown.
     * </p>
     * @param params the security parameters
     */


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.

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. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20161021/04482d27/attachment.html>