[Discussion] Organization --> [sub]Organization(s) & Organization --> Groups --> Roles

[Frank-D]

Hi @xgp,
following my original interest in this keycloak organization project/extension (ref.) a few months back, I've finally reached a point in my app. development where this multi-tenants support is much needed, and so I've just installed this keycloak extension locally and started playing with it.

Questions:

1- Is there any plan to support multiple [sub]organizations under the same tenant/organization?

Context:
No need to be hierarchical, could be as a nice-to-have, but even a simple flat model of 1 org to many [sub] accounts would have been really nice, where a [sub]account could represent a company's division, or department, or team, or it could simply be a user's workspace, where the user is allowed to have a few of those.

Of course, I could assign the user to multiple organizations to model that, but then I loose many benefits of one single organization encapsulation. I suppose allowing an organization to be the child of another organization could have been enough here to allow such hierarchical mapping, but perhaps it is easier said than done, when thinking about the impact of such model on the IDP for instance, but not impossible.

---

2- Is there any plan to support assigning groups to a user at the "organization level", instead of only roles?
(seems to be exactly related to #25, but I wanted to circle back on this in case plans may have changed since then, now that such issue is closed..)

Context:
In my case, I wanted to leverage the keycloak 'groups' to model my application roles, and the keycloak 'roles' to model my application fine-grained permissions (I've already done so actually, but without any multi-tenant support thus far, reason why I'm here now;) ).

Basically, I was planning to mainly only assign users to groups, and each group is associated to multiple roles, so that by assigning a user to a specific group, the user will automatically inherit the group's associated roles (e.g. app.'s fine-grained permissions), without having to assign each and every single fine-grained permissions to each individual user.

And I was planning to have all tenants support the same list of defined groups by default (e.g. app. roles), and in the event that a specific tenant requires a different set of fine-grained permissions (e.g. keycloak roles) for a given role (e.g. keycloak group), I could always define another unique group that only that tenant would leverage, but in the end, such group will have to be composed of the already existing keycloak roles which are used in the application code (the app. is not checking for the existence of the user groups, but rather the user roles (e.g. app. fine-grained permissions).

Thanks

[xgp]

@Frank-D Thanks for your thorough and thoughtful questions.

Regarding 1, there are no plans to create a hierarchy among organizations. When we originally built this out, organizations was mostly a vehicle to create mutli-IdP, multi-tenancy. In the original prototype we did actually have a concept of multiple, hierarchical "teams" as children to an organization, but we removed it, as there was no demand for it, and we thought it unnecessarily introduced complexity. However, if you think there would be an elegant way to achieve this, we'd listen to a design proposal or review a PR.

Regarding 2, we've talked about it in #25 and #48, but haven't started execution yet. Also, there are some problems with using Keycloak's native groups and roles along with the roles for the organization extension. There were some tradeoffs we had to make based on what is/was available to us when building an extension.

[Frank-D]

Thanks for your answers @xgp.

I won't comment back on point # 2 in here, since I've added a response into #48 instead, I realize it belongs over there, sorry.

As for point # 1 about supporting any kind of orgs hierarchy, indeed I saw in this extension code that the "organization team" entity is still in there in the source code, and it seems to be exactly what I had in mind!

I haven't looked at the entire code to understand what it does/support etc, but I can see from high-level that it is exactly aligned with the idea that I had in mind over here. For sure the ability to support a full hierarchy of [ org ] --> [ team] --> [(sub) team] --> [(sub) team] would be ideal, since I can see many people needing this, but I believe that simply supporting one [organization] mapped to many [teams] (e.g. flat hierarchy) would solve probably 80% of the situations, anyone correct me if I'm wrong.

What I've personally seen in the recent years at the office with large B2B customers of my company's SaaS platform, is that some of those large customers may be doing business from different countries, where for some of them each country office is managed as a separate entity / sub-division, and this means sometimes on the tech side, it could come with their own IDP etc. So we're actually talking about "sub-tenants" in the end here, where not only the different B2B customers have to be modelled as different tenants, but even within a specific customer/organization, their different divisions also requires to be modelled as different [sub]-tenants within that org, so that their users/members can authenticate using their own division's IDP for instance, and also be isolated data-wise, based on their division/[sub-tenant] and authorization (groups/roles) within that sub-tenant.

I believe "org team" could solve exactly that, if we could:

1. allow to map an existing [kc IDP] to an [org team], where the logic would be that if a team has no "idp override/mapping", then the team's idp falls back on the team's org IDP.

2. allow to map/assign "org roles (and/or groups!)" to "org's team members", exactly the same as an org. member (actually, ideally I wouldn't introduce a new member entity/model, we should keep the same already existing org member entity imo, that is already linked to an organization, that's fine, and simply add a new ~ "Organization Team/Member/User Memberships" mapping, which maps a user/member to a list of one to many org teams, since a user could belong to multiple teams, or only one. And to remain backward compatible and not introduce any breaking change, this new team memberships mapping is totally optional, can remain null, until a user create a first team mapping inside the organization.

What do you think @xgp? Is this something you believe is 1) possible to be done as part of keycloak spi extension in general, and 2) is something that could be interesting for your phase-two multi-tenants extension?

Here are the 3 existing 'team-related' classes that I found to be still present in current source code of this extension, even though I'm not sure I would duplicate the "member" entity and end up with 2 member entities (one for org, one for team), unless you guys had a very specific reason for doing so..?

• TeamEntity
• TeamAttributeEntity
• TeamMemberEntity

Btw, I'm not asking you to implement any of this if you guys at phase-two simply don't need this for your own customers and have no time to participate into this, I am more curious to know if that is something you would be interested to see added into your phase-two extension by the community.

Cheers

[Frank-D]

UPDATE:
See #48 (comment).

This issue can either be converted to a discussion, if ever there might be a plan to support [sub-] teams in this extension, or else, I guess we can close it as won't fix.