Repository navigation
manage-users role is a way too broad #13604
Replies: 3 comments 5 replies
|
There should be a fine-grained permissions feature that you may want to try to take a look at. It appears to enable a lot of functionality after you enable it (it's not enabled by default, but you can manually enable it when creating a new client, or from the options page of an existing client). I have not had the time to look at it in detail, but it may be a good first step. Not sure if it has come out of technology preview yet, as mentioned here, but the new admin interface has the option to enable it. |
|
I tried but it serves different purpose. You define security matrix there, providing your own scopes, policies and permissions which are resembled then in permission tokens. This has nothing to do with client service account roles. It is completely different story aimed at scenarios, where u have different resource servers and u want to define your own actions and policies which provide more fine-grained control over those resources. I have completely different problem and not only me: https://stackoverflow.com/questions/73239414/keycloak-users-security In order to create realm user, i need client access token. This token has only predefined roles set from different builtin clients like realm management etc. I spent nearly 3 weeks trying to figure out how can i restrict manage-users role only to user creation action. I can not change it. So, if i want to create a user through Keycloak REST API, i need to claim client token for POST method which has "manage-users" role in it, thus opening a big security breach because this role allows to read all realm users as well etc. Neither query-users nor view-users roles do not fit for that. Like i said, i simply do not understand the reason behind that decision... |
|
OK, it seems like the fine-grained options were not what I was hoping. It's likely that the user management role can have blanket permissions since it was the most common use-case. Overall, such operations are normally done from inside Keycloak itself, so there may not have been a large enough need for fine-grained roles. If it amounts to anything, I would also like more fine-grained roles, and having generic roles like user management as collections of such roles - e.g., create users, change user password, reset user TOTPs, update user details, and manage users to be a group of all of the above. |
|
Yes, that would be perfect. |
|
I also want to have a specific role for creation of user. In current moment for creation of user I need to provide manage-users role. This role is very broad |
|
+1 |
|
I agree that manage-user is way too broad. I believe that my PR for support granular permission will solve the problem. |
|
Three years later this is still an issue! "manage-users" (or "manage" scope in fine grained 2) violates principle of least priviledges. There should be a separate create-, update-, read-, delete-users and maybe even some more to support e.g. create-users only permissions by api. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hi
Keycloak 19.0.1
Maybe I am missing something but can not find a way to restrict newly created client role to user creation only. Seems like manage-user do the job but from security perspective it is way too broad.
How can i reduce role scope only to standard CRUD actions for service account roles?
I use only Keycloak REST API + Spring Boot Adapter for authorization.
P.S.
Regards,
Andrey
All reactions