<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 10/21/16 9:58 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A5C069@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite"><br>
<pre wrap="">
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.</pre>
</blockquote>
<br>
That's fair. This is a new thing, and we don't have much real
hands-on with it yet.<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A5C069@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<pre wrap="">
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:</pre>
</blockquote>
<br>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A5C069@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<pre wrap="">
<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></pre>
</blockquote>
<br>
<br>
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.<br>
<br>
<br>
</body>
</html>