11:55 a.m.
To answer my own question:
backend/saml2.py always creates an enveloped signed authnRequest when
authn_requests_signed is true, this is bad.
self.sp.apply_binding needs a valid sigalg to create a detached signature on
the Redirect binding. This is not implemented in saml2.py
So, the work-around is to set authn_requests_signed: false in backend conf
and supply sigalg='http://www.w3.org/2001/04/xmldsig-more#rsa-sha256' in the
apply_binding call.
I'm not quite sure where to get the "correct" sigalg from in a more robust
version of this fix, since the IdP metadata doesn't mention a preferred or
allowed sigalg in metadata. I guess this would thus become an explicit Satosa
SP configuration option with a sane default?
Best regards,
Martin
On Thursday, January 10, 2019 4:36:17 PM CET Martin van Es wrote:
Hi,
Today I noticed a very strange behaviour of SATOSA SAML backend and was
curious if anyone on the list could shed a light on my findings?
For SURFnet's SecureID (2factor auth) service an SP needs to send a signed
authnRequest on the Redirect binding of the SSO endpoint. The only setting I
could find for SATOSA backend conf was
authn_requests_signed: true
This, however generates an enveloped signed xml messages that is dropped on
the Redirect endpoint, which is against the SAML standards, which explicitly
mandates the signature element to be removed and a URL request parameter
Signature to be added to the request:
3.4.4.1 DEFLATE Encoding
1. Any signature on the SAML protocol message, including the <ds:Signature>
XML element itself, MUST be removed
4. The signature value MUST be [...] included as a query string parameter
named Signature.
source: SAML-bindings-2.0-os
Did I miss something in the config to enable this behaviour or is pysaml2
blatantly ignoring the standard?
Best regards,
Martin van Es
_______________________________________________
Idpy-discuss mailing list
Idpy-discuss at lists.sunet.se
https://lists.sunet.se/listinfo/idpy-discuss