<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 5/13/15 6:16 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:68495AE8-689E-4325-833C-6537F2EF2873@osu.edu"
type="cite"><br>
<pre wrap="">
Yes, somewhat constrained by the fact that when connection pooling is
involved, generally that limits the control you have once existing
connections are formed.</pre>
</blockquote>
<br>
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.<br>
<pre wrap="">
</pre>
<blockquote cite="mid:68495AE8-689E-4325-833C-6537F2EF2873@osu.edu"
type="cite">
<pre wrap="">
I suppose one could essentially "resolve" a SOAP client if that were the
unit of configuration, </pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:68495AE8-689E-4325-833C-6537F2EF2873@osu.edu"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote cite="mid:68495AE8-689E-4325-833C-6537F2EF2873@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Not exclusively self-signed though, and not reliably mappable back to the
RP (e.g. SPs can share keys).</pre>
</blockquote>
<br>
I pretty much written that idea off. <br>
<br>
<blockquote cite="mid:68495AE8-689E-4325-833C-6537F2EF2873@osu.edu"
type="cite">
<pre wrap="">
</pre>
<pre wrap="">
I guess it's nice that the hardest problem I had to solve is also the
hardest in Java. </pre>
</blockquote>
<br>
Awesome. :-)<br>
<br>
<br>
<blockquote cite="mid:68495AE8-689E-4325-833C-6537F2EF2873@osu.edu"
type="cite">
<pre wrap="">I suppose at the end of the day, there's always signing,
which is going to be the dominant case IdP to SP anyway. </pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:68495AE8-689E-4325-833C-6537F2EF2873@osu.edu"
type="cite">
<pre wrap="">
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.</pre>
</blockquote>
<br>
<blockquote cite="mid:68495AE8-689E-4325-833C-6537F2EF2873@osu.edu"
type="cite">
</blockquote>
I was hoping to avoid, but I'll go there if necessary.<br>
</body>
</html>