Roles <-> Groups

[adrianschneider94]

Hi,

as far as I understand it, groups are just for managing users in Keycloak whereas roles are for managing permissions. (Group people in Groups, grant different groups different sets of roles).

But on the other hand you can have nested groups but not nested permissions in keycloak. Nested groups would be very handy to not map all keycloak groups into camunda but just the relevant ones.

As you see I don't have a settled opinion on this but I think it's worth discussing.

Best wishes,
Adrian Schneider

[VonDerBeck]

Hi Adrian,

this Keycloak Identity Provider leaves the management of fine grained permissions to Camunda itself - see authorizations view in the Admin application. Thus it has the same behavior as the well-known LDAP Identity Provider Plugin: users and groups come from outside, the detailed permissions are managed in the application (Camunda) itself.

For the time being, this design is intended.

Cheers
Gunnar

[VonDerBeck]

Hi Adrian,

you also mentioned nested groups. A filter for only mapping groups within a certain part of a hierarchy could be a feature to be implemented in future. I strongly agree with that.

Cheers
Gunnar

[gil0109]

@VonDerBeck I noticed this was removed from 1.3.0 milestone. Any idea when this will be added?

[VonDerBeck]

Hi @gil0109,

Unfortunately, I cannot give you a date at the moment. Since the plugin also works well with mass data the feature has a lower priority than other enhancements.

[adrianschneider94]

Hi,

after working with keycloak/OIDC for a longer time now, I think even more, that the roles approach would be the "right" one.
The users are sorted in keycloak groups which often originate from user federation.
These groups are meant to organize the users in a general manner, independent of the application.
Let‘s say, I have customers and employees in my realm. But I don‘t want to see all the customers in Camunda.
For this, there are roles in Keycloak/OIDC. And those roles can be created per client.
With those I can map the general groups to specific roles for camunda in Keycloak.
Like that, there are only those roles and users in camunda, which should be there.
Others (the customers in the example) not.

[VonDerBeck]

Hi @adrianschneider94,

Thanks! That is certainly true. However, it is difficult to transfer this to the general public. Some customers simply use the LDAP User Federation to import their users and groups into Keycloak. And that's it. If the administration effort and the amount of indirections and mappings increases, you will probably lose some plugin users. Therefore, the simplest possible straight forward approach is the one that covers the mass of use cases. Maybe it is worthwhile to do a survey among the users at some point.

[chaitanyabjoshi]

Hello Gunnar (@VonDerBeck),

First of all I would congratulate you as this Plug-In work brilliantly.

Now, in last few days I went through this discussion multiple times. We have a setup where we have multiple applications which depend upon Keycloak and some of these applications depend upon Camunda BPM. Users for all applications come from a federated organizational user database.
Process applications in Camunda BPM expect a certain user group structure. But these groups are irrelevant for other applications. As Keycloak allows role configuration per client, clients (including Camunda) can decide their own role structure while keeping the grouping structure the same.

Considering this scenario, I side with Adrian (@adrianschneider94) little bit more that Keycloak roles are probably more relevant unit for authorization in Camunda. But at the same time, there can be process applications which may want to take advantage of the groups. For example, I can design a process which can only be started by role for instance requestor but then some user tasks in this process can only be performed by group special-users which have requestor role. In this case, Camunda should be able to see both - the role requestor and group special-users. Too bad that Camunda doesn't have this fine grained user management.

It is irrelevant which of the two are used for Camunda authorizations. This is semantic difference which users should sort out.

My two cents...

Thanks and Regards
Chaitanya

[VonDerBeck]

Hi @chaitanyabjoshi, @adrianschneider94,
meanwhile I had a deeper look into the Keycloak REST API focussing on roles. I think an option e.g. "useKeycloakClientRolesAsCamundaGroups" would indeed be of great benefit.

In order to implement this without creating a big mess and performance issues within the Identity Provider we sadly have to wait for some Keycloak Features, e.g.

