9:10 p.m.
Hi,
The current SAMLBackend actually allows "discovery initiated" flows.
That is, a browser with no other state can invoke the URL endpoint for
the SAMLBackend disco_response() as long as it passes in the entityID
for the IdP to use for authentication in the query string. The backend
will redirect the user to the IdP and consume the SAMLResponse when the
browser returns.
Such a flow does not make much sense for most deployments because
after consuming the SAMLResponse and passing back to the frontend, the
frontend (either SAML or OIDC) will fail because it doesn't know where
to redirect the browser, since the flow did not originate or come
through the frontend. The SAMLFrontend will fail with the well known but
hated "UnknownError".
I have a deployment where this is happening fairly regularly. It turns
out it is because of users that have either bookmarked the discovery
service or are opening/restarting browsers with tabs that were "paused"
at discovery. Sigh.
We will be (attempting) to educate users, but we also want to not allow
"discovery initiated" flows and we want them to fail with a better
exception and error message in the log files to assist help desk staff.
Unfortunately I can imagine some deployment configurations where a
"discovery initiated" flow might make sense and is "doable" (with
enough
microservices anything is doable). So I don't think we can just make the
current behavior disallowed by default.
Instead I have submitted PR 322
https://github.com/IdentityPython/SATOSA/pull/322
which adds the configuration option 'allow_discovery_initiated' for the
backend. By default it is True to preserve the current (odd) behavior,
but when set to False a flow that starts at the disco_response()
endpoint will immediately fail with exception SATOSAStateError and message
IdP discovery initiated flow not allowed
Sorry for the long note, but I thought it better to explain in detail
since the code changes themselves might not make the use case (or edge
case) clear.
Please let me know if you have any questions or concerns.
Thanks,
Scott