SOAP Client: Client TLS credential selection

[Cantor, Scott]

On 5/13/15, 10:00 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:


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

Ideally with essentially the same machinery we use for selecting other 
credentials.

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

Yes, somewhat constrained by the fact that when connection pooling is 
involved, generally that limits the control you have once existing 
connections are formed.

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

Yes. It uses the same logic, a CredentialResolver that has various inputs 
and picks the one to use. I don't think I have a way to split off signing 
from TLS at the moment.

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

I suppose one could essentially "resolve" a SOAP client if that were the 
unit of configuration, but I was assuming the credential would be 
resolved, along with any other relevant settings for the SOAP client 
depending on how fancy one gets.

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

Not exclusively self-signed though, and not reliably mappable back to the 
RP (e.g. SPs can share keys).

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

I guess it's nice that the hardest problem I had to solve is also the 
hardest in Java. I suppose at the end of the day, there's always signing, 
which is going to be the dominant case IdP to SP anyway. Doesn't 
necessarily apply to using this code to implement an SP, but even there, 
this is just the reason why all the other implementors abandoned client 
TLS. I was an early adopter and stubborn enough to make libcurl work, I 
guess, so I had a warped view of what was possible.

>I want to solicit thoughts and feedback on this idea.

I don't know enough of JSSE, but I've never seen it as being very robust 
certainly, so I don't imagine there's much choice but to go around it.

-- Scott