4:53 p.m.
* Giuseppe De Marco <giuseppe.demarco at unical.it> [2020-03-26 16:38]:
Note that I was talking about the SAML backend (SP) and the above is
about the frontend (IDP). Thanks for the pointer anyway.
The only reason to sign authn requests is if they contain something
extra the SP doesn't want to be removed (in transit) and replaced with
an authn request without it, maybe forceAuthn or authn context class
refs or something like that.
For ordinary authn requests the IDP must already validate the
requested ACS URL (from the SAML spec), which of course is done using
metadata obtailed securely out of band.
So in the common case signing an authn request does not provide any
added security but it does expose the SP to trivial DoS attacks.
(A note to those who thing "signing" makes everything more secure,
forgetting about the availability aspect of IT security.)
Disabling
signed auth requests is the first thing I did (an
unfortunate default of pysaml2) but that setting has nothing to do
with the SP not supporting encrytpted responses or assertions, AFAIU.
Disable encryption
https://github.com/peppelinux/Satosa-saml2saml/blob/master/example/plugins/…
Not sure I
follow about Shibboleth conventions
First time I saw that ShibIdP don't require any signature by default on the
authnRequest I though <<Ok, it's the accessibility/security trade-off
!>>. I thought the same thing ... Found it with pdb, my
friend.
Seems I have a lot to learn, when really I should be learning about
the application I need to integrate...
PySAML2 is a wondeerful toy, in general it's just
fun!
We should let newcomers to be able to appreciate it ... And
comparisons with shibboleth are necessary to continue growing, and
here I am, out of topic!
:)
Thanks for sharing.
-peter