<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 2/6/14 10:06 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CF19B559.8774%25cantor.2@osu.edu" type="cite">
<pre wrap="">
</pre>
<pre wrap="">
I can take a stab.
</pre>
<blockquote type="cite">
<pre wrap="">SAMLPeerEntityContext
</pre>
</blockquote>
<pre wrap="">
I think this is done in something like the Initialize action you're
talking about, by copying data from the inbound copy.
</pre>
</blockquote>
<br>
Yes.<br>
<br>
<br>
<blockquote cite="mid:CF19B559.8774%25cantor.2@osu.edu" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">SAMLEndpointContext
SAMLBindingContext
</pre>
</blockquote>
<pre wrap="">
The only part of this I think would be set in Initialize is the relay
state in the SAMLBindingContext, by copying it from the inbound version,
and this is aided by helper methods in the SAMLBindingSupport helper class.</pre>
</blockquote>
<br>
Yes.<br>
<br>
<blockquote cite="mid:CF19B559.8774%25cantor.2@osu.edu" type="cite">
<pre wrap="">
I'm not sure what would call setIntendedDestinationEndpointURIRequired.
That, I guess is meant to distinguish non-SOAP from SOAP cases, but I
don't really know what code would be expected to know how to set it.</pre>
</blockquote>
<br>
No, nothing to do with SOAP. That property and also the
hasBindingSignature are only used on the inbound side. It's related
to some security handler(s) that need to enforce some policy based
on evaluation of some binding and message specific info.<br>
<br>
That's also mentioned in my MessageContext notes from last week I
believe.<br>
<br>
<blockquote cite="mid:CF19B559.8774%25cantor.2@osu.edu" type="cite">
<pre wrap="">
The endpoint context and most of the binding context are set in a separate
(IMHO) action that does the endpoint computation and validation steps
using inbound message fields and metadata, mostly through the
BasicEndpointSelector class.</pre>
</blockquote>
<br>
Yes.<br>
<br>
Related note re: implementing the 'conditional' value for the
signing and encryption flags, for front-channel: If we decide to
support 'conditional' in v3, and implement analagous to v2, the
dynamically-selected binding URI (and by implication the Endpoint
since that's where it comes from ) would need to be resolved before
any of the signing and encryption can be done. The URI would be used
to lookup from the Spring context the actual MessageEncoder bean
instance that we be used, since that's the thing that actually
implements the binding/transport confidentiality and integrity eval
(at least in v2). This is pretty yucky, and as we've mentioned, we
may choose not to support 'conditional' in v3 (although I guess that
means we break backward-compt with v2 configs - can we actually do
that?). Alternatively, we have to come up with a different notion
of what 'conditional' means and/or how to evaluate it.<br>
<br>
<br>
<blockquote cite="mid:CF19B559.8774%25cantor.2@osu.edu" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">SecurityParametersContext
</pre>
</blockquote>
<pre wrap="">
Whatever versions of this exist and get created are done by some other
action that's using a TBD resolver class that computes the data.</pre>
</blockquote>
<br>
Yes.<br>
</body>
</html>