Wiring HTTP client security in Spring

[Brent Putman]

On 10/24/16 11:48 AM, Cantor, Scott wrote:
> This is the same as the typical case with metadata in fact, but I don't think we have any support at the moment for wiring in a simple certificate check for the TLS connection, just for the signature filter.

That's probably true. Both of the existing HTTP metadata providers
(batch and dynamic) can take either a full TLSTrustEngine child
element, or a tlsTrustEngineRef to a bean, but I don't think we have
any shortcut for the single-certificate case.    The easiest way I can
see would be via the ref, with a FactoryBean for ExplicitKeyTrustEngine
that we are discussing.  I guess could also add a certificate attribute
somewhere or something, although that means we then have 3 different
ways to do the same thing, which maybe starts to get a little confusing
for the user...

>
> Yes, I've been aware of this one for a while, it's not a new thing, I just hadn't had the time to work up the wiring and actually test it. It's behaving like I'd expect with my metrics pusher. Default HttpClient wired in does "just trust the JVM and wave hands" and it fails on a self-signed cert. Adding a trust engine into the mix does the right thing based on how I configure it (and switching to the enhanced socket factory with no trust engine fails after the fact as you described).

Awesome.  I do like it when things actually work as designed. :-)


>
> I don't have example wiring at this point for PKIX via a custom root list though, which we probably need to work up. If you have something like that lying around...


You're talking about "our" PKIX, i.e. via a PKIX TrustEngine?  No, I
don't have anything.  It's not unlike the explicit key one.  Basically
a PKIXX509CredentialTrustEngine injected with a
StaticPKIXValidationInformationResolver that has the static anchor(s)
in it.

But I thought we didn't want to promote PKIX anymore?  Or is this
different, since we're talking about TLS, not XML signatures, etc.?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20161024/38ebb07f/attachment-0001.html>