Members should be able to join multiple organizations. There is a PoC already but we need to sort out the impact of it when authenticating users.

Today, organization members can only join a single organization. This constraint assumes that organizations are isolated from each other and their members can only be managed and access protected resources from a realm within the scope of a single organization.

There are two types of organization membership:

• Managed, the lifecycle of the member is bound to the lifecycle of the organization and they can not exist without the organization they belong to
• Unmanaged, the lifecycle of the member is disassociated from the lifecycle of the organization and they can exist even though the organization does not exist

Unmanaged members are realm users, whose account was originally created and bound to the realm. On the other hand, managed members have their accounts originally created when joining an organization through the different mechanisms to create accounts at the realm in the scope of an organization. For instance, using identity federation where accounts are created when authenticating through an identity provider associated with the organization or when creating an account using a registration link.

Considering a single organization, it is very easy to classify memberships as managed or unmanaged. As members can only be a member of a single organization, they have a managed membership whenever their accounts are created within an organization's scope.

However, when members can join multiple organizations the type of their membership can not be the same across all the organizations they are a member of. In this case, the type of the membership should also take into consideration the member’s identity ownership and the organization where the membership was created.

In terms of identity management, member's accounts can be managed in the scope of different organizations so that members can be assigned to different roles, and any constraint imposed by the organizations they belong to should be respected. For instance, force a specific email domain in their email address or different/multiple factors when authenticating.

In terms of authentication, a member of different organizations can authenticate and access protected resources in the scope of any of these organizations. In the case where a member belongs to a single organization, the authentication process is driven by first identifying the existing account associated with the organization and then authenticating the member either through an identity provider associated with the organization or any of the credentials set to the member’s account.

The identity-first login step will first try to match the user’s email address with an organization based on the email domain. If there is a match, that user will be prompted to authenticate based on the authentication policies and mechanisms available from that organization. Once authenticated, the resulting tokens will hold metadata about their membership.

However, when members can join multiple organizations the authentication process can no longer assume that the member is authenticating to a single organization. Instead, the authentication process needs to be driven by the organization the member wants to have access.

In terms of authorization, members should be granted to access protected resources in any organization they belong to. In essence, that means issuing tokens with metadata about the access scope that a member has in the different organizations. Or even exposing only the metadata about the organization the user is interested in accessing.

In summary, these are the following areas impacted by members joining multiple organizations:

• Member Onboarding
• Identity Management
• Authentication
• Authorization

This document aims to provide a proposal on how to address the problems associated with each of these areas when supporting members to join multiple organizations.

Member Onboarding

With the possibility of joining multiple organizations, members must have a single organization as the source of truth for their identities.

Taking into consideration the two types of membership, the single source of truth of the identity of a member will be driven by the mechanism used to onboard the member. Onboarding members to an organization can be done through the following mechanisms:

Members can only have a single membership of type managed so that it is possible to infer the single source of truth for their identities. When a member account is created for the very first time in the scope of an organization, by either the identity brokering or registration link mechanisms, the account has that organization as the single source of identity.

On the other hand, any existing account added as a member of an organization, including those already associated with an organization, will always be of type unmanaged on that organization. In this case, the source of truth of the member’s identity will be either the realm itself or some other organization where the identity has a managed membership type.

Understanding the source of truth of the member’s identity is a key factor when managing members accounts and their lifecycle as well as how they authenticate to a realm.

Identity Management

From an identity management perspective, members and their lifecycle can only be managed from the source of truth of their identities.

If the membership is of type unmanaged and the account maps to a realm user, organizations won’t have ownership and they won’t be able to delete these accounts. The same is true if a managed member of an organization joins another organization, in this case, only the organization where that user is a managed member will have complete control over the member lifecycle.

Authentication

In terms of authentication, when an account is shared by multiple organizations the authentication process should consider whether or not the account maps to a managed or unmanaged member.

When authenticating a managed member, the process should be based on the authentication policies and mechanisms available to the corresponding organization. That means, authenticating through any identity provider available from the organization where the member is a managed member or any credentials set to the account.

On the other hand, the process of authenticating unmanaged members should be solely based on the mechanisms available in the realm.

Authorization

In terms of authorization, when members authenticate to a realm the tokens will hold information about the organizations they belong to.

It should be fine to issue tokens with metadata about all the organizations the user belongs to. But we can also consider a least-privileged access approach where metadata about an organization is only added on-demand and based on the intent of the client acting on behalf of the user. This can be done by supporting a specific scope so that clients can send in authorization requests the organization they want to have access.