Replies: 14 comments 33 replies
-
I'm one of the authors. If your concern is just licensing because of our Elastic License v2 choice, let's talk about that. I think in the long term, we and our customers would prefer this to be part of Keycloak native. Given that there are hundreds of users of this extension, and that we've had a couple of years of burn-in time with the choices that we made, I think it would be a great starting point for this effort. All of the features you mentioned (domain verification, API changes, UI additions) have already been made by us in some form. Let me know how we can help and participate in this effort @zwitter1 |
Beta Was this translation helpful? Give feedback.
-
|
have you considred keycloak extension https://github.com/p2-inc/keycloak-orgs ? |
Beta Was this translation helpful? Give feedback.
-
DesignOverviewMulti-tenancy is a highly requested feature in keycloak that, as of yet, is not supported in a way that most users find accessible. Specifically, users of keycloak want to be able to create discrete tenants within a single realm that act as a bound of authority on users, groups, and resources. The addition of tenants within a realm would allow for multiple logical "organizations" to exist within a realm that are distinctly separate from each other. For example: Tenant-A users would not be able to operate on Tenant-B users and vice versa. A realm admin would be able to operate on all users regardless of their tenant membership. This functionality would be further supported by new user types like "tenant admin" to compliment a realm admin. Distinct groups should be able to exist within a tenant to further divide users into groups that inherit various roles and permissions. GoalsFor this initial effort, we want to introduce minimal behavior that allows users to be separated into bounds of authority. However, multi-tenancy is often not feature complete without many other features being added. The Non-Goals section will list more specifically things that we are not trying to immediately accomplish but that should be accounted for in future implementation. Goals:
Non-GoalsThese are goals that we SHOULD be working towards in the future but only after getting the base functionality established:
Design ConcernsA couple of more direct approaches have been suggested to add tenancy that we have some concerns about. Namely, adapting groups to function as tenants and adapting realms to function as tenants. The main concern about using existing methods to implement this new functionality is responsibility. Tenants are logical groups that first and foremost serve as bounds of authority on users. This is a departure from how both groups and realms work in their present state. While some functionality that realms have will ultimately need to be tenant specific, realms are designed to represent the entirety of a authn/authz space including resource server management, OIDC/SAML management, and idenity provider management. A lot of this functionality is something that would not be desirable to expose directly to the tenant and the work needed to create a divide between a top level realm and a nested realm would require a logical schism in the codebase in order to implement, increasing complexity and logical overhead for any realm operation or feature implementation. Groups have the inverse issue. Currently, groups do contain users but are designed to perform the logical operation of allowing users to inherit composable sets of roles and permissions based on their group membership. While this does function somewhat as a bound of authority, a lot of functionality would need to be added to groups to make them function as fully functional tenants within the realm. Ultimately, we would still need to introduce functional SPIs for tenant features that would then use groups to calculate out their bounds of authority. This would be necessary to avoid making groups responsible for more than their simple job of composing user roles. Additionally, both approaches introduce another layer of nesting within the database that increases the complexity of both the data model and the queries that would need to be performed to operate on a tenant or limit functionality depending on whether or not the object is considered a tenant. It would also introduce questions of how to best represent these concepts in the UI (does the groups section also show tenant groups, for instance). Suggested SolutionBy introducing a discrete tenant model/representation/entity that exists alongside groups and realms we accomplish a number of things:
|
Beta Was this translation helpful? Give feedback.
-
|
Great write up @alice-wondered ! Couple of questions:
Why only one? The approach we took in our orgs extension was specifically to allow a User to be members of multiple tenants, which is a common use case in SaaS applications. E.g. a Tenant might have employee users with
Given this is already true for a Realm, isn't this redundant?
Does this mean that a Tenant can have a Group that is specific/unique to that Tenant, or that Groups can be used by Tenants, and assigned to members as a tuple? In our modeling of organization roles, we tried both approaches. One where each Tenant can have a unique set of Groups, that only their members can be associated with. The other where we use standard Groups, but the users are associated with those Groups only in the context of their Tenant (e.g. implemented as a different claim). |
Beta Was this translation helpful? Give feedback.
-
I also think this is too strict, as I see use cases outlined by @xgp in practice. A rule that might work could be that a user has only one "home" tenant that effectively owns the account (e.g., that manages the credentials). Still, allow explicit (directed) tenant trust relationships that will enable users from tenant1 to sign in to tenant2. This could work similarly to identity brokering across realm boundaries, where a "proxy" user is created in the target tenant to grant access to tenant-specific applications. A feature that should IMHO be considered from the start is the ability to configure settings, policies, or clients across all (or a subset) of the tenants. |
Beta Was this translation helpful? Give feedback.
-
|
Another often requested feature request I get in practice is the ability to express tenant-specific password policies. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback! I'm going to try and answer everything and hopefully keep the discussion going! Why only one tenant?The goal that we were trying to accomplish by setting this restriction wasn't to lock down users into only accessing the resources of a single tenant. Instead, we're trying to focus on who has authority over an account and ensure that this is enforced at all times. For instance, a user that belongs to the 'Acme-A' tenant would be subject to the authority of that tenant's admins and the policies they set up (2fa, password policies, account deletion, so on). It is definitely true that some users, like contractors, will need to be able to work within multiple tenants. The enforcement of a user 'belonging' to one and only one tenant should not be a bound on authorization. Google Drive is a great showcase, in my opinion, of how this behavior works. Members of the This may not be desire-able in all cases, as then you wouldn't be able to enforce tenant policies over the account in question and it could cause potential security issues. Because of that, another function that we have in mind leads into the next question Why specify that usernames should be unique within a tenant?The goal would be to change the username uniqueness constraint slightly so that they have to be unique within any This would enable the ability to map a single email address login to multiple usernames, all of which could be the same but belong to different tenants. By signing into keycloak with your email, you would then be prompted to select the specific tenant that you want to login as. An extension could also be made to allow account switching, easily allowing a contractor to switch between different tenants depending on the client they're working with. This would give the appearance of having only 'one' account that is jumping between tenants. But under the hood each account would be subject to the authority of the tenant that it belongs to. @thomasdarimont I think this is really similar to the idea that you proposed of having a 'home' tenant. Though in this case because each account is distinctly different I suppose the major difference is that there is no proxy and that each tenant would still have authority over the account in question. Tenant GroupsIn regards to having groups on tenants, the idea is to enable the same permission composition that is available to realms on tenants. Ultimately I think it would be a good idea to have group information mappable to claims for the tenant as well, as that could inform decisions for things like authorization or even UI configurations. I don't think that we would do too much with groups here other than specify that groups can't be moved across tenants (or from a realm into a tenant, or backwards) and that users can only belong to groups that are either within their realm or their tenant. There would also be a bit of work to make sure that moving groups to different parents enforces these boundaries as well. This would effectively allow an admin within a tenant to make groups for their users (and I guess the implicit feature that goes along with this is tenant specific roles) and organize users how they please within groups. I see this feature being extremely helpful for mapping LDAP/AD information into a tenant in the future. |
Beta Was this translation helpful? Give feedback.
-
|
@thomasdarimont completely agree on considering settings, policies, and clients. The authorization behavior within keycloak is extremely flexible so this shouldn't be much of a concern outside of building out the boiler-plate needed for allowing that behavior. Settings and clients will take a bit more thought, but there are a few different ways forward. Tenants should definitely have an While we're focusing first and foremost on establishing the authority of a tenant over a user, I do agree that these are things that need to be able to be added. Having discrete tenant service provider interfaces should help in crafting that behavior. If the SPIs go in the direction of how |
Beta Was this translation helpful? Give feedback.
-
|
Also, I would love to hear more about particular use cases that might come up that vary outside of what a "normal" user would experience. The contractor example was great feedback and a perfect user story! |
Beta Was this translation helpful? Give feedback.
-
I think this raises the concept of "lightweight" versus "heavyweight" tenancy. We refer to these as "customer IAM" and "institutional IAM". When we were originally building our orgs extension, we considered the spectrum between something that could be achieved by essentially tagging with Groups, all the way up to recreating "mini" Realms within a Realm. Let's consider 2 different use cases: 1. Modern enterprise SaaS application (customer IAM)Use case: A company building and hosting a modern enterprise SaaS application wishes to find a CIAM that allows enterprise customers to identify users as members of their organization, and grant roles to those users. The primary integration requirement is to allow identity brokering using the enterprise customers' own identity provider (SAML or OIDC). Concrete example: We have a customer with 260 enterprise customers for their cloud, SaaS application. 248 of those customers have their own identity provider that they must use to authenticate. Any policies that they require for compliance are executed at the external IdP. For the 12 customers that don't have their own, external IdP, they are asked to accept the default policies, or they are given their own Keycloak Realm for an extra cost. All of those IdPs are associated with a customer through our orgs extension, allowing the application to identify organization relationship and authorization. Implementation requirement: It's also important to note that the team building this application is focused on their app, and do not wish to dedicate significant resources to the maintenance and configuration of Keycloak or tenants over time. The more they can "set it and forget it", the better. This is a key requirement that drove us to simplify our orgs extension and focus on self-management by organization admins. 2. Large university (institutional IAM)Use case: A large university with many campuses wishes to find an IAM system that allows students, faculty, staff and contractors to access departmental-, role- and campus-specific resources, as well as global resources for all. That is, some resources/applications will be available to only some personas, and some will be available to all. Concrete example: We have a customer who is a large, for-profit US university, with a large in-person and virtual student body, and complex tiers of staff, faculty and outside contractors. Each department is given their own Keycloak Realm from a Keycloak cluster that is centrally managed by their IT team. The individual department administrators have nearly full control in setting policies and protecting applications that only their Users can access. The central IT team also manages a central Realm that owns all of the student users, and all of the departmental Realms are Identity Providers in that Realm. The central Realm now also uses our orgs extension to associate Users to department, giving global applications the ability to determine department relationship. Implementation requirement: The central IT team is already familiar with running large, complex applications, and providing them as services to their department administrators. Using a Realm-per-tenant approach fits into their standard model, and did not present any departure from their expectation of configuration or operation requirements. We had the above 2 use cases as consulting customers before our orgs extension was complete, and it was a significant reason we went with a "lightweight" concept of tenancy in our extension. For the institutional use case Realm-per-tenant already works, and there tend to be IT resources at those customers where configuration, administration and maintenance of those setups is expected and no problem. We could think of no legitimate reason to try to rebuild "mini" Realms, with a significant duplication of functionality, as the use case was essentially already solved. |
Beta Was this translation helpful? Give feedback.
-
|
Somewhat OT, but this was a suggestion that came up that I related to Chris Zietlow:
Another one that we came up with is 4) It would (potentially) be an opportunity to create extension points to the "new" admin console, which are now, in our experience, significantly harder to maintain with frequent breaking changes. |
Beta Was this translation helpful? Give feedback.
-
|
@xgp I'm trying out your extension and I'm wondering if (in addition to many more capabilities on top of it, such as invitation) what it basically does is to introduce an By having organizations managed from a realm, users bound to an organization can now have access to realm-level clients (e.g.: APIs a company is offering to third parties). The extension also provides a I know there are many more capabilities, but I would like to check if these are the top-level requirements you are addressing:
Here are the requirements I'm missing but not sure if they apply to the problem(s) you are solving:
All that make sense? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @pedroigor Thanks for the thoughtful evaluation. I think you understand it well. Regarding the specific points: Current requirements addressed:
Future/Unimplemented:
Please let me know if I can help as you try it out. Also, I'll be giving a presentation on the orgs extension next week at @dasniko 's Keycloak Dev Day in Frankfurt in case you'll be there (in person or virtually). I'll also try to post the video here afterwards. |
Beta Was this translation helpful? Give feedback.
-
|
@xgp Thanks. I guess those are the top-level requirements you want/need from upstream and perhaps what makes sense to deliver first. If so, I would like your help (and from others) to get more details about each requirement so that we can start thinking about how to start implementing it upstream. I would like to start creating some epics/issues for each of those requirements.
Too far away ... But it would be nice to watch the video. Please link it here. |
Beta Was this translation helpful? Give feedback.
-
|
@xgp are you able to share the video? thank you. |
Beta Was this translation helpful? Give feedback.
-
|
@lsmith77 I don't have a copy of it. @dasniko has said he will post it to his Youtube channel once he has time to edit it. |
Beta Was this translation helpful? Give feedback.
-
|
It's now published: https://youtu.be/DNq51wWw3F4 |
Beta Was this translation helpful? Give feedback.
-
|
@xgp Could you give more details about why you gave up using groups and realms to solve the problem? I see you mention this in the README file but without much detail. We have been discussing the different solutions to solve this problem and all of them have pros and cons. For instance, having a tenancy/organization object model helps to build on top of existing realm capabilities with the cost of introducing more changes and potentially reaching a point where an organization behaves like a realm. On the other hand, using realms gives us all the capabilities for free with the cost of potential scalability and complexities when dealing with different "types" of realms and how we use a realm object everywhere. The same for advanced groups, which is probably the easiest path but it also has potential scalability and additional complexity as we now have groups kinda behaving like a realm. Kinda similar to the organization object model as we are leveraging an existing entity (that already serves as a user repository, token mapping, etc) other than the realm to represent organizations and link things around. Your input should be helpful to understand what you experienced in practice and why you choose the organization object model approach. |
Beta Was this translation helpful? Give feedback.
-
|
Sure @pedroigor . Keep in mind that one of our primary restrictions was the we could not modify Keycloak functionality, and that we were restricted by only what was available to extensions. Per my comment above, I think this effort is a great opportunity to revisit the extension points and implement multi-tenancy as an extension. RealmsFor this, we investigated creating a mechanism for external Realm "templates" that would allow us to easily create different "types" of "child" Realms, and make the associations within another "parent" realm that they would be brokers to. We encountered a few problems:
Our conclusion was that it was far from "free", it came with significant scalability and complexity costs, and ultimately wouldn't work in the existing Admin UI GroupsWe considered this more seriously, as we had already done a prototype for a customer using Groups. We tried 2 approaches
We encountered the following problems:
When you say "advanced groups", are you talking about this proposal? I think that's basically an description of our orgs extension, using changing Groups in Keycloak as the implementation strategy. I don't really have an opinion on the value of doing that over making a first-class Organization entity, other than that overloading probably makes sense to us (developers familiar with Keycloak), but will produce confusion among others. I see it from the perspective of "let's change as little as possible", but forgetting that this is actually a significant change, and how we communicate it (through design of the feature, as well as documentation) is paramount. One side note is that a non-insignificant reason we chose to create a first-class Organization entity was that other companies (e.g. Auth0 and nascent companies like Zitadel and WorkOS) were using the same terminology and features at the time. Developers will more easily understand and adopt something that is familiar. |
Beta Was this translation helpful? Give feedback.
-
|
I can't speak for anyone else but I personally find this really useful as input for the design/solution discussion, so thank you for the write up! |
Beta Was this translation helpful? Give feedback.
-
|
Hi, @xgp and others interested in the support for organizations. @vramik and I have started to work on it and the plan is to tackle each of the points we discussed here as a first step. We understand that those are the core requirements to make the feature available and to make it possible to gather feedback about its capabilities. In this first iteration, we are delivering:
The corresponding epic is #27928. All the work is in upstream/main and should be available from Keycloak 25 as an experimental feature. Thanks for all the discussion here and we are looking forward to collaborating with you. Please, let us know about any suggestions/comments on what is being delivered. |
Beta Was this translation helpful? Give feedback.
-
|
@pedroigor I have one question about the implementation. In our current solution each organization has the ability to choose the authentication methods (email/password, google, microsoft, saml ..). we do plan to offering organization specific login screens using custom domains. but we wonder if your solution plan includes this ability. at the same time if a user is a member of 2 organizations with the same email, we would ideally then have some way to force the user to use the organization preferred login method before gaining access. I guess the flow would be as follows:
So what we would hope to see supported:
This would still require the application to check if the correct authentication method is used before granting access to the organizations data. |
Beta Was this translation helpful? Give feedback.
-
We are not considering a migration plan for those using the P2 extension. But both share the same core requirements where these requirements are being gathered from this discussion and use cases at Red Hat. We are focusing on B2B use cases and that is why I asked about what you meant by "SaaS" in your previous comment. SaaS involves more things than what we are planning for Keycloak Organization and we are not delivering the possibility of using Keycloak as an (S)IaaS (not yet). Our main goal with Keycloak Organization is to leverage the existing (IAM) capabilities we have to solve B2B use cases. That means solving all the core requirements herein discussed and those you mentioned above:
We are considering this capability. It is related to what is being discussed (so far, I think only internally within core-clients team) around authentication policies. In a nutshell, you should be able to specify how organization members authenticate to an organization (using mechanisms other than the identity broker bound with an organization) so that you can enforce different factors and steps during authentication. What else do you have in mind about this one?
Yes, we just leverage what we have today. Not only
We have this requirement from use cases at Red Hat. And this one is a bit more hairy considering how we handle browser sessions today. I guess you mean here something like Google where you can switch between accounts, right? This one should not be part of a v1 of Keycloak Organization. Out of curiosity, some of the requirements above are not available yet from P2 extension, are they? |
Beta Was this translation helpful? Give feedback.
-
|
@lsmith77 One last thing, and about themes. Did you mention the possibility of having customizations to login themes on a per-organization basis? This is a tricky one and how much we can do depends on how far we want to allow customization to themes. There is a very thin border-line between SaaS and B2B, I think, where the latter does not imply the same level of customization when you are doing SaaS. wdyt? |
Beta Was this translation helpful? Give feedback.
-
|
@pedroigor ok thank you. I guess once the solution is released work on a migration path can begin from the p2 community. that being said, we will likely plan our solution in such a way, that we could re-create the organization setup in keycloak from our own app specific database which would ease a possible migration. You mentioned that you want to support org specific login methods and the ability to force users to re-authenticate based on those requirements. Doesn't this then mean that users will then need to authenticate against a specific organization? Which in turn would mean it is all the more relevant to offer organization specific login screens. The way we had planned to deal with this with p2, where afaik you do not authenticate against a specific organization (though organizations can setup their own providers), was allow users to select the organization. we would then introspect the authentication token to determine what login method was used and if the login method is not acceptable to the chosen organization force them to authenticate with an acceptable login method. |
Beta Was this translation helpful? Give feedback.
-
Not necessarily as authentication and themes are distinct aspects. I see your point and I can see some level of theme customization on a per-organization basis. However, how much we want to customize will proportionally add complexity to the feature. The main reason is that organizations are not managing Keycloak installations and deploying their own themes so we need to come up with something else, from the administration console or organization self-service, to allow organization administrators to customize the L&F.
Selecting an organization is something we need more discussion. In the first version, realms must be set with an identifier-first login flow so that Keycloak can easily map the user's email domain to an organization. As a result, it will automatically redirect the user to the identity provider associated with it. See #28273 and feel free to comment there. |
Beta Was this translation helpful? Give feedback.
-
|
Hi All, we finally managed to define the scope and the roadmap of the First Release of Keycloak Organizations feature. As you'll see from the link above, we are not yet delivering everything we have planned but the backbone of Keycloak Organizations. Any feedback and contributions are welcome. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, I’m a bit late to the party, a bit of exchanges to catch up. I can provide some ideas or some use cases to think around. For the context we are a start-up working on a SaaS Platform bringing together different actors in the same field. We first tried to use the Groups of Keycloak as Tenant to map it to Companies, but at some point we found it a bit blocking for our use case (maybe we took a wrong direction and we lacked some experiences with Keycloak) and we felt that some functionalities were missing (which is fine, « 80% » rule). Here is our use case to provide some « case study » 1. User can be part of multiple Organizations with the same email.For example, we can have Organization A (building stuff) and we can have Organization B (doing consulting for building stuff). So on the same platform, a user from Organization B can temporarily be part of Organization A as a consultant for a project of X weeks or months. 2. We can assign "tiers" (realm role in fact) to OrganizationsWe have different tiers (free, premium, enterprise… etc), which gives access to different services or functionalities. 3. Active Organization and switching Organization.With that, we need to be able to select or define an « Active Organization » during the session which should be reflected in the current user token (adjust roles, organization info like id & name). 4. Self manage membersWe want Organizations to self-manage their members and informations. 5. SSOWe want to be able to configure Organizations SSO or let them configure it. Other:
And probably more that I forget right now. |
Beta Was this translation helpful? Give feedback.
-
|
@MGLL Helpful feedback, thanks. @xgp Is a great extension and does a lot. Hopefully, we'll align our solution with the requirements being solved by their extension and collaborate toward the core functionality of organizations. Not easy, but we'll try :) In the mean time, please help us to consolidate the first version of this feature as per #28609. We want to deliver in the first version the core bits of this feature. By core bits, you should not expect things like self-service but the baseline to start building more stuff on top of it. Next iterations will be delivering more and more stuff. If you think we should consider delivering something in the first release, please add a comment there.
We are leveraging groups behind the scenes to assign members to an organization. By doing that, having the same users in two distinct organizations is a matter of a user joining a group.
I like the idea behind this proposal. If I understood correctly, the As mentioned before, as we have organizations backed by a group, assigning a realm/tier role to an organization could automatically grant these roles to all its members.
We have this requirement documented but not yet started.
We want self-service too but our initial focus are the operations from the perspective of the Keycloak Administrator. As soon as we are good with the core capabilities we would like to focus on the Organization Administrator persona and related use cases such as self-service. It is a key capability for CIAM/B2B ...
Not sure exactly what you mean by configure SSO but the @keycloak/core-clients team is designing authentication policies. Based on this feature you'll be able to manage the different authentication aspects of a realm. Like authentication flows but without all the burden of managing flows and steps. Keycloak Organization will leverage that to deliver authentication policies on a per-organization basis.
Hierarchies are always tricky. Not sure if we want to consider this. At least not until we are done with the core functionality.
This is also planned.
We have this implemented already but not yet with all the dynamism you have in User Profile. But we have a similar requirement from sso.redhat.com.
As mentioned before, these should be addressed by authentication policies. |
Beta Was this translation helpful? Give feedback.
-
Would that mean, that creating an organization also create a group behind the scenes?
Yes, tier idea is based on the current group logic where assigning a role on the group assign it to all members. Idea would be the same for organizations.
Sorry I was referring to the capacity to create / assign organizations specific SSO. So, when I try to login with my company email which use a specific SSO, I'm redirected to authenticate there. I'm not sure if it's covered by what you mentioned same as for "Organization level password policies or 2FA enforcement.". If it's the case, let me know. |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps "also delete associated users if the organization is deleted" is a matter of who "owns" the user? If the user is "owned" by the organization then deleting an organization (group) could legitimately also delete the users. Think of using the organization as a tenant for a SaaS app who no longer wants to use our service. On the other hand, if users, who are "owned" by the realm and assigned to one or more organizations, then it's just like a group assignment with more complex rules. There is also another mixed use case where users might have an "owning" / "home organization" and have some sort of relationship with other organizations (org1 can manage users from org2 and org3). Is this also already covered by the current implementation? |
Beta Was this translation helpful? Give feedback.
-
|
The first two cases we are covering now by #29029. The second one is not yet supported as we don't allow an account to join multiple organizations. We are re-evaluating this decision though and perhaps we can try to include this capability in the first release. The argument for not doing it now is that we already have high-priority tasks that are related to the core capabilities and adding support for multiple accounts should not be a hard task once the core capabilities are set in stone. Wdyt? |
Beta Was this translation helpful? Give feedback.
-
@MGLL Yes, this is an implementation detail though and administrators should not worry about these groups and how they linked to organizations.
Yes, we are working on it so that you can have multiple brokers associated with an organization where each broker might be associated with a specific domain (from the domains associated with the organization). When a user authenticates, the user is either automatically redirected to the identity provider that matches the email domain or is presented with a list of brokers to choose. |
Beta Was this translation helpful? Give feedback.
-
|
Hi All, As part of the first release of Keycloak Organization, we have changed a bit the scope to allow the possibility of linking existing users to a realm. For more details, see #29023. There are some key points about the aforementioned issue that I would like to share with you and see if you have any feedback. So far, we have been focusing on the use cases where there is a strong relationship between a member and the organization they belong to. In other words, when you remove an organization these members are also removed from the realm. For instance, a member whose identity originated from the identity provider (federation) associated with an organization makes no sense to exist if the organization no longer exists. Kinda of an aggregation relationship where the part can not live without the whole. On the other hand, when you think about linking existing users to an organization you have a different situation where the member's identity is not intrinsically linked to the organization but to the realm. In this case, the member identity should exist regardless of the existence of a specific organization. For this reason, we are planning (see #29029) to introduce different constraints around members depending on the relationship between their identities and an organization. We are also introducing the term "managed member" to refer to members whose identities have a strong relationship with an organization. |
Beta Was this translation helpful? Give feedback.
-
|
@xgp Do you have something similar in the extension? How are you handling these different types of members or there isn't a distinction at all? |
Beta Was this translation helpful? Give feedback.
-
|
the entire organization concept is optional. so users can be members in 0 to n organizations. semi-related: when logging in you can set an “active organization” on the access token, either way you can map the list of organizations of the user into the access token. |
Beta Was this translation helpful? Give feedback.
-
|
Feedback I could provide is that indeed organization is optional. So, in the realm, a user can have 0 or n organizations. On my side, the use case is that deleting an organization shouldn't delete users attached to it. |
Beta Was this translation helpful? Give feedback.
-
But why you would want to keep users federated from the identity provider linked to the organization when the organization is removed? Going a bit further, how we handle users federated from the identity provider when it is removed from the organization? |
Beta Was this translation helpful? Give feedback.
-
|
Ah sorry, missed the
I guess the same way, remove the user? |
Beta Was this translation helpful? Give feedback.
-
|
Would it break existing brokers? Is the org concept an add on and opt in?Will it break exisitng settings/urls etc?
If some one want to migrate existing realms and consolidate them jnder new org and migrate all brokers which could be at realm level to orgs,is that possible? Will there be a migration path provided?
Yahoo Mail: Search, organise, conquer
On Thu, 25 Apr 2024 at 2:30 am, Pedro ***@***.***> wrote:
Would that mean, that creating an organization also create a group behind the scenes?
@MGLL Yes, this is an implementation detail though and administrators should not worry about these groups and how they linked to organizations.
Sorry I was referring to the capacity to create / assign organizations specific SSO. So, when I try to login with my company email which use a specific SSO, I'm redirected to authenticate there.
Then, from a KC Administrator, there is multiple SSO, but from an organization POV (self-managing) I can see my SSO and configure it.
Yes, we are working on it so that you can have multiple brokers associated with an organization where each broker might be associated with a specific domain (from the domains associated with the organization). When a user authenticates, the user is either automatically redirected to the identity provider that matches the email domain or is presented with a list of brokers to choose.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
It should not break realm-level brokers.
Yes, there is a switch you can enable/disable org behavior to the realm.
The way the feature is enabled now is based on changes to both browser and first broker login flows and it works fine for new realms. But for existing realms, we did not have discussions how we are going to make it easier to enable org-specific behavior.
Not in this first release. We really want to deliver a trial so that we can focus on the core capabilities and behavior. We can discuss until 26 (target release to make it supported) how to deal with migrating realms to orgs and if it makes sense. |
Beta Was this translation helpful? Give feedback.
-
Looking to open the floor for discussion about an alternative pathway for implementing native multi-tenancy support within keycloak.
What are we looking to do
The Red Hat team is proposing the inclusion of a new hierarchal organization structure that we are referring to as the Tenant. A Tenant will serve as a root level grouping within the realm that provides scoped authority to its own users and assets. Each Realm will be capable of supporting multiple tenants, and all of these tenants will have access to clients registered to the realm.
Why is this necessary
The goal of this change is to provide Keycloak's consumers with enhanced control over b2b integrations. As business scales there is often an increased need for more robust user management, and access regulation solutions. This becomes especially evident with further integration of partnering organizations. To achieve this, we require an additional layer within keycloak that enables us to draw links between individual users and their governing organizations (if present). This additional layer (the tenant), needs to be highly configurable to meet the varying needs of keycloak consumers and have the potential to scale to their business.
Approach
The Introduction of a "Tenant"
Domain Verification
REST API
UI Additions
Acknowledgments
Advanced Groups
We will likely be drawing some inspiration from this and working with the keycloak team directly to come up with the final solution. Enhancements to groups is already in our considerations for this project.
keycloak orgs extension
This is an interesting solution to the problem though we are a little weary of the licensing. We would ultimately prefer to implement and share a native keycloak solution with the community.
Beta Was this translation helpful? Give feedback.
All reactions