[micro-service] Set target-issuer from disco response and decide backend by target-issuer

[peppelinux]

Hello,
I developed a microservice that can map specific SaToSa backends to specific target entity id. A configuration example can be this:

module: satosa.micro_services.custom_routing.DecideBackendByTarget
name: TargetRouter
config:
  target_mapping:
    "http://idpspid.testunical.it:8088": "spidSaml2"
    "http://strangeIDP.testunical.it:8081/saml2/metadata": "strangeSaml2"

In the debug logs if the microservice has been activated we can read

[2019-04-14 23:01:29] [DEBUG]: [urn:uuid:acedce81-9287-4700-bd96-15b7adaeab5a] Routing path: Saml2/disco
[2019-04-14 23:01:29] [DEBUG]: [urn:uuid:acedce81-9287-4700-bd96-15b7adaeab5a] Found DecideBackendByTarget (TargetRouter microservice ) redirecting Saml2 backend to spidSaml2

I needed a backend routing based on the target entity ID because I have some SAML2 IDP that only accepts highly customized authn request and metadata. An example could be SPID italian federation. Another example could be the need to use different configurations, like sign and digest algorithms, depending by target IDP.

I was looking into DecideBackendByRequester microservice but soon I realized that it was made for different goals, in it the subjects are the requester entity ID and not the target entity ID.

This PR also answers to my related issue.

• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you added an explanation of what problem you are trying to solve with this PR?
• Have you added information on what your changes do and why you chose this as your solution?
• Have you written new tests for your changes?
• Does your submission pass tests?
• This project follows PEP8 style guide. Have you run your code against the 'flake8' linter?

[c00kiemon5ter]

@peppelinux with the latest changes we now have two micro-services, with the test rewritten to test both services.

• DiscoToTargetIssuer registers a handler that parses a response from the discovery service and sets the target_entity_id on the context.
• DecideBackendByTargetIssuer sets the target_backend based on the target_entity_id and the mapping between issuers and backends

Nothing else is done, but what is necessary for these goals. The responsibilities are clear.

---

DiscoToTargetIssuer should run before DecideBackendByTargetIssuer.

---

Also, squashed and rebased on top of current master.

[peppelinux]

I have to test It, probably tomorrow

[peppelinux]

@c00kiemon5ter I MUST set context.target_frontend otherwise I get the following exception when the Response came back to ACS endoint

SATOSA/src/satosa/routing.py", line 108, in frontend_routing
    frontend = self.frontends[context.target_frontend]["instance"]
KeyError: None

I made my tests, It seems to me that's quite good as it is now

[c00kiemon5ter]

Hello @peppelinux, I made another update, effectively moving the responsibility to set the target_frontend to the disco micro-service. If the discovery response were not intercepted, there would be no reason to set the target_frontend on DecideBackendByTargetIssuer.

The reason we need to set target_frontend is because it is needed to set the router state when switching from the frontend (and the response micro-services processing) to the backend (on _auth_req_finish). The discovery request and response used to be handled by the backend, and at that point the router state had been set already. With the interception of the discovery response, we force some stages to run again, and those include the switch from the frontend to the backend.

Because we have navigated away from the proxy (we redirected to the discovery service) the data on context has been lost (including the target_frontend) except for the state (persisted on the cookie). Now that we need to go through the switch to the backend again - but without a target_frontend - the error occurs. To fix it, we make sure that we store the target_frontend on the cookie, and restore it once we have a response from the discovery service.

This process does not involve the selection of the backend. Thus this is the responsibility of the DiscoToTargetIssuer to handle.

Ideally, DiscoToTargetIssuer would also create the request to the discovery service. Then this whole process would become apparent that it is needed to be done that way. We will look into doing this in the future.

[c00kiemon5ter]

Please, have a look and test it. Then we should merge ;)

[peppelinux]

Ok, everything works great even with idp_hinting ... Three year passed meantime but it was worth of it, let's merge it now!

[peppelinux]

hey, this seems to purpose the same or a similar goal of this PR
https://gitlab.daasi.de/didmos2/didmos2-auth/-/blob/master/src/didmos_oidc/satosa/micro_services/discovery_based_routing.py