Advanced groups #19055

stianst · 2023-03-16T06:52:44Z

stianst
Mar 16, 2023
Maintainer

Group options

Group top-level type
- Organization - organization aware groups
- Context - context aware groups
- Default - plain old style groups
Group second-level type
- Context
- Default - plain old style groups

Organization Groups

Must be top-level groups
- Only supported if top-level-groups are organization aware
Top-level groups can be marked as organization groups:
- Group attribute: kc.group.type=organization
Can be associated with a domain
- Group attribute: kc.organization.domain=
- Can we build in built-in support for safely linking with a domain?
- We can have an option to allow a domain to be fully owned by an organization group, or allow users outside of the group to use the same email domain
  - Could have an option on the organization group perhaps to mark the domain as fully owned, or partially owned
- Domains should probably only be associated with a single organization group though
Can be associated with a authentication policy
- Group attribute: kc.organization.authenticationPolicy=
User can only be a member of a single organization group
- May support multiple in the future, but a single initially

Context Groups

Either top-level groups, or 2nd-level groups
- Depending on group options
Users can be members of multiple context groups
Users can have overriding attributes based on the context group
- User attribute: kc.context..
Users can have different sub based on context groups

Client context

During an authentication request a client or the user is required to select the context if the user is associated with more than one context.

Tokens can only be issued for a single context

Clients can have the context scope as required or optional.

If clients have context scope as optional and don’t include it in the authorization/authentication request, any context groups (or attributes) are excluded as there will be no mappers looking for the special user attributes

Clients select context with the context scope (name should be configurable), for example:

/auth?context=<group-name> (parameterized scope basically, can’t remember the syntax so this could be wrong)

If the context scope is required, or the client doesn’t specify the value of the parameterized scope the following will happen:

If user is not associated with a context group it will ignore the context request
If a user is associated with a single context group that will be used
If the user is associated with more than one context group the user will need to select the context group before continuing

User account selection

During login we need to know the organization group to apply the correct IdP and authentication policy.

Logic for looking up users by email ([email protected])

Look for user by email
If one is found we know the organization group
If one doesn’t exist we look for an organization group by email domain
If multiple are found we allow users to select
** User enumeration is an issue here, but that is an issue regardless for any realms that have self-registration enabled
** This should be a feature enabled at the realm level though

Ability to look up users with organization aware lookup (#, for example stian#redhat.com)

Optional for users to use this, and they don’t really need to unless they are using an email that is associated with multiple users where on is associated with a organization group and one is not
Only relevant if a domain is not hard linked to a single organization group, as otherwise we can just do by email
On identity first login flows this can either be a single field asking user to enter the ‘#’ separator or it could be two separate fields
This is not really good UX though, users want to just use their username of choice or email, and not some weird stuff ;)

Clients and groups

We’ll want to be able to associate clients (service accounts and 3rd party clients) with organizations. For service accounts that could be handled by adding the service account user to a group. For other client types we will also want to be able to associate them with a group.

This allows us to put clients into a group, which allows us to allow some users to manage clients in a specific group only.

Roles

Role namespaces would allow us greater flexibility to associate roles with different things. For example:

realm/my-role			Realm role
clients/my-client/my-role	Client role
organization/my-role		Organization role

It would also open up the ability to share a group of roles across multiple clients, as a client could default to using clients/<client-id> namespace, but could be configured to a different role namespace.

We can also do smart stuff around flattening roles into tokens by removing the full namespace, parts of it, or including the full namespace. With a new role mapper we can have a more consistent/clean layout of roles in tokens without breaking backwards compatiblity:

{
	roles:
		realm:
			my-role
		clients:
			my-client-role
}

jbman · 2023-03-20T12:18:56Z

jbman
Mar 20, 2023

