SOAP Client: Client TLS credential selection

[Brent Putman]

I'm trying to finish up the SOAP client.  One outstanding issue is how
a client TLS credential is chosen.

My assumptions are:
1) We don't want to use KeyStores.  We prefer something driven by our
X509Credential abstraction.
2) In a given instance of the SOAP client, it would be desirable for it
to support using multiple client TLS credentials, selected (somehow) at
runtime.  (The alternative being a client that supports only 1
credential that is passed at client construction time).

For reference, what does the SP support here? Does it allow usage of
different credentials with different peers?

If we don't need/want to support multiple credentials, or if we would
find it acceptable to statically wire up different SOAP client
instances (with different creds) for different relying parties, then
ignore the rest of this message.  But I'll proceed on the assumption we do.

In JSSE (and so also in HttpClient) client TLS key/cert selection is
driven by the X509KeyManager interface, which for our needs is pretty
limited and not ideal:

    String chooseClientAlias(String[] keyType, Principal[] issuers,
Socket socket)

That returns an alias for looking up nominally in a KeyStore.  That
alias then serves as the key to get the PrivateKey and certificate chain.

Not sure if we can base anything off of issuers.  Although in Shib the
peer would usually be self-signed, so maybe it reduces to just a map of
relying parties.  Same for the socket data.  For both you could
theoretically have a key manager that gets a map of issuers or
hostnames/IPaddresses and maps to a collection of X509Credentials,
defaulting to a particular one if no mapping override is supplied. 
This however feels very un-SAML like, would be pretty brittle and
doesn't leverage the kind of credential selection we do in other parts
of the system.

Does anyone else know of any other possibilities with JSSE that I'm
missing, or other simple ideas for using the X509KeyManager interface
in a more or less standard way?

Ideally what we would want is for the client TLS cred to be selected in
our "usual" way: via -Configuration(s) + -Resolver, producing a
-Parameters stored in the operation context.  The issue is getting that
info into the JSSE layer.  The only way I can see to do that is via a
ThreadLocal approach.  I'm loathe to do it, b/c I really don't like
circumventing defined interfaces like that.  But it's the only way I
can see at the moment to make it work.  IIRC Daniel is doing something
similar in ldaptive for (?) trust eval and X509TrustManager?

The impl sketch would be:

1) client cred is resolved and stored in the InOutOperationContext
passed to the client (or resolved by a MessageHandler directly in the
client)
2) client stores the cred ref in the HC HttpClientContext it creates
for each call
3) either an HttpClient wrapper or plugins
(HttpRequestInterceptor/HttpResponseInterceptor) has logic which stores
the cred in the ThreadLocal before the request, and then clears it
after the request is executed
4) a custom impl of X509KeyManger then uses the ThreadLocal credential
at runtime

I want to solicit thoughts and feedback on this idea.

Thanks,
Brent

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