Ability to create users as a fine grain admin of a group

1,679 views
Skip to first unread message

Clement Cureau

unread,
May 11, 2020, 10:51:48 AM5/11/20
to Keycloak Dev
Hi there,

We use fine grain permissions on groups to allow a subset of users to manage their own "scope" of groups and users. We found out that the current implementation of the "manage" & "manage_membership" group scope permissions actually only allows user update, and not the creation part, see https://issues.redhat.com/browse/KEYCLOAK-11621. To fill that blank, I did some coding and posted PRs : 
We need that feature in our workflows and are using those unmerged commits in our setup. We'd love to see them merged, so we'd like to get feedback... 
  1. Do you guys think this should be accomplished in a different way?
  2. Can we consider our use case "mainstream" enough and count it in the features list of the refreshed UI being written?
Clement.
create-user-w-groups_04.PNG

Stian Thorgersen

unread,
May 12, 2020, 10:19:14 AM5/12/20
to Clement Cureau, Keycloak Dev
I wonder if strictly speaking what's missing is the permission to create users. Rather than say an admin can create a user in a group if he has manage-members and manage-membership what you probably want is the ability to allow an admin to create users, but then limit what the admin can set on the user.

My thinking here is that allowing an admin to create a user in a group is effectively more powerful than allowing an admin to create a user in no groups. 

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/5228cd05-9db1-4d6d-b0a1-2a14a7975ed3%40googlegroups.com.

Pedro Igor Craveiro e Silva

unread,
May 12, 2020, 11:27:35 AM5/12/20
to st...@redhat.com, Clement Cureau, Keycloak Dev
On Tue, May 12, 2020 at 11:19 AM Stian Thorgersen <stho...@redhat.com> wrote:
I wonder if strictly speaking what's missing is the permission to create users. Rather than say an admin can create a user in a group if he has manage-members and manage-membership what you probably want is the ability to allow an admin to create users, but then limit what the admin can set on the user.

My thinking here is that allowing an admin to create a user in a group is effectively more powerful than allowing an admin to create a user in no groups. 

+1
 

On Mon, 11 May 2020 at 16:52, Clement Cureau <clement.cure...@gmail.com> wrote:
Hi there,

We use fine grain permissions on groups to allow a subset of users to manage their own "scope" of groups and users. We found out that the current implementation of the "manage" & "manage_membership" group scope permissions actually only allows user update, and not the creation part, see https://issues.redhat.com/browse/KEYCLOAK-11621. To fill that blank, I did some coding and posted PRs : 
We need that feature in our workflows and are using those unmerged commits in our setup. We'd love to see them merged, so we'd like to get feedback... 
  1. Do you guys think this should be accomplished in a different way?
  2. Can we consider our use case "mainstream" enough and count it in the features list of the refreshed UI being written?
Clement.

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/5228cd05-9db1-4d6d-b0a1-2a14a7975ed3%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.

Pedro Igor Craveiro e Silva

unread,
May 12, 2020, 11:43:03 AM5/12/20
to Clement Cureau, Keycloak Dev
On Mon, May 11, 2020 at 11:51 AM Clement Cureau <clement.cure...@gmail.com> wrote:
Hi there,

We use fine grain permissions on groups to allow a subset of users to manage their own "scope" of groups and users. We found out that the current implementation of the "manage" & "manage_membership" group scope permissions actually only allows user update, and not the creation part, see https://issues.redhat.com/browse/KEYCLOAK-11621. To fill that blank, I did some coding and posted PRs : 
I've looked at this one again and it looks OK to me. Missing tests though.
It makes sense to me. I'm just not 100% sure if we should always show the new component but only in case the user lacks manage_users role. The reason is that if the user has full access he can always create the user and use the "Groups" tabs.
It makes sense too.
 
We need that feature in our workflows and are using those unmerged commits in our setup. We'd love to see them merged, so we'd like to get feedback... 
  1. Do you guys think this should be accomplished in a different way?
  2. Can we consider our use case "mainstream" enough and count it in the features list of the refreshed UI being written?
I think what you did is OK and +1 to have it.

For being "mainstream" enough, it would be nice if others could vote for these changes. 

Stian Thorgersen

unread,
May 13, 2020, 2:30:41 AM5/13/20
to Pedro Igor Craveiro e Silva, Clement Cureau, Keycloak Dev
My point here is that allowing someone to create users should be a separate permission. Creating a user within a group gives at least the same amount of power as creating a user without a group.

Which is why I think we should add a create users permission instead. Then an admin can only add groups or roles that the admin is permitted to, which is already the case.

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/CA%2B3s2iRHfWXj1ZbYYxKoU9Ap5dHeHZftP9VtPmjW3BPU7eqmHg%40mail.gmail.com.

Julien.Pliss...@ext.cdiscount.com

unread,
May 19, 2020, 5:40:39 AM5/19/20
to keyclo...@googlegroups.com
On Wed, 2020-05-13 at 08:30 +0200, Stian Thorgersen wrote:
> My point here is that allowing someone to create users should be a
> separate permission. Creating a user within a group gives at least
> the same amount of power as creating a user without a group.
>
> Which is why I think we should add a create users permission instead.

Sounds sensible, however for our use case we need a way to give to "group managers" permissions to create new users only if the newly created users are members of any of the groups they manage (they must not be able to create users that are not members of any group or members of groups they do not manage).

There is probably a case for a generic create users permission, but in KEYCLOAK-11621 Clement suggested a new group permission specifically for our use case that would be named create-user-in-group.

Also at some point we may want this "create user" operation to become an "add user to group" operation where if an existing user is found with a match that is close enough (exact e-mail, exact or close match on first and last name) it is added to the group with an API response that looks like the user was created, rather than rejecting the request because the e-mail is already used; if no user with the same e-mail is found then the user is created and added to the group.

We do not want our group managers to be able to list or search all users of a realm, excepted (maybe) for an exact match like the above.

Maybe it would be more relevant to implement that create or update feature as a POST on /{realm}/groups/{id}/members.


--
Julien Plissonneau Duquène

Stian Thorgersen

unread,
May 25, 2020, 2:45:10 AM5/25/20
to Julien.Pliss...@ext.cdiscount.com, Keycloak Dev
Adding an explicit create-user-in-group seems like the way to go. The implicit approach taken in the PR we have open seems like you won't have the option to differentiate if someone can just add members to the group, or if they can also create new users.

For the add user to group, but pretend to create the user, that's not an idea I like very much. This can be handled on the calling side instead by simply rejecting to the 409 by adding the group to the existing user without any need to search or list users.

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/44e19e831aa777368bd7325a853eeba8dbaf2d40.camel%40ext.cdiscount.com.

Schuster Sebastian (IOC/PDL22)

unread,
Jun 11, 2020, 11:56:33 AM6/11/20
to st...@redhat.com, Julien.Pliss...@ext.cdiscount.com, Keycloak Dev

We also have the use case that admin should only be able to create users in specific groups (countries they are responsible for in our case).

 

Mit freundlichen Grüßen / Best regards

Dr.-Ing. Sebastian Schuster

Project Delivery Berlin 22 (IOC/PDL22)
Bosch.IO GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch.io
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 726112-100 | Sebastian...@bosch.io

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling

Reply all
Reply to author
Forward
0 new messages