4:37 p.m.
Let's see
Il giorno gio 26 mar 2020 alle ore 15:14 Peter Schober <
peter.schober at univie.ac.at> ha scritto:
My fault, just happy to know that pysaml2 decrypt well the assertions from
a ShibIdP
... We should not let our guard down, we are so
close to solving it but ...
Years have passed in the meantime.
> > > Another data point: When trying to start SAML SSO by accessing the
> > > discovery_response endpoint at <base>/<name>/disco I end up
with the
> > > exception raised in disco_response() from satosa/backends/saml2.py
> > > ("No IDP chosen for state" / "No IDP chosen")
> > > Probably this resources takes
mandatory entityid arguments
> Indeed, my mistake. See my other post for
more exceptions once I
> included that.
PySAML2 and Satosa took me a lot of time for debugging, patching, studying
... But once this "tunnel" finishes they works like a charm, wonderfull
performances in production. I use also Shibboleth IdP in a production
environment for IDEM federation, and I have to manage two istances it
behind a HAproxy, because each restart of it (when a reload of a service
could not be done) could take 14 seconds of downtime.
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!
____________________
Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.demarco at unical.it
Thanks for your response (and no apologies needed
about not being a
native speaker of the English language).
Probably even with italian ...
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
!>>.
Then I found a lot of security restrictions in pysaml2 for the certificates
validity and moreover that guided me to read the Shibboleth IdP sources ...
:)
or how encrypted assertions my differ by
implementation, but it seems
satosa can
decrypt everything my Shib IDP sent just fine. So that particular
aside was irrelevant (except for my claim that either form of metadata
generation has a bug by adding the use="signing" restriction).
Sorry for including that particular distraction (I wasn't sure it
mattered, back then).
I hope this problem about encryption will be patched soon, it's something
mess in the arguments used in xmlsec1 to produce the encryption or
something linked to xmlsec. I should have been more time to debug to
purpose a patch, but too many things in the last months ... I'm thinking
about this lack just as a temporary bug.
To avoid
encryption of assertions from a ShibIdP side, if I remember
well,
just remove your encryption keys, here:
No, the Shib IDP by default terminates with an error for any SPs that
doesn't have encryption keys. And the default SAML SP metadata
generated by satosa does not have any keys usable for encryption in
them, which is eaxctly why I called that a bug before and above. ;)
I haven't seen an 'encryption_keypairs'
parameter in the satosa examples:
https://github.com/IdentityPython/SATOSA/blob/master/example/plugins/backen…
nor the satosa documentation:
https://github.com/IdentityPython/SATOSA/tree/master/doc#configuration
nor in the pysaml2 docs:
https://github.com/IdentityPython/pysaml2/blob/master/docs/howto/config.rst
but I see it being used satosa/backends/saml2.py.
I thought the same thing ... Found it with pdb, my friend.
https://github.com/IdentityPython/SATOSA/blob/master/src/satosa/backends/sa…
Anyway, encryption/decryption is not the issue, after all.