<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 9/1/16 12:06 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:5B25D158-EE54-4F12-BC14-6F6FDBECEA5A@osu.edu"
type="cite"><br>
<pre wrap="">
When we "sign" messages, we populate a context with all of the signing parameters (i.e. the key, etc.) and then we pass control to message handlers that are binding specific and sign the "message" in whatever way is appropriate. In the Redirect case, the message encoder does the signing, </pre>
</blockquote>
<br>
Yes, the general rule is that if the signature is defined by the
binding (e.g. Redirect DEFLATE and POST SimpleSign), then the
implementation of the binding handles that. So that means the
encoders.<br>
<br>
<blockquote cite="mid:5B25D158-EE54-4F12-BC14-6F6FDBECEA5A@osu.edu"
type="cite">
<pre wrap="">and the handler that would sign the XML knows not to do anything.</pre>
</blockquote>
<br>
<br>
I believe that's not literally technically true. The
SAMLOutboundProtocolMessageSigningHandler itself doesn't have any
conditional logic. To avoid XML signing when you use a binding with
a binding-specific signature, you either 1) don't wire that outbound
handler in at all, or 2) you make the execution conditional using an
activation condition. In the IdP, since the outbound binding is
determined dynamically at runtime, we do the latter. See for
example in idp-conf, the system/flows/saml/saml2/sso-abstract-beans.xml.<br>
<br>
<br>
<blockquote cite="mid:5B25D158-EE54-4F12-BC14-6F6FDBECEA5A@osu.edu"
type="cite">
<pre wrap="">
I may be misremembering, maybe we do the XML signing in the POST encoder also, I can't recall if that was what V2 did or what V3 does. Either way, we don't sign the XML if the outbound binding is Redirect.</pre>
</blockquote>
<br>
<br>
In v2 we did do the XML signing of the protocol message in the
encoders. We did lots of stuff in the encoders and decoders that
wasn't really specific to the particular binding or the
encoding/decoding operation, like security policy eval on the
inbound side. It was kinda messy.<br>
<br>
In v3 we decided to simplify the encoders and decoders and make them
really just about the encoding/decoding operation. So they don't do
XML signing anymore. As I mentioned above, they do perform the
generation of a binding-specific signature if applicable, since the
binding spec is where the particular signature format is defined.
Kind of has to, since only the encoder knows what the encoded form
will look like, and there's sort of a chicken/egg problem otherwise.<br>
<br>
For the record, that isn't true on the inbound/decoding side. The
decoders just decode, and validation of the binding-specific
signature can be and is done by a (binding-specific) handler that
you wire in.<br>
</body>
</html>