Wiring HTTP client security in Spring
Cantor, Scott
cantor.2 at osu.edu
Fri Oct 21 21:58:31 EDT 2016
> 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.
Good news I was able to provide an invalid certificate and fail it, and then a non-self-signed server cert as the trust anchor and it worked, so I think I have the code itself right. Bad news is the wiring falls into the category of unusable for anybody out there, so this is going to take some work down the road.
For now, my opinion is that we may want to just start handling the common cases directly by perhaps building some HttpClientSecurityParameters factory beans that auto-wire the important cases, e.g. inject a certificate and it auto-wires an ExplicitKeyTrustEngine with StaticCredentialResolver with that certificate. I'd use parent beans but it's not really possible to build that much nested wiring on the fly.
For things like service resources or this minor use case of mine, static trust or PKIX through a fixed root set is really 99.9% of the use case anyway.
If I'm missing a shortcut we already have, I'll take a look, but I'm not seeing anything. This was what I had to do for just a simple certificate:
<bean id="SecurityParameters" class="org.opensaml.security.httpclient.HttpClientSecurityParameters">
<property name="TLSTrustEngine">
<bean class="org.opensaml.security.trust.impl.ExplicitKeyTrustEngine">
<constructor-arg>
<bean class="org.opensaml.security.credential.impl.StaticCredentialResolver">
<constructor-arg>
<bean class="net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean"
p:certificateResource="%{idp.home}/credentials/authdev.crt" />
</constructor-arg>
</bean>
</constructor-arg>
</bean>
</property>
</bean>
That should really be <bean class="..." p:certificateResource="="%{idp.home}/credentials/authdev.crt" />
-- Scott
More information about the dev
mailing list