3:14 p.m.
Dottore,
Thanks for your response (and no apologies needed about not being a
native speaker of the English language).
* Giuseppe De Marco <giuseppe.demarco at unical.it> [2020-03-26 14:47]:
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.
Indeed, my mistake. See my other post for more exceptions once I
included that.
Cheers,
-peter
I stopped using the metadata generator, I forge it on
the fly with this parameter:
It was fine. And I know I can configure the SP to publish it's own metadata
at the entityID value (if one choses a URL) but that has the same
deficiency with the use="signing" restriction on the published key.
But that was a tangent and doesn't affect the (not) working of my
deployment.
That contained
a copy of the provided SAML SP certificate, though
with a use="signing" restriction. (I.e., the metadata generated
that way would fail with any default Shibboleth IDP. Unless
pysaml2 doesn't support encrypted assertions or reponses I
consider this a bug. At least neither the satosa nor the pysaml2
docs had anything on this.)
Put it to false:
https://github.com/peppelinux/Satosa-saml2saml/blob/master/example/plugins/…
Yes shibboleth creates a lot of
"conventions" and as I can see many
security restrinctions goes down in its ideal world ... But not the
encryption, pySAML2 (xmlsec1) works fine with shibidp encrypted
assertions, the problem is that a Shibboleth SP doesn't do the same
with encrypted assertion from a pysaml2 IdP.
Not sure I follow about Shibboleth conventions 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).
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. ;)
just remove your encryption keys, here:
https://github.com/peppelinux/Satosa-saml2saml/blob/master/example/plugins/…
then renew sp metadata to shibidp. But I can tell you that pySAML2
(xmlsec1) works fine with shibboleth encryption (but not the inverse!).
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.
Anyway, encryption/decryption is not the issue, after all.
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