A common requirement across different kind of groups (Organization, Workspase, Project, ...):
The members of a of group need to view and manage a subset of all users, clients, roles, IdPs or whatever is managed at realm level currently.
(Note: I use the word group but it doesn't have to be the Keycloak entity group.)

Before getting more specific how these groups like Organization, Workspace or project, it would be helpful to control access in a way, that

allows the same entity to be viewed or updated by multiples parties groups
defines ownership of data: An owner has final control over allowing or revoking access to other groups
allows one user account to work within different context: one of the groups where the account is owner or allowed to view or manage.

Context should be selected by client and/or user at authorization time which then results in an access token just for this context (= one specific group).

How to manage and store who has access?
For an efficient resolution of viewable entities, the owner group and the list of groups which have access should be stored for each entity.
In addition each account can have group specific roles, like e.g. group-x:view (view every entity which has group x listed) or group-x:manage (manage every entity which has group x listed).

0 replies

LMonert · 2023-03-20T19:59:24Z

LMonert
Mar 20, 2023

Would this also enable functionality like this plugin https://github.com/sventorben/keycloak-home-idp-discovery ? We use it in a project and it would be a great addition to standard Keycloak.

0 replies

antikalk · 2023-05-13T18:01:27Z

antikalk
May 13, 2023

Would really appreciate this feature! I think it would be a great addition for keycloak to allow different organizations / groups with their own user management permissions within one keycloak realm. So a big +1 from my side 👍

0 replies

Frank-D · 2023-06-07T22:59:47Z

Frank-D
Jun 7, 2023

That's very interesting, and promising.

I was about to possibly write my own keycloak spi extension (..and add support for multi-tenancy + multi-workspaces/teams), for a multi-tenants saas project that I'm working on.

Perhaps I don't need as many things supported as what has been highlighted here (at least not for day 1 / mvp), however I see a lot of similarities between the extension I had in mind and current initiative, so I thought of sharing my high level game plan for this upcoming extension, if that can help current initiative a bit.

At this point, I'm still at the point of evaluating if it's worth developing such extension, or simply going with alternative authn/authz options, which are coming more and more with such saas-related multi-tenants offering (..and so, I really think that it would be a great time for keycloak to support that asap, within one single realm to avoid duplication of resources across realms, among many other multi-realms solution limitations or pain-points).

One player that I had in mind was Zitadel for instance, with their [ 1 Organization to * Projects ] multi-tenancy + multi-workspaces concept. I know Auth0 also has a concept of multiple Organizations, probably like a few other alternatives, but they don't have a free/oos option like keycloak and Zitadel has.

Anyhow, here's how I was planning to extend keycloak:

EXISTING / KC OOTB:

(among many other ootb kc features, but those are pertinent to the extension items listed later down below...)

o1) KC OOTB: Given existing 'realm user' entity... (represents a human that might want to login and access applications...)
entity: [kc realm user]

o2) KC OOTB: Given existing 'realm role' entity... (can represent a fine-grained permission in simple RBAC applications)
entity: [kc realm role]

o3) KC OOTB: Given existing 'realm group' entity... (can represent a role - e.g. group of permissions - in simple RBAC applications)
entity: [kc realm group]

o4) KC OOTB: Given existing 'realm client' entity... (can represent the calling app./client for service-to-service authn/authz communications)
entity: [kc realm client]

o5) KC OOTB: Given existing 'realm idp' entity... (can represent a remote/external idp, for which keycloak will relay authentication to)
entity: [kc realm idp]

o6) KC OOTB: Maintain relation between 'realm user' and 'realm role(s)' (ability to assign 1 to * role(s) to 1 user)
relation/mapping: [realm user] 1--* [realm role(s)]

o7) KC OOTB: Maintain relation between 'realm group' and 'realm role(s)' (ability to assign 1 to * role(s) to 1 group)
relation/mapping: [realm group] 1--* [realm role(s)]

o8) KC OOTB: Maintain relation between 'realm user' and 'realm group(s)' (ability to assign 1 to * group(s) to 1 user)
relation/mapping: [realm user] 1--* [realm group(s)]

o9) KC OOTB: Maintain relation between 'realm idp' and 'realm user(s)'
relation/mapping: [kc realm idp] 1--* [kc realm user(s)]

o10) KC OOTB: Maintain all existing ootb KC logic around users and roles/groups/idp for all existing kc authn/authz logic.

NEW / KC EXTENSION:

e1) KC EXT: New custom entity 'realm organization'
entity: [realm organization]

e2) KC EXT: New custom entity 'realm org. team' (that new ~subgroup entity can represent - in any given app/business context - a team, department, division, subsidiary or literally a workspace, etc)
entity: [realm organization team]

e3) KC EXT: New custom relation between 'kc realm' and 'realm organization(s)' (ability to create & assign 1 to * orgs to 1 realm)
relation/mapping: [kc realm] 1--* [realm organization(s)]

e4) KC EXT: New custom relation between 'realm organization' and 'kc realm idp' (ability to assign 1 idp to 1 org.)
relation/mapping: [realm organization] 1--1 [kc realm idp]

e5) KC EXT: New custom relation between 'realm organization' and 'kc realm user(s)' (ability to assign 1 to * user(s) to 1 org.)
relation/mapping: [realm organization] 1--* [kc realm user(s)]

e6) KC EXT: New custom relation between 'realm organization' and 'kc realm user' and 'kc realm role(s)' (ability to assign 1 to * role(s) to 1 user within 1 org.)
relation/mapping: [realm organization] 1--1 [kc realm user] 1--* [kc realm role(s)]

e7) KC EXT: New custom relation between 'realm organization' and 'kc realm user' and 'kc realm group(s)' (ability to assign 1 to * group(s) to 1 user within 1 org.)
relation/mapping: [realm organization] 1--1 [kc realm user] 1--* [kc realm group(s)]

e8) KC EXT: New custom relation between 'realm organization' and 'kc realm client(s)' (ability to assign 1 to * client(s) to 1 org.)
relation/mapping: [realm organization] 1--* [kc realm client(s)]

e9) KC EXT: New custom relation between 'realm organization' and 'realm org. team(s)' (ability to create & assign 1 to * org. team(s) to 1 org.)
relation/mapping: [realm organization] 1--* [realm org. team(s)]

