Dedicated multi-tenancy / organization support for Keycloak
Thomas Darimont
Dedicated multi-tenancy / organization support for Keycloak
I recently had an interesting discussion with different customers where they told me that Keycloak fits very well for some use cases but not such well with others.
TLDR: Many customers need something like a realm with support for customization on the "tenant" or "organizational" level for specific realm settings (theme, domain/hostname) / components (IdPs, user federation) with generic client configurations. Are there already plans for such a feature?
What currently works well with Keycloak:
# EAIM In-house
- many different applications/services connected via OIDC, SAML
- users stored in an LDAP directory, Keycloak database, or external user store
- Integration with company IdP (ADFS, Azure AD, Okta, etc.)
- ~10s - 10000s of users (employees, external partners)
- Branded login, account theme
- Centralized user management
- single domain
-> This use-case works very well (flexible enough and reliable) with Keycloak today
# CIAM SaaS Product
- few (uniform) applications/services connected via OIDC, SAML
- users stored in the Keycloak database, external user store, or LDAP directory
- ~10s - millions of users (consumers)
- Offline Sessions for mobile apps
- Social Login
- Branded login, account theme
- Centralized user management
- single domain
-> This use-case works okayish (flexible, yes, but scale and reliability need quite some effort) with Keycloak today and scales with proper Keycloak configuration.
What doesn't work so well:
# CIAM Multi-tenant SaaS Product
- few (uniform) applications/services connected via OIDC, SAML
- applications might be tenant aware and allow branding/customization
- users stored in the Keycloak database or external user store, or LDAP directory
- ~10s - millions of users (employees and customers of a tenant)
- 10s - 1000s of tenants/organizations
- tenants/organizations users might come from different IdPs, user federations, databases
- multiple tenant-specific domains (staged environments per tenant)
-> IMHO, this use-case is currently not supported out of the box and, in some cases, not possible with Keycloak as it comes today.
To support tenant-specific IdPs or user storage federations, one must create a realm per tenant based on a template.
This approach currently hits a scalability limit (with a few 100 realms), which the new storage implementation might fix. However, even
if Keycloak would support an arbitrary number of realms, users would still need to use a templating mechanism to deal with that many realms, which
differ only in minor configuration (IdPs, user storage federation, etc.).
Other workarounds are to model tenants/organizations with groups in Keycloak, but this is difficult to manage and has limited use.
One can model organization structures with groups and store tenant/org-specific metadata. Still, things become difficult or impossible when you need to support tenant-specific users via dedicated IdP user storage.
Other auth solutions use a concept of an "organization" to express org/tenant-specific differences of a global configuration.
It would be great to have support for such an organizational concept.
In the Keycloak community, some folks already build interesting extensions like keycloak-orgs[1], which support organizations at some level. Still, those solutions are an add-on and require some maintenance effort to keep them working
with new Keycloak versions.
An alternative to an organizational layer could be a realm template/parent realm concept, where a realm could inherit settings from a parent realm
with support for overrides and additional configuration
However, it would be great if we had support for modeling organizations with dedicated / customization of:
- Identity providers
- Storage user federation
- custom domains
- auth-flows
- Groups
- Users
- Roles
- Keys
- Scopes
- Protocol mappers (with defaults to map orgId into token/assertions)
- User management with delegated administration -> organization admins can manage their users, configure their IdPs, etc.
The list above sounds like a dedicated realm-per-tenant model. However, I think most users only need to customize keys and IdPs with a logical segmentation of their users with support for delegated administration.
As I did not see a design proposal [2], I'd like to ask: Are there already any plans to support such a model?
Support for this would enable the usage of Keycloak in more scenarios which are currently barely possible with Keycloak, and increase Keycloak adoption rates.
[1] https://github.com/p2-inc/keycloak-orgs
[2] https://github.com/keycloak/keycloak-community/tree/main/design
Garth
- Groups (we're in the process of building this right now in order to facilitate, like Keycloak, grouping of Roles)
- Roles (these roles are separate from Keycloak's Roles. Similar to `realm-management` Roles, there are a set of standard Roles which control a User's ability to change data of the Organization and its child elements)
One of the big things we have struggled with is delegated administration. We'd like to piggy-back on the "Fine-Grained Authorization Service" to allow administration using the Keycloak Admin UI, but we've never got it working, and so we abandoned the idea of working in conjunction with that feature. Instead, we've had to build our own "Admin Portal" that uses a combination of Keycloak and our Organization Roles to authorize a user to manage organization data.
Thomas Darimont
In my mind, a realm template is a collection of realm components/settings that's meant to be shared across multiple "realms instances" without requiring repeated configuration within a "realms instance."
Users can create or mark an existing realm as a realm template.
Users can create realms based on a realm template which effectively becomes an "instance" of the realm template.
A realm based on a realm template will then inherit the configured components. Whether this happens by reference or copy is to be defined, both make sense depending on the element.
Realm templates could allow configuring the following, with the possibility to override settings per concrete realm instance:
- Login customizations
- Themes (Keycloak could ship with a generic theme (admin, login, account) that can be parameterized (styled) with realm attributes without requiring explicit custom themes like the keycloak-orgs extension does)
- Default User Roles
- Clients (With the possibility to customize URLs, scopes, protocol mappings, role mappings in realm instances)
- Client Scopes
- Authentication Flows
- Required Actions
- Feature toggles (Which OAuth or OpenID Connect or SAML features to advertise and enable, most clients don't need device auth flow)
- Client Policies
- Password Policies
- 2FA Policies (HTOP, TOTP, WebAuthn)
- CIBA Policies
- Roles (Think generic roles which are the same across multiple tenants/organizations)
- Users (Think support users, alternatively allow IdP connection with a "Support Realm")
- Groups (Think generic groups which are the same across multiple tenants/organizations)
- Identity Providers
- User Federation
- Events
- Security Defences (Web Security Headers and Brute-force Protection)
- Session settings
- Token settings
- User Registration (default roles, groups)
- User Profile
Some stuff would explicitly NOT be part of the realm template:
- Realm Keys (should be controlled per concrete realm instance to give control to the tenant)
- Email Connection & Authentication
- (User federation connection & credentials, I'm not sure here)
- SAML Signing / Encryption Keys
- Client Credentials (each concrete realm-instance of a realm-template would have its own client credentials / service-account user)
Inherited settings/components from a parent might be read-only. When a component needs to be customized, then the customization could
"augment" the component definition from the realm template. It should be possible to override settings, remove settings, reset settings to default,
add values to lists, or remove values from lists, e.g. redirect URIs. It should always be visible which setting comes from the template, and what was added/customized in the concrete realm instance.
Import and export for such realms should take the templating into account. We could export a realm with a template reference with a "realm-overrides" structure containing the customizations or completely materialize the realm by rendering the effective configuration.
Perhaps this approach is "easier" to implement than to introduce a dedicated organization layer which in its fullest extend would infact be 80% of a realm anyways.
What are your thoughts on that matter?
Kind regards,
Thomas
Stian Thorgersen
--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/2dff9dc2-0a76-4770-b5eb-5b763c49ecd3n%40googlegroups.com.
Garth
Is there already a GitHub issue/discussion where this is being discussed (similar to how the database support issue was constructively presented to solicit community feedback before making a decision [1])? Please let us know when there is a design proposal that we can see.
I agree with Stian's opinion on "Realm of Realms". We originally prototyped our approach this way, and found that the relationship between the Realms was complicated and fragile, and ultimately couldn't be implemented without a new management layer with authn/z between Realms (or more abuse of the "master" Realm). However, we never tried anything like Thomas's templating approach, so maybe we missed something that would make it easier and more resilient.
The "smart" Groups idea is really interesting. I like the idea of being able to associate other top level Keycloak elements (Client, Authentication policy, Domain, etc.) through typed Group Attributes (think new User Profile, but for Groups). An outstanding issue that would need to be addressed is that of Roles. A few thoughts from our experience:
- The reason we took a separate approach was that an individual User (in our model) could be associated with multiple Organizations, and could have different Roles within each organization.
- It was not evident to us that the Organization's Roles had anything obvious relationship to Keycloak's Realm and Client Roles.
- Having separate top-level roles for Organizations made sense since there was not always inheritance between Keycloak and Organization Roles.
In any case, I'm very enthusiastic to help out with this, as we have many customers and users on our `keycloak-orgs` extension, and we've had success serving many use cases with the decisions we made. We're big supporters of this concept being integrated into Keycloak.
[1] https://github.com/keycloak/keycloak/discussions/10404
>>>> - many different applications/services connected via OIDC, SAML
>>>>
>>>> - users stored in an LDAP directory, Keycloak database, or external user store
>>>>
>>>> - Integration with company IdP (ADFS, Azure AD, Okta, etc.)
>>>>
>>>> - ~10s - 10000s of users (employees, external partners)
>>>>
>>>> - Branded login, account theme
>>>>
>>>> - Centralized user management
>>>>
>>>> - single domain
>>>>
>>>>
>>>>
>>>> -> This use-case works very well (flexible enough and reliable) with Keycloak today
>>>>
>>>>
>>>>
>>>> - few (uniform) applications/services connected via OIDC, SAML
>>>>
>>>> - users stored in the Keycloak database, external user store, or LDAP directory
>>>>
>>>> - ~10s - millions of users (consumers)
>>>>
>>>> - Offline Sessions for mobile apps
>>>>
>>>> - Social Login
>>>>
>>>> - Branded login, account theme
>>>>
>>>> - Centralized user management
>>>>
>>>> - single domain
>>>>
>>>> -> This use-case works okayish (flexible, yes, but scale and reliability need quite some effort) with Keycloak today and scales with proper Keycloak configuration.
>>>>
>>>>
>>>>
>>>> What doesn't work so well:
>>>>
>>>>
>>>>
> --
> You received this message because you are subscribed to the Google
> Groups "Keycloak Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to keycloak-dev...@googlegroups.com.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/keycloak-dev/CAJgngAf1U2VKOCFWvcA13pFvJLJEpiiB%3D8%3DM5yBz%2B_qv6FLUxA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Stian Thorgersen
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/a4eeb373-6ea2-4889-9d8f-5d861e58c4cb%40app.fastmail.com.