HTTPRedirectDeflateEncoder removing AuthnRequest signatures?

Misagh Moayyed mmoayyed at unicon.net
Thu Sep 1 12:21:30 EDT 2016


Gotcha. Thanks very much. 

-- 
Misagh

From: Cantor, Scott <cantor.2 at osu.edu>
Reply: Shib Dev <dev at shibboleth.net>
Date: September 1, 2016 at 9:07:07 AM
To: Shib Dev <dev at shibboleth.net>
Subject:  Re: HTTPRedirectDeflateEncoder removing AuthnRequest signatures?  

On 9/1/16, 11:49 AM, "dev on behalf of Misagh Moayyed" <dev-bounces at shibboleth.net on behalf of mmoayyed at unicon.net> wrote:  

> Yes, if I understand your correctly. My method of confirmation is to basically check to  
> see if the authn request object carries a signature, mostly via isSigned().  

We use support classes in the IdP that recognize signatures at different layers if we need to generically ask that, e.g. SAMLBindingSupport.isMessageSigned()  

> Could I ask you to elaborate a bit more on this? Binding level, when? And what sort of  
> specialized algorithm?  

SAML Bindings, sec. 3.4 describes the algorithm used.  

https://www.oasis-open.org/committees/download.php/56780  

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, and the handler that would sign the XML knows not to do anything.  

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.  

-- Scott  


--  
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20160901/0aa1a865/attachment.html>


More information about the dev mailing list