<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I'm trying to finish up the SOAP client. One outstanding issue is
how a client TLS credential is chosen.<br>
<br>
My assumptions are:<br>
1) We don't want to use KeyStores. We prefer something driven by
our X509Credential abstraction.<br>
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).<br>
<br>
For reference, what does the SP support here? Does it allow usage of
different credentials with different peers?<br>
<br>
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.<br>
<br>
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:<br>
<br>
<tt>String chooseClientAlias(String[] keyType, Principal[]
issuers, Socket socket)</tt><br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
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?<br>
<br>
The impl sketch would be:<br>
<br>
1) client cred is resolved and stored in the InOutOperationContext
passed to the client (or resolved by a MessageHandler directly in
the client)<br>
2) client stores the cred ref in the HC HttpClientContext it creates
for each call<br>
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<br>
4) a custom impl of X509KeyManger then uses the ThreadLocal
credential at runtime<br>
<br>
I want to solicit thoughts and feedback on this idea.<br>
<br>
Thanks,<br>
Brent<br>
<br>
</body>
</html>