HTTPRedirectDeflateEncoder removing AuthnRequest signatures?

[Brent Putman]

On 9/1/16 12:06 PM, Cantor, Scott wrote:
>
> 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, 

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.

> and the handler that would sign the XML knows not to do anything.


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.


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


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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20160901/840e50a0/attachment-0001.html>