Topic for tomorrow : InitializeOutboundMessageContext

[Brent Putman]

On 2/6/14 10:06 PM, Cantor, Scott wrote:
> I can take a stab.
>
>> SAMLPeerEntityContext
> I think this is done in something like the Initialize action you're
> talking about, by copying data from the inbound copy.

Yes.


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

Yes.

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

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.

That's also mentioned in my MessageContext notes from last week I believe.

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

Yes.

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.


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

Yes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140206/1fdc98b1/attachment.html