Replies: 11 comments 7 replies
-
|
Related to organization concept is the idea of a workspace concept. Say for example for a SaaS solution that wants to leverage Keycloak it is likely that the SaaS solution has the concept of organizations, but also the ability to define workspaces (or some other name) within organizations. A similar concept would be useful in Keycloak as it would allow tokens to not only be associated with a given organization, but also with a given workspace. |
Beta Was this translation helpful? Give feedback.
-
|
What's the use-case for workspaces within an organization? One thing that I've seen in practice is that the whole application and services landscape is somewhat decided by certain business domains. Within each business domain there are different applications that users that are working in a domain should be able to access. It's like a logical grouping of applications and potentially other things (roles, groups, shared attributes etc.). |
Beta Was this translation helpful? Give feedback.
-
|
The "membership" of a use for a business domain is usually determined by a concrete group membership (e.g. from an LDAP federation) within an organization, e.g. members from the group sales belong to the "sales domain". |
Beta Was this translation helpful? Give feedback.
-
|
Another use-case is a logical separation of user bases based on the country where the service is offered, e.g. the same system could host users and applications for a service offered in country1 and and for an offering in country2. User bases for countries need to be logically separated, but they are most of not all of the configuration. |
Beta Was this translation helpful? Give feedback.
-
|
At this point the idea above is not quite explaining everything I've been thinking about and we're not planning on starting this work immediately. However, I would like to collect some use-cases and ideas around the general concept that we can use when doing some more in-depth designs. |
Beta Was this translation helpful? Give feedback.
-
|
We have one very basic use case for this: client organization. |
Beta Was this translation helpful? Give feedback.
-
|
A very rough write-up of the idea of implementing organizations and workspaces as a smart group: #19055 |
Beta Was this translation helpful? Give feedback.
-
|
how is it differnt from whats already being offered by phaseII as keycloak extension? |
Beta Was this translation helpful? Give feedback.
-
|
The concept sounds like something that could fit our use case for authentication. Specifically "Everything has to be re-created in each individual realm." is something we'd have to do without your organization concept. For us it would be important that the same user can belong to multiple organizations. |
Beta Was this translation helpful? Give feedback.
-
I'm currently looking at the (very nice!) organizations preview feature and I would like to add that requiring a domain for an organization doesn't always work. For example very large organizations such as HP, MediaMarkt, etc. often have a single global domain for email ( |
Beta Was this translation helpful? Give feedback.
-
|
You can still ha multiple domains associated with the organization and different broker in it. Where they might be associated with a specific domain or not. It would be nice to understand what we are missing to solve the use case. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I totally missed your reply.
Large companies often need to be divided further then just a single organization. For example in Europe most large corporations are divided by country or region (Benelux, Nordics, etc.). These organizations operate mostly separate from each other, but they do share a single email domain. Hence you can't create separate organizations for them. This means a lot of stuff won't work. For example you might want to delegate user management of the organization in Germany to someone, but they shouldn't be able to manage users from the Spanish organization. As far as I can tell the organizations feature does not help with that. It would require the user to be in specific groups. One could then use the "fine grained permissions" feature the delegate user management. This does however not work if you want to say: The admin should only be able to create new users in the "Germany" group. |
Beta Was this translation helpful? Give feedback.
-
|
Since organizations are based on domain names, it’d be really nice to have some realm settings available for organizations as well. On the top of my mind, feontend url and theme would be amazing to have on an organization level. |
Beta Was this translation helpful? Give feedback.
-
|
@siepkes I'm with you. I think this identiy-first login step to select the organization based on the email domain might be a common use case but it is not the only one. Currently everyting seems to be designed for that use case. |
Beta Was this translation helpful? Give feedback.
-
|
Does it help #31438? |
Beta Was this translation helpful? Give feedback.
-
|
i agree its not a common usecase, and does not really reflects "orgs", this could also conflict with external identity providers, users having multiple sources for logging in etc.. not a great fan of this feature :( |
Beta Was this translation helpful? Give feedback.
-
|
Using the front-end URL to map organization sounds like a nice capability. However it would require reviewing the host name providers. We also have this #31438. Does it help? @kkcmadhu Can you please elaborate why it does not reflect orgs and the overlap with external IdPs? |
Beta Was this translation helpful? Give feedback.
-
|
The feature road map is #30180. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Realms are a useful concept within Keycloak, but for B2B scenarios where the customer is an organization rather than an individual this is not ideal. The current options are to either model a customer as a realm, or as a user group.
Modelling a customer as a realm is far from ideal as realms are completely independent of each other. Everything has to be re-created in each individual realm. This is also problematic from an application perspective due to realms having separate endpoints, which require the applications to essentially integrate with a different IdP for each customer.
Modelling a customer as a user group works in some scenarios, but comes short in other scenarios. As an example what if a customer wants all their employees to authenticate through their own identity provider? If this identity provider is configured as an identity broker within the Keycloak realm, how do you associate that with the customer? Another example is if there are public APIs available to customers. How would you associate third-party OAuth clients with the customer? There are several deployments of Keycloak where this has been achieved, but results in a lot of additional effort.
As this is a fairly common use-case for Keycloak we should have a built-in concept to solve the B2B scenarios.
What would be very useful in these scenarios is the ability to define an organization (could also be named a tenant, but that somewhat conflicts with realms as they are also tenants, so let's avoid that) within a realm.
An organization within Keycloak should be able to be associated with:
Bring your own identities
In many B2B use-cases the customer have their own identity provider with all their employees. Rather than requiring registering employees in Keycloak they would like to integrate with their existing identity provider. This can be achieved by registering an identity broker with the organization.
Further by leveraging verified domain names it is possible to automatically redirect users to an organizations identity provider automatically based on the domain name used in the login. Let's for example say a user enters
[email protected]if theacme.orgdomain is associated with the "acme" organization in Keycloak it is possible to automatically redirect toidp.acme.org.The automatic redirection relies on an identity-first login, and users authenticating with an email address rather than a username. This may not always feasible so there may be a need for alternative ways approaches to this problem.
An issue with identity brokering is the lack of background updates to users within Keycloak. A common use-case here is if a user leaves an organization and is removed from their identity provider the user will still exist in Keycloak. Another use-case is if users within Keycloak can be granted permissions like roles or groups they are not known to Keycloak until after they first authenticate. Ideal is that organizations can not only be linked to an external identity provider through identity brokering, but also through user federation to be able to synchronize users in the background.
Authentication policies
Different organizations may have different requirements for authentication. For example one organization requires all their employees to use two-factor authentication, while another would like to make this optional. Another example is related to
bring your own identitieswhere one organization requires all employees to authenticate via their own identity provider, while another smaller organization doesn't have their own identity provider and would just like to register the users within Keycloak.Groups
An organization may want to manage their users in groups rather than a flat structure, this would mean that it should be possible to create groups within the organization and map users in the organization to those groups.
In the
bring your own identitiesuse-case it would be useful to be able to map external groups into internal groups within Keycloak.Organization administration
It should be possible for an admin of the organization to manage related settings for the organization such as:
Beta Was this translation helpful? Give feedback.
All reactions