Wiring HTTP client security in Spring

[Brent Putman]

On 10/21/16 9:58 PM, Cantor, Scott wrote:
>
> 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.

That's fair.  This is a new thing, and we don't have much real hands-on
with it yet.

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


FWIW, the original use case for these params was in the SOAP client,
where they are resolved from a message context.  Which in turn is
probably going to be populated from params -Resolver + a
-Configuration(s), like some of the other things.  So wiring up a
params instance directly isn't something I'd given a lot of thought to
- although ultimately it's just a POJO bean.  It's the property inputs
to it that are the complex things.


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


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


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