1:31 p.m.
* Peter Schober <peter.schober at univie.ac.at> [2020-03-27 17:35]:
* Peter Schober <peter.schober at univie.ac.at>
[2020-03-26 14:16]:
To close off this thread: As mentioned in another post
https://lists.sunet.se/pipermail/satosa-users/2020-March/000120.html
I'm now pretty sure my SAML backend has been working fine all this
time despite the exceptions I asked about.
The problem seems to have been with my testing method(s), i.e., by
sending the SAML SP an unsolicited response (even if the backend has
allow_unsolicited: True, whatever that's supposed to achieve, then, if
satosa falls over dead when it does recieve one) or starting
SP-initated SSO using the DiscoveryResponse URL (at
/<name>/disco?entityID=someidp) both ended in exceptions, as reported
here earlier.
But involving the frontend (which I'm not further along setting up)
shows the SAML part is fine, after all.
I'll continue my public soliloquy in other threads.
-peter
Ignoring my failed attempts to deploy this in
uwsgi for now
FWIW, got satosa runing under uwsgi (plus proxying from httpd), so
gunicorn vs. uwsgi is not an issue after all.
I'll be trying to get the to-be-protected application to start an OIDC
flow next, maybe that'll show whether my satosa deployment is actually
broken or whether my testing methods were simply insufficient...