[SPIKE] HSP: Evaluate Support for HSP Auth Token

[GenosseOtt]

Description

For integration with HSP, they offer an authentication token that we can get in the frontend.

As outlined below, we have two options for using this token in our openMCP systems.
This spike should investigate the Token Exchange approach, in which our BFF would exchange the token against a token from our idp (see below in comment).

Lets take some time, read into all the material and build a little prototype.

Expected Result

1. Create simple sample page that is embedded locally in HSP (using the local development capabilities)
2. This sample page gets the luigi token
3. Create an IAS tenant/application for testing
4. Configure the trust in the IAS tenant/application to the HSP idp
5. The sample frontend successfully exchange the HSP token against the IAS token

This should give us an idea how we would implement this and what we have to do to configure it
The following points should be thought of:

• what are do we need to do on the provisioning api
• and what do we need to do for the MCPs

Since this will most likely involve effort from the core team, lets have a clear picture what would be required so we can discuss it with the core team.

Open Questions

Acceptance Criteria

• lay out how we could achieve this, what modifications we need to do in what systems
• basically having a "How to Guide"

Out of scope

• any real implementation

[enrico-kaack-comp]

The HSP (and openMFP) give a valid token to the application in the context. Getting this token is easy, you just register a luigi Init Listener (https://docs.luigi-project.io/docs/luigi-client-api?section=addinitlistener) and read the jwt token from it.

More effort is required for trusting this token. There are roughly two approaches:

1. Trusting the IDP from HSP:
   We configure the Onboarding API Cluster and all MCP to trust the issuer of the token (the IDP). This is configuration for the onboarding api and a custom IDP for the MCP that we could add automatically.
   The following problem is the user mapping: Every IDP usually has a prexif (like openmcp for the default) and in RoleBindings, Users are referenced as :email (or id or whatever is configured). If the HSP IDP has a different prefix, it would require to map all users again (automatically in a controller). In theory we could configure the HSP IDP to use the same prefix as our preconfigured IDP so we dont need to map all users/groups twice with different prefix. This means we would accept impersonation of HSP IDP of our system IDP. If this is a legitimate configuration regarding security and best practice is questionable.
   Once a user uses a custom IDP and not the system IDP, this system would break though.

2. Exchanging the HSP token:
   It seems to be possible to exchange the token from one IDP (HSP IDP) against another one (our system IDP). This would skip the problem with user mapping outlined above as we just deal with one IDP in the end. TODO find documentation about how this work (should follow OAuth 2.0 Token Exchange).
   Basically our BFF would exchange the HSP token against our system IDP token, stores it in a session and uses it for proxying requests.
   In the scenario of custom IDPs for MCP, the admin would need to configure the custom IDP to allow the token exchange (as in trusting the HSP IDP). Maybe an automated approach could be made in a way of: user connects to MCP, gets dialog: mcp can not accessed with current idp configuration, wanna enable idp configuration? -> on yes it automatically reconfigures the MCP or IDP to allow token exchange.
   Or we do a hybrid approach of token exchange for the onboarding api (since we control it) and a normal redirect flow for custom idps (which we dont control).

Overall the Token Exchange approach seems to be the right approach for this problem since we dont have to remap users/group that would just create a mess. We need to outline and research the possible scenarios with system IDP/custom IDP and how we would like to support/handle this.

[enrico-kaack-comp]

Reassess if this investment is necessary right now or can be postponed to later.