Wiring HTTP client security in Spring

[Cantor, Scott]

> I'll observe that most of that is actually the ExplicitKeyTrustEngine, and wiring
> up a static instance like that with static creds is kind of a special case.

It is not the norm for the SOAP client, and I appreciate that the complexity was built around handling that use case, we just have to cook up some helpers to scale it back for the rest of the use cases.

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 actually an issue I suppose, since MDQ will probably involve just a simple certificate check. I guess I'll see about building a quick and dirty factory bean for this.

I wasn't clear from the Jira thread, do I need to build them in the IdP modules for some reason? What was the reason for the parallel factory beans there and not using the ones in Spring Extensions?

>  Maybe that particular trust engine case is actually where we need a FactoryBean (or
> at least partially, we could have for both and they get composed).  As we
> move from custom schema to Spring native wiring, I imagine we're going to
> find a lot of things like that where we need factory beans to
> facilitate/simplify some of the nastier wiring cases.

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).

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

-- Scott