9:36 p.m.
Hello,
On Mon, 27 Aug 2018 at 16:27, Scott Koranda <skoranda at gmail.com> wrote:
I do not see a direct relation between the saml2-backend (start_auth()
function) and the SAMLMirrorFrontend. The key defined and used through
the context object contains the '_MIRROR_' part, but this is only
something that we understand - not the compiler/interpreter. For the
code, there is no direct coupling between the respective modules.
The mechanism by which information is passed between the frontend and
backend modules is
- either, through the Context
- or, through the InternalData (InternalRequest and InternalResponse)
(choice depends on the kind of data that needs to be communicated)
The SAMLMirrorFrontend sets a flag (by invoking decorate() with the
appropriate key) in the environment (the context).
The backend checks the environment and if a flag is set it acts appropriately.
Also, see pull request #191 that refactors the code to make the above clearer:
https://github.com/IdentityPython/SATOSA/pull/191
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
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?