• KEYCLOAK-11494 Get users for role composite (KEYCLOAK-11494 Get users for role composite keycloak/keycloak#6326)
• KEYCLOAK-11733 Add endpoint to get parents of a role (KEYCLOAK-11733 Add endpoint to get parents of a role keycloak/keycloak#6383)
• ...

This is all about a more powerful query api focussing on (client) roles and their users, whether associated directly or indirectly. Both are currently on hold, but labeled for Keycloak 11.0.0.

Once these features are stable and included in Keycloak, I hope that the implementation of an optional "Keycloak role mode" for the Identity Provider might well be possible.

Thanks for your valuable input.
Gunnar

[Cracky5457]

For theses 2 MR if someone want to help to improve them he can, we have to change the wording for parents of a role and also there is a risk a requesting the whole database with KEYCLOAK-11494 ( we need to put some restriction/limitation. Also for reviewing and suggestion I can in few days apply changes on theses MR.

We are using them on production since 6 month without any issues.

[adrianschneider94]

I'm a bit confused, because I thought, that one cannot retrieve the effective client roles of a user. However I'm doing that in my project right now with the /admin/realms/{realm-name}/users/{id}/role-mappings/clients/{client-id}/composite endpoint. Am I missing something?

[VonDerBeck]

Retrieving the effetive roles of a single user - ok, done, but sadly this is only one aspect.

Have you thought about querying the other way around? Get all users who have an effective given client role? Including indirection over groups, composite roles etc.? The endpoint GET /{realm}/clients/{id}/roles/{role-name}/users is only the admin interface - it won't get the list of all effective users, but only the directly assigned users.

This may work in special scenarios when directly assigning users to client roles, but is far too little for a generally applicable approach.

[MarvinKern]

@VonDerBeck
I have currently a springboot camunda application that gets the users from Keycloak and this is working fine.
However I want to manage my users with another store, that is connected with Keycloak. But there are only roles and no groups.
When I followed your discussion correctly, it is currently not possible to map the roles to groups and put the users in the processEngine right?
Are there any updates on this topic?

Thank you for your help 👍

[Traore57]

hello dear community, I created new user for my process which I modeled with CAMUNDA. the problem is that I cannot connect with these created users. could someone help me please? I am new to modeling bpmn processes

[VonDerBeck]

Hi @Traore57,

Are you using the Keycloak Identity Provider Plugin? If yes, what exactly do you mean by "I cannot connect with these created users"?

[iceman91176]

Unfortunately @VonDerBeck is right - as long as we can’t get users from a role we have to use groups. And I can think of some cases where we need to know who is a member of a camunda group.

Roles (client, realm, composite) where user are either directly assigned that role or by a group can get pretty complex. And as @Cracky5457 mentioned there are some performance impacts.

On the other hand I totally agree with @adrianschneider94 , @chaitanyabjoshi - using roles makes it easy to isolate camunda-specific stuff in keycloak.
If u think about authenticating/authorizing machine-clients e.g. for external tasks , roles make even more sense.

Of course one could do some filtering - just read groups from keycloak that have a prefix for example. But that is just cosmetics .

What comes to my mind is this (don’t know if that works at all) Have a read-only user store that syncs with keycloak . But the groups(and group memberships) will be maintained in camunda. And as a bonus the groups will be synced TO keycloak as client-roles, and are available for other clients.

that might work in smaller deployments, but gets bad when users/groups grow.

I might go for the filter ;-) I am currently reworking my keycloak-sso extension and might provide a PR if you don’t mind.

It still means some extra work for service-account-clients but we can‘t have it all unfortunately.

[tmaroschik]

Reading through the org.camunda.bpm.extension.keycloak.KeycloakIdentityProviderSession class, I think it should be possible to use client roles (no realm roles) instead of groups when the client is given:

findUserByQueryCriteria => GET /{realm}/clients/{id}/roles/{role-name}/users
findGroupById => GET /{realm}/clients/{id}/roles/{role-name}
findGroupByQueryCriteria => GET /{realm}/users/{id}/role-mappings/clients/{client}

Find those here https://www.keycloak.org/docs-api/11.0/rest-api/index.html
I left out the obvious queries.

Am I missing something from the bigger picture? Probably some part about the effective users.

[adrianschneider94]

Hey @tmaroschik,

that‘s what @VonDerBeck pointed out here:
#3 (comment)

You just get the directly assigned users, not the effective users in this role. So any role mapping or sth. similar wouldn‘t have any effect.