e10) KC EXT: New custom relation between 'realm org. team' and 'kc realm idp' (ability to assign 1 idp to 1 org. team, to allow overriding default org. idp for those team's users)
relation/mapping: [realm org. team] 1--1 [kc realm idp]

e11) KC EXT: New custom relation between 'realm org. team' and 'kc realm user(s)' (ability to assign 1 to * user(s) to 1 org. team)
relation/mapping: [realm org. team] 1--* [kc realm user(s)]

e12) KC EXT: New custom relation between 'realm org. team' and 'kc realm user' and 'kc realm role(s)' (ability to assign 1 to * role(s) to 1 user within 1 org. team)
relation/mapping: [realm org. team] 1--1 [kc realm user] 1--* [kc realm role(s)]

e13) KC EXT: New custom relation between 'realm org. team' and 'kc realm user' and 'kc realm group(s)' (ability to assign 1 to * group(s) to 1 user within 1 org. team)
relation/mapping: [realm org. team] 1--1 [kc realm user] 1--* [kc realm group(s)]

e14) KC EXT: New custom relation between 'realm org. team' and 'kc realm client(s)' (ability to assign 1 to * client(s) to 1 org. team)
relation/mapping: [realm org. team] 1--* [kc realm client(s)]

Results of those extension points, offering some great [SaaS] multi-tenants abilities:

r1) Allows to define as many tenants (org.) and sub-tenants (org. teams) as we need, within a single given kc realm.

r2) Allows to define/map a default IDP at the org. level (all users within that org. would be linked to such IDP by default, unless overridden at their team level...)

r3) Allows to override default org. IDP at the org. team level, if a given sub-tenant/team uses a different IDP (often the case, when an organization has multiple divisions located in multiple countries, each country division may end up having their own IDP; same principle with an owning parent/holding company having multiple subsidiaries, with each their own idp).

r4) Allows to define/map multiple clients at the org. level.

r5) Allows to define/map multiple clients at the org. team level.

r6) Allows to assign users directly under an org. without any teams defined (if one's business use case doesn't require/involve sub teams)

r7) Allows to assign users directly under one or more org. team(s) (a team can represent many different things in any given app, from a sub-tenant, to a working team, division, department, or simply a separate workspace)

r8) Allows to re-use and assign existing ootb kc roles and groups to users under org. and/or org. teams. This way, one can benefit from assigning the same role/group directly to users using the kc ootb management screens/api, AND/OR assign those same roles/groups to users under a specific organization or organization team context.

r9) All those additional customized/extended features must/will not interfere or impact any existing KC ootb features, that's the ultimate goal here. The only things that get affected in the end, are the following 2 items only:

r9.a) IDP at org. or org. team level for users, hence overriding default KC ootb behaviour of an IDP for entire realm context (we still create IDP at realm level using existing screen/api, but then we map it to orgs and teams, so that it applies only to users under that specific context...).

r9.b) Access Token and/or UserInfo can get updated, if selected in corresponding mapper, to contain these new orgs/teams' roles/groups mappings. Again, not impacting the already existing roles/groups mapping done at the realm level; we're talking about adding new fields to the existing access token & userInfo payloads to represent such new mappings.

Known Limitations for mvp:

l1) Does not take into account any of the keycloak 'authorication services' / policies features. Strictly rely on simple RBAC concepts around users mapping with: orgs, sub-orgs (teams), groups and roles (I suppose this is enough for 'most' applications...at the very least, 80/20, if not much more).

0 replies

jopdorp · 2023-07-18T08:07:16Z

jopdorp
Jul 18, 2023

Looks like most of this is already implemented here: https://github.com/p2-inc/keycloak-orgs

0 replies

paultempleman · 2023-08-28T08:49:28Z

paultempleman
Aug 28, 2023

@stianst another angle to this would be how this could be used to created underlying digital trust of organisations within and across realms by implementing this to aligned with standards such as OpenID Connect Federation 1.0

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Advanced groups #19055

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 6 comments

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Advanced groups #19055

Uh oh!

Uh oh!

stianst Mar 16, 2023 Maintainer

Group options

Organization Groups

Context Groups

Client context

User account selection

Clients and groups

Roles

Replies: 6 comments

Uh oh!

jbman Mar 20, 2023

Uh oh!

LMonert Mar 20, 2023

Uh oh!

antikalk May 13, 2023

Uh oh!

Uh oh!

Frank-D Jun 7, 2023

EXISTING / KC OOTB:

NEW / KC EXTENSION:

Results of those extension points, offering some great [SaaS] multi-tenants abilities:

Known Limitations for mvp:

Uh oh!

jopdorp Jul 18, 2023

Uh oh!

paultempleman Aug 28, 2023

stianst
Mar 16, 2023
Maintainer

jbman
Mar 20, 2023

LMonert
Mar 20, 2023

antikalk
May 13, 2023

Frank-D
Jun 7, 2023

jopdorp
Jul 18, 2023

paultempleman
Aug 28, 2023