Replies: 19 comments 52 replies
-
This sounds much closer to what I was expecting from fine-grained permissions, thank you very much for all the effort. Are you also planing to add dynamic filters for applicable users? For example, it would be helpful to grant administrators user management privileges (e.g., reset credentials) for users that have a particular attribute set, or who are part of a specific group. This would be different from organizations, as all users involved are still part of the same organization (and have the same email domain), but would apply when administration still needs to be more granular (e.g., per-department). |
Beta Was this translation helpful? Give feedback.
-
This change looks very promising, thank you for your effort! Selecting users for permissions:
User Permission Assignments: Permission metadata: Permission definition vs. activation: |
Beta Was this translation helpful? Give feedback.
-
how to handle Fine Grained Permissions for user attribute? |
Beta Was this translation helpful? Give feedback.
-
One part I'm sorely missing (both in the new Fine-Grained Admin Permissions and the old RBAC) is a way to prevent admins from modifying users' credentials. Unless I missed something there is simply no way to do that. When an admin has access to "manage" a user, they can remove or change the user's credentials. I'd like to see a separation between managing user attributes and user credentials. If this is implemented, the ability to trigger a "credentials reset" email should IMO either be a separate permission, or could fall under "managing attributes" because it directly involves the user. |
Beta Was this translation helpful? Give feedback.
-
As of today, the nightly build of the docs contains the documentation for the V2 feature of the fine grained admin permissions: (I also updated the description at the top) |
Beta Was this translation helpful? Give feedback.
-
One feature that I really look forward to is to have a moderator role to a specific resource. IOW, something like:
Also, when creating a subgroup, it would be nice that the same roles are inherited by the sub group. Is this possible at all with V2? |
Beta Was this translation helpful? Give feedback.
-
At first, thanks for all the hard work on this @vramik ! I wanted to ask if it is possible to limit permissions for a Service Account to modify (and delete) the resources it had previously created. We would need this functionality for the v2 Admin REST APIs where a Terraform/OpenTofu Service Account would be managing Clients. The same rule applies to the Operator as well - it should only be able to modify the resources (Clients but in the future other aspects of the Realm or maybe even Users) it owns. Tagging @vmuzikar as he might also be interested in this. |
Beta Was this translation helpful? Give feedback.
-
Hey @slaskawi, nice yo see you around ! I can think about two possible options to achieve what you want:
Using FGAP v2 it should be possible to create a permission that grants access to a service account, using a user policy, to a set of one or more clients. However, this will not give you the best experience because you will be forced to update the permission every time you add a new client using your SA. And for that, you'll need to use a super admin that has access to manage permissions in a realm. However, the second option, using the concept of "owners", would perhaps give the best experience because every time a client (or any other realm resource) is created by an SA the access to that client will automatically be granted to the "creator" or "owner". We need to discuss this problem more and decide how we want to solve it. However, for me, it is a valid use case and useful for automation scenarios. |
Beta Was this translation helpful? Give feedback.
-
Thanks for all the hard work on this! I am encounting a problem that a realm administrator cannot see any client role in the 26.2 release. I grant When I login as I also tried creating a role type permission, but still it cannot see any client role. Though this time it can see realm roles. Also, I tried adding other role to user Am I missing something or is it a bug? |
Beta Was this translation helpful? Give feedback.
-
Thank you, really helpful feature and comprehensive! I use user groups to represent relations between doctors and patients. As example we have the following groups:
I want to grant
As much as I understood, I need to create one policy for each group to have the right access control. Or is there a simpler way to represent this? |
Beta Was this translation helpful? Give feedback.
-
Thank you for the update in 26.2.0 - it makes managing fine-grained permissions much easier. Unfortunately, it still falls short of our goal: true group-based delegation. Could you let us know whether these limitations are scheduled to be addressed soon? Observed behavior (Keycloak 26.2.0)
More details were provided withing the existing issue in the comment #22976 (comment) |
Beta Was this translation helpful? Give feedback.
-
I would like to ask whether it is (or will be) possible to delegate group management permissions in a more fine-grained way: The idea is to allow a delegated administrator to manage not only the current sub-groups but also to create new sub-groups within a specific parent group without requiring additional permission updates each time. This would be extremely useful for larger organizations where teams manage their own spaces but should stay scoped within their designated hierarchy. Is such functionality available today, or planned? If not, would it make sense to consider this as a feature request? |
Beta Was this translation helpful? Give feedback.
-
I'm looking for a way to allow group managers (i.e. with "manage-members" of a group) create users; but only if the user is within the group. Such a feature was suggested back in https://groups.google.com/g/keycloak-dev/c/mOxO_ET4g2w Is this possible today? or is it coming soon? |
Beta Was this translation helpful? Give feedback.
-
These fine grained admin permissions look really promising, it is very useful to allow and deny resources more specifically. One thing we were hoping to do is to deny a It seems the I could imagine a scenario where the Should this feature also consider such a use-case? Or is this perhaps already planned? Regardless, thanks everyone for all the work into this so far! |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
I would like to somehow designate a User (or Users) as administrators of an Organization. While I know this is a planned feature, I wonder if FGAP gives me the ability to do this in advance of it being formally supported. What would that look like? Can I do it with just FGAP or would I need to write some kind of custom Provider too? |
Beta Was this translation helpful? Give feedback.
-
Hi @vramik, Thank you for starting the discussion and providing the info for how to use the fine grained permissions! Goal:Having GroupA admin should be able to manage only users for this specific group, GroupB admin should only be able to manage users for GroupB group. Giving:The following setup:
Expected:AdminA should be able to add UserA1 to group GroupA/Dummy Actual:AdminA is not able to add UserA1 to group GroupA/Dummy Suggested workaround:Create a new user based permission as the following: Which makes thigs complicated, as i will need always to create two different permissions set for each group. it's also confusing because in the documentation the groups scopes |
Beta Was this translation helpful? Give feedback.
-
@aymns I am experimenting with something similar. If I understand correctly, the Permission applies to the object (the resource) whereas the Policy applies to the subject (the user trying to do something to the object). So perhaps you have too many groups listed in the Policy and your Policy should only list the Admin group, right? These things helped during my experimentation:
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
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 All,
Keycloak allows realm administrators to manage access to realm resources like users, clients, groups, and identity providers. One of the key features that support that is Fine-Grained Admin Permissions which we are working to make fully supported in Keycloak 26.2.
We would like to share what we are planning around this feature and its roadmap.
Update (as of April 4): The new docs are available.
A bit of background
Today, Keycloak allows delegating realm management operations to specific users in a realm using two different access control methods:
The RBAC method is based on a set of management roles that can be granted to a realm administrator. This method is fully supported and the existing roles provide a coarse-grained access control over the operations that can be performed in a realm. While this method is enough for some use cases, it does not allow enforcing access to individual resources but to all of them. It also lacks fine-grained access control over specific operations on realm resources where access is only enforced for CRUD operations.
On the other hand, the Policy-Based method relies on a set of user-defined policies to govern access to realm resources, being it all the resources of a certain type (e.g.: all the users) or a specific resource object (e.g.: individual user). It provides fine-grained access control to operations other than CRUD operations and the possibility of using different access control methods, including RBAC.
The Fine-grained Admin Permissions feature relies on a Policy-Based Access Control. Despite the high demand by the community to have it fully supported, it has been a technology preview feature for a long time due to its complexity and usability issues, preventing us from delivering new capabilities and improvements.
Introducing resource types
One of the key concepts being introduced is the idea of a resource type. The resource type represents the resources that administrators can manage access in a realm. For that, there will be the following resource types:
For each resource type, there would be a set of actions that can be performed on these resources. For example, for the
Users
resource type, the actions will includeview
,manage
,map-roles
,manage-membership
orimpersonate
.When managing access to realm resources, administrators will be following these steps:
As an example, creating permission to allow some realm administrator to manage members of a specific group in a realm would involve:
Groups
resource typeSales
group, the resource objectmanage-members
actionUser Policy
to check if theMyAdmin
is among a whitelist of usersPermissions may be applied to all resources of a type (e.g., all users) as well as permissions for individual resource objects (e.g., a specific user or set of users). This dual-level permission structure ensures flexibility to cover a wide range of use cases, from broad administrative roles to narrowly scoped permissions for specific tasks.
Managing permissions from a single place
Differently from how the feature works today, administrators will be able to list, search, create, delete, and evaluate permissions without having to navigate to different places in the administration console. Instead, the permissions will be managed from a single place through a new
Permission
section that will be introduced to the left-side menu of the administration console.In the
Permissions
tab, administrators are presented with a list of all the active permissions in a realm. From this tab, they can choose to create, update, delete, or search for permissions.In the
Policies
tab, administrators will be able to define conditions using different access control methods to decide whether or not a permission will be granted for an administrator trying to access a specific resource or perform an operation on it.In the
Evaluate
tab, administrators will be able to test their permissions and evaluate if they are enforcing access to resources as expected.Roadmap
Our goal is to make Fine-Grained Admin Permissions a fully supported feature in Keycloak 26.2. The roadmap includes the following key milestones:
Keycloak 26.2
Future Releases
Try it out
We encourage you to try out the upcoming changes to Fine-Grained Admin Permissions and share feedback.
In the latest nightly build, you can manage permissions only for the
Users
resource type.To get started, please follow these steps:
http:/localhost:8080
and authenticate using theadmin
username andadmin
passwordfgap
realmAs an example you may want to allow
myadmin
to see two users from a realm:myadmin
, create its credentials.query-users
role to the useralice
,bob
,charlie
Users
resource typeview
Specific users
in Apply permission to and select usersalice
andbob
allow-myadmin
, choose Policy typeUser
myadmin
, click Savehttp://localhost:8080/admin/master/console
and log in asmyadmin
user and click Usersalice
andbob
users foundYour feedback is crucial in shaping the final version of this feature, so please report any issues or suggestions through the Keycloak GitHub repository or community channels using the label
area/admin/fine-grained-permissions
.Conclusion
The Fine-Grained Admin Permissions feature is an important step toward providing more flexible and secure access control in Keycloak. By focusing on its manageability and usability, we aim to empower administrators with better tools to govern access to realm resources.
We look forward to hearing your feedback and working together to make this feature a success!
The Core IAM team.
Beta Was this translation helpful? Give feedback.
All reactions