Keycloak Tenancy

Pros:

• Pool efforts and costs by bringing all your tenants and users together in the same deployment.

• Users only have access to their realm and do not see customers from other realms.

• This is the simplest approach, as multi-kingdom architecture requires less development time for functional implementation.

Cons:

• For each realm, a user will have a distinct identity. If a user shares multiple identities in multiple realms, it becomes very complex to link them.

• Like all software, Keycloak has known limits. Performance is degraded beyond a hundred or so realms: start-up, use of the administration console, creation of entities such as realms, etc. This problem is an issue identified by the project.

• The load effects on one component will affect all the others: I/O, memory, network, everything is shared.

Pros:

• Pooling of efforts and costs by bringing together all stakeholders and users within the same deployment.

• Better scalability: it’s possible to have several thousand customers in a kingdom, unlike kingdoms limited to a hundred or so for performance reasons.

‍Cons:

• Part of managing user rights is delegated to the client, which requires customization of the Keycloak deployment to achieve stricter partitioning.

• Roles are configured via the label concept in Keycloak, but it is impossible to configure roles for each tenant.

• The application must react to each label, check the rights assigned, and manage user access according to their rights. You need to be able to block access to the application completely for users who don’t have the right access rights.