2:47 p.m.
Hi Peter,
I'll try to share my poor knowledge on some of the things you wrote, other
users with more experience than mine would be do better. No way otherwise
for my english ... :)
Il giorno gio 26 mar 2020 alle ore 14:16 Peter Schober <
peter.schober at univie.ac.at> ha scritto:
I've also used `satosa-saml-metadata` to generate
backend.xml.
I stopped using the metadata generator, I forge it on the fly with this
parameter:
https://github.com/peppelinux/Satosa-saml2saml/blob/master/example/plugins/…
and this parameter:
https://github.com/peppelinux/Satosa-saml2saml/blob/master/example/plugins/…
same approach for backends and frontends.
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.
So I've removed that 'use' restriction
to cause the IDP to send
encrypted assertions but later also /disabled/ that in the IDP again:
I get the same exception either way, so this may not in fact be
related.
To avoid encryption of assertions from a ShibIdP side, if I remember well,
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!).
With no idea how to test the SAML side of things (I
know nothing about
OIDC and so left the OP setup and RP integration for later) I sent the
SP an unsolilcited response from my IDP. ('allow_unsolicited: True' is
set in the SAML backend config) which ultimately fails with an
"Unknown error".
Yes in a production environment where satosa runs in multiple workers each
with a private memory we have this bane...
I'd need also to try to setup a mongodb to enable some shared sessions
between my workers, but this is another topic.
if context.state[self.name]["relay_state"] !=
context.request["RelayState"]:
File "/usr/local/venv/SATOSA/lib/python3.7/collections/__init__.py",
line 1025, in __getitem__
raise KeyError(key)
KeyError: 'saml'
It seems that something went missing in the session.
BASE: https://test.example.edu
COOKIE_STATE_NAME: satosa_state
# Also tried with delete set to False
CONTEXT_STATE_DELETE: True
STATE_ENCRYPTION_KEY: somestring
cookies_samesite_compat:
- [satosa_state, "SATOSA_STATE_LEGACY"]
Probably I'm wrong, try this:
cookies_samesite_compat:
- ["SATOSA_STATE", "SATOSA_STATE_LEGACY"]
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
Any pointers?
Should I post (even) more config snippets?
Logs from the other exception too, when accessing the disco endpoint?
Without Python Debugger (import pdb; pdb.set_trace()) I wouldn't have been
in production.
Take some more day to find your configuration and asset, it's normal.
let us know
____________________
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