[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.

[floeschau]

Hello @JanssenBrm,

Sorry for the late reply. I will implement as you suggest (add a new property auth_type with the value list to make the kind of token exchange explicit).

Note, however, that the property token_url is only needed for the Trusted Token Delegation (in fact I introduced it, along with some other properties, for that purpose). In the Identity Brokering case, the token endpoint under KEYCLOAK_BASE_URL is used (since the token exchange is initiated with a request to the main IDP).

[floeschau]

Hi @JanssenBrm, I pushed the change. I named the configuration property exchange_method to avoid confusion with auth_method (default identity_brokering).

[JanssenBrm]

@floeschau - This. seems to be very specific for the terradue case and not OGC generic. Just for my understanding: in which case is the expecting issuer iam.terradue.com? Probably missing something, but I would assume that the user_token is always coming from APEx?

[JanssenBrm]

Thank you very much for the changes @floeschau. I only had one small question, for the rest the code looks fine for me to deploy to dev and test out.