Task: custom IDP: Allow Connection to `ManagedControlPlane` via custom IDP

[GenosseOtt]

(Edited to represent technical discussion from below)

Context

It is possible for an MCP admin to configure unlimited custom Identity Provider (in mcp.spec.authentication.identityProviders) and additionally enable/disable the default system idp (mcp.spec.authentication. enableSystemIdentityProvider).
This is reflected by mcp operators into the kubeconfig, that contains one user-entry per idp configured.
The user can decide which IDP to use when connecting. This is what we want to offer in the UI as well.

Description

Right now, when clicking the connect button, the user is authenticated via the default system idp.
This changes to let the user choose which IDP to use (use simple dropdown for now, more specified in other task).
The list of possible IDPs should be read and constructed in the frontend from the mcp.spec.authentication - as described above - mid term this information will be written in the mcp.status as described in [1]).
When the user chooses one IDP and want to connect, the /auth/mcp/me endpoint is triggered (with mcp and idp choice) to determine if an active session for this mcp and idp exist. If yes, we show the mcp detail page.
If not, we start a login oidc flow against /auth/mcp/login (with mcp and idp choice):

• we only allow ONE active session per user per mcp. So if user chooses idp1 and next time idp2, we overwrite the idp1 session information
• the BFF does not trust the user provided values. Instead it will query the mcp spec itself (with the user onboarding token) and reads the spec and extracts the required OIDC information.
  Now the BFF initiates the OIDC redirects as before.

All session related information can be stored in the BFF encrypted session storage we already have.

Step by Step

• Change frontend button to dropdown and construct all posissble IDPs from spec
• change /auth/mcp/me endpoint to also handle the idp information in its decision (define struct that is saved in the session - will include an identifier for the idp to handle it here)
• modify /auth/mcp/login that it handles the idp identifier from the user, queries the mcp from onboarding api and extracts the right oidc information to start the OIDC flow as previously
• Assume normal PKCE flow with client ID

Related

• Allow Custom IDP to be added/edited on ManagedControlPlane #148
• [1] Expose available IDPs in MCP status mcp-operator#123

Acceptance Criteria

• Have one custom IDP setup for Dev team to use and verify
• Member from Non-Default IdP can authenticate to their MCP

[enrico-kaack-comp]

In a discussion with @ValentinGerlach , @n3rdc4ptn and @andreaskienle we discussed the following:

Flow (rough high-level outline, might deviate in detailed implementation):
if an MCP is configured with > 1 IDP (e.g. the default system IDP and one additional custom IDP):
The connect button in the UI allows to choose with which IDP (= Auth Context) to connect.
This information is sent to the BFF. If the BFF already has a token in its session for this MCP with this Auth Context, it will continue the request. If no token exist, the OIDC flow needs to be performed (this information might be queried with the /me endpoint). For that, the BFF queries the MCP resource from the onboarding api (with the users auth token), read the idp information from the mcp.spec and initiate the redirect for the OIDC flow. We do not perform oidc flow with the information from the frontend, only from the provisioning api.

Further misc
We decided that per MCP the user only has one active IDP session that we store in the encrypted session storage in the BFF.
Mid-term, the information for available IDPs will be available as a field in the mcp.status, containing a list with all IDP (including default system idp and custom idp). There might also be a flag showInUI that allows to hide non-interactive flows for e.g. Github Actions from the UI.

[ValentinGerlach]

Mid-term, the information for available IDPs will be available as a field in the mcp.status, containing a list with all IDP (including default system idp and custom idp). There might also be a flag showInUI that allows to hide non-interactive flows for e.g. Github Actions from the UI.

Related: openmcp-project/mcp-operator#123