The idea is that satosa-saml-metadata will create IdP
metadata for a unique
IdP entityID for each configured IdP on all SAMLbackends or OIDC RP. In our
case the entityID is a concatenation of the [satosa proxy url] + /[backend
module name] + /[base64 encoded IdP entityID] which are also the base for the
endpoints:
entityID="https://proxy.scz-vm.net/md/SamlMirrorIdP.xml/SamlSP/
aHR0cHM6Ly9pZHAtdGVzdC5zY3otdm0ubmV0L3NhbWwvc2FtbDIvaWRwL21ldGFkYXRhLnBocA=="
Location="https://proxy.scz-vm.net/SamlSP/
aHR0cHM6Ly9pZHAtdGVzdC5zY3otdm0ubmV0L3NhbWwvc2FtbDIvaWRwL21ldGFkYXRhLnBocA==/
sso/redirect"
Thanks Martin (and Niels). With your hints and further study I think I
have a solid grasp on the SAMLMirrorFrontend now.
I do have a small (and not urgent) request:
Some of the SAMLMirrorFrontend logic "leaks" over into the SAMLBackend
class in the method start_auth(). That method has some special logic to
inspect the context and detect that a dynamic IdP has been targeted. If
it finds the dynamic IdP in the context it calls
entity_id = urlsafe_b64decode(entity_id).decode("utf-8")
and then sends a SAML authentication request off to that
federated/authenticating IdP.
I think the SAMLBackend class should not have to be aware of any details
of how the SAMLMirrorFrontend class works.
My thought is that there should be a standard way for the SAMLBackend to
be "signalled" that it should use a specific IdP. Then the logic for its
start_auth() method could be
- am I being signalled to use a specific IdP? Yes, go do it
- else, am I federated with only one IdP? Yes, go do it
- else go do IdP discovery
Thoughts? Ivan?
Thanks,
Scott K