Hello Cody,
On Thu, 16 Feb 2023 at 07:29, Little, Cody (Education)
<
Cody.Little@sa.gov.au> wrote:
>
> UNOFFICIAL
>
>
> Hey All,
>
> We’re looking at setting up SATOSA as a SAML proxy for a handful (300+) SAML apps (very basic onelogin php-saml apps) to a single Okta SAML2 app.
>
> From reading through the documentation a number of times, I’m a bit confused.
>
> Few questions:
First of all, you should tell us what you would like to achieve. Why
do you want to use SATOSA? What will it offer in your envisioned flow?
I am giving you some information below, but let us know more to
understand what you are trying to solve.
> Do I need to create a front-end config for each SP or just append additional metadata URLs to the metadata array?
> How are the SPs differentiated from one another if not by entity IDs is this where the client-side cookie comes in?
>
The usual flow starts from the service. The service requires an
authenticated subject, thus redirects to an IdP so that the subject
authenticates.
In the proxy scenario, the IdP is the proxy. The frontend of the proxy
acts as an IdP interface, it receives a SAML authentication request,
processes it and forwards the message to the actual/external IdP. The
forwarding is done by the backend of the proxy that acts as the SP
interface.
[SP] ---(saml-authn-request)---> [frontend | proxy | backend] ---(saml-authn-request)---> [IdP]
[SP] <---(saml-response)--- [frontend | proxy | backend] <---(saml-response)--- [IdP]
The authn request originates from a specific service. The proxy keeps
this information as state on the cookie. It recreates the request and
when it gets back a response it knows to which service it should
return it.
All SPs see the proxy as an IdP.
All SPs trust the metadata of the proxy-frontend.
The IdP sees the proxy as an SP.
The IdP trusts the metadata of the proxy-backend.
Note that when there are multiple IdPs, the backend needs to redirect
the user to a discovery service (aka WAYF).
The above is one possible (and probably common) scenario. The proxy
looks like two different entities (as an IdP on the frontend, and as
an SP on the backend).
You could have other scenarios, like having the proxy expose multiple
endpoints, one for each service (the "mirrored" setup).
Cheers,