Config schema and parser support for HttpClientSecurityParameters in HTTP metadata resolvers.

Client TLS support implemented as described in r8532.

Realized another needed bit of work: Since we can now supply client TLS cred via the params, we need to make sure the TLS socket factory is wired correctly for that case. If have a client cred, the socket factory should get a ThreadLocalX509CredentialKeyManager.

To facilitate this, probably need to add a SecurityEnhancedHttpClientSupport to opensaml-security-impl that has some methods analogous to those in HttpClientSupport in java-support.

Thanks. I think that sets me straight. The answer to all my parser questions is usually "use a factory bean".

We do already use a FactoryBean for HttpClient. But you may recall that in order to have some IdP-specific stuff (setting of the User-Agent), we actually have IdP subclass of all those spring-extensions ones in package net.shibboleth.idp.profile.spring.relyingparty.metadata. So we could add stuff to those 3 classes. That would mean redundant code, unfortuantely. But looking at it, I think it's actually better to create a single new FactoryBean for TLSSocketFactory, which takes various inputs, and then it just figures out what kind to return. I'm going to give that a try, seems like will work just fine.

> Because we build an HttpClient instance in the parser if one isn't specified,

Strictly speaking we build (or should build) a net.shibboleth.ext.spring.factory.HttpClientFactoryBean which leads us back to...

> Probably a Rod question.... is there any way to "look ahead" and dereference the bean ref in order to look at the bean's properties?

I'm relpying to this question before I have fully caught up on all the other mails, so maybe I've got the wrong end of the lollipop but...

When I read this earlier this morning I thought "I would reach for a FactoryBean". By the time doCreateInstance() is called all properties are set (not sure if they have been initialized) so it will know the exact type of all the inject properties and can make any calls it wants

But it gets a bit mucky because the HttpClientFactoryBean is actually declared in spring-extensions. OpenSAML has no run time dependencies on SpringSupport, so we could make it dependant on TrustFactory.

In practice however OpenSAML has a run time dependency for testing. So its a no-go; also making SpringSupport dependent on OpenSAML just "feels wrong"..

So I guess we go back to having a specialized FactoryBean in the IdP which extends the SpringSupport one and also understand TrustEngines?

There's a slight wrinkle with this re: the parsers. Because we build an HttpClient instance in the parser if one isn't specified, we need to know whether or not we effectively have a TrustEngine. That determines what kind of TLS socket factory we use.

Probably a Rod question: Before, this was easy because the trust engine was either a child element or a bean ref by itself. Now we can also have one as a property of the injected HttpClientSecurityParameters bean. Is there any way to "look ahead" and dereference the bean ref in order to look at the bean's properties? If not, is there a way to look at the BeanDefinition for the bean ref and see what properties are set, or something similar?

If not, it's not the end of the world I guess. We could just say for now that you either have to use one of the explicit trust engine schema mechanims, or inject an HttpClient bean rather than having the parser build one.

And if we're going to dump the custom schema stuff for metadata in 4.0, then I guess this will take care of itself.