SOAP Client: Client TLS credential selection

[Cantor, Scott]

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


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

I was thinking not only things like other credential types, but even SSL 
cipher suites for example. I'd have to look at the various options I 
supported, but there are a bunch of properties like timeouts and such that 
I allowed to be per-RP.

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

Maybe it's the simpler path, yes.

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

Yes, and that's basically a non-starter on SPs. With an IdP you're 
essentially in control of your web environment. An SP is sitting in an 
application environment where multiple ports are not realistic and until 
recently, and arguably still, renegotiation on one port is not workable.

Even the server credential isn't all that usable since it's a commercial 
cert changing every year, so it's probably signing both ways. The real 
reason I wanted to get a SOAP client implemented is to eventually 
implement SP functionality, but we should calibrate how much effort we 
expend to make the client work vs. just signing.

-- Scott