Implement "active" organization switching using OIDC `prompt=select_account`

[xgp]

Per @phamann 's comment we should extend @MGLL 's contributed Active Organization feature to be more spec-compliant, using a custom Authenticator which acts upon the presence of the OIDC query parameter prompt=select_account.

From the spec:

select_account

The Authorization Server SHOULD prompt the End-User to select a user account. This enables an End-User who has multiple accounts at the Authorization Server to select amongst the multiple accounts that they might have current sessions for. If it cannot obtain an account selection choice made by the End-User, it MUST return an error, typically account_selection_required.

This way, we could use Keycloak's existing auth and token endpoints and off-the-shelf OIDC clients without any modification for account switching.

Add an account_hint=<org_id> param, allowing users to switch directly to an account without being challenged to choose from a list, similar to Keycloaks kc_idp_hint behaviour.

[MGLL]

I will probably take it to continue my works.

Here is my idea (based on assumption, might differ once I will be working on it):

Files to be added / created:

• ActiveOrganizationAuthenticatorFactory
• ActiveOrganizationAuthenticator
• Necessary .ftl form (maybe "select-orgs.ftl", probably a challenge for me)

[MAYBE]

• ActiveOrganizationPermissiveCondition
• ActiveOrganizationPermissiveConditionFactory

Assumption / Personal Notes: prompt and account_hint form parameter can be retrieved in the Authenticator flow through MultivaluedMap<String, String> formData = context.getHttpRequest().getDecodedFormParameters(); On this basis, I think I can apply the necessary logic.

Flow / Idea: ActiveOrganizationAuthenticator

• The Authenticator will be either REQUIRED or DISABLED. So it can be disabled to rely on the alternative way to manage "active organization" (current implementation).
• If the prompt=select_account is provided, the select-orgs form will be rendered for the user to be selected. Except:
• If the user doesn't have any organization, an error will be returned.
• If the user belongs to 1 organization, the selection will be skipped. (can be a conditional if we don't want that as a default behavior)
• If the account_hint=<org-id> is provided, the select-orgs form will be skipped (if the organization is valid).
• The selected organization will be persisted into user's attribute (similar to current implementation).

ActiveOrganizationPermissiveCondition (optional) I propose this conditional to have a more "permissive" approach. As in some use case, belong to an organization might be optional. So, I would like to introduce this condition to cover this potential use case:

• If it is set, then when the user doesn't have any organization, no error will be returned, and the flow will be successful.

My current questions: How can we test an authentication flow?

• from my point of view the cases
  • with account_hint=<org-id> can be covered as it doesn't require to interact with a form.
  • with user belong to 1 organization can be covered as it doesn't require to interact with a form.

@xgp if you have some examples on how the other case can be tested automatically (where we have to select an organization). Except from manual testing, I don't see how it is possible currently.

Also, let's take this thread to exchange on this approach if you would like something different.

(don't know if you can assign it to me, but, if possible, assign it to me, I will work on that)

[xgp]

@MGLL Regarding testing authentication flows, I have used Cypress and a Cypress testcontainers. Unfortunately, I've only done that for consulting project, and I don't have open source examples. However, after I figured out Cypress, it was fairly easy.

Regarding your idea for implementation, it seems like it will work.

[xgp]

Completed in #172