Alternative token exchange

[floeschau]

With this change, an alternative way of token exchange (Cross-Domain Federation), alongside the existing Internal-to-External exchange is enabled. This can be extended into Trusted Token Delegation (by adding additional claims to the access token).

This is needed to have the Dispatcher run in different environments (e.g. for testing and reference) and with a different IDP configurations where the IDP authorising the use of the execution platform is not configured within the central IDP (e.g. APEx).

It requires additional settings in the BACKENDS configuration (all of which are optional so as to guarantee backward compatibility), e.g. in the case of the Geohazards Exploitation Platform (GEP):

{
    ...
    "https://processing.geohazards-tep.eu": {
        "auth_method": "USER_CREDENTIALS",
        "token_provider": "gep",
        "token_url": "https://iam.terradue.com/realms/master/protocol/openid-connect/token",
        "client_id": "apex-test-token",
        "client_secret": "...",
        "subject_issuer": "iam-dev-apex",
        "audience": "processing-gep-apex"
    }
}

The presence of token_url in the backend configuration triggers the alternative token exchange. Otherwise the existing routine is used.

[JanssenBrm]

I believe the token_url property should not be considered the selection property to decide whether to use TTD or not as the token_url would be required for any kind of external OIDC communication. Maybe it is better to define a new property (e.g. auth_type) which can be set to trusted_token_delegation or identity_brokering. This not only ensures that code can be split more logically but also allows the validation to ensure the right properties are defined depending on the selected auth_type. What do you think?