SOAP Client: Client TLS credential selection

[Brent Putman]

On 5/13/15 6:16 PM, Cantor, Scott wrote:
>
> Yes, somewhat constrained by the fact that when connection pooling is 
> involved, generally that limits the control you have once existing 
> connections are formed.

Hmm.  I had not given any thought to connection pooling issues.  I'll
have to cogitate on that - both in this context and more generally. 
Need to investigate what HC does, but I believe pooling is active by
default.

> I suppose one could essentially "resolve" a SOAP client if that were the 
> unit of configuration, 

Yes, that's precisely the other alternative: wire up potentially many
SOAP clients with one cred per, and then resolve them at runtime,
similar to the security -Configuration based things.  That indirectly
allows for per-relying party customization of the credential used.


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

Yeah, there's not much else for the client per-se, but the whole
operation context is available, and so as always the configured
MessageHandlers may accept arbitrary input data from the context.

Actually, I need to take another look at Basic auth.  The current
injected HC CredentialsProvider can support multiple auth creds in
their standard way via AuthScope.  But if we wanted to support say
basic auth creds specified dynamically in the op context, or resolved
via a strategy function, etc, that requires just a bit more.   Going
the "resolve the SOAP client" route would also address this.

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

I pretty much written that idea off. 

> I guess it's nice that the hardest problem I had to solve is also the 
> hardest in Java. 

Awesome. :-)


> I suppose at the end of the day, there's always signing, 
> which is going to be the dominant case IdP to SP anyway. 

You think signing will be more common for IdP issuing back-channel
LogoutRequest as well as resolving inbound artifacts?  I would have
thought TLS, but in general we've always discussed switching to
preferring message level security just due to the PITA factor of
configuring support for client TLS on the server side.


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

I was hoping to avoid, but I'll go there if necessary.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150513/092cd139/attachment.html>