Fine Grained Admin Permissions #37133

vramik · 2025-02-06T12:34:56Z

vramik
Feb 6, 2025
Collaborator

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:

Users
Groups
Clients
Roles

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 include view, manage, map-roles, manage-membership or impersonate.

When managing access to realm resources, administrators will be following these steps:

Choose the resource type they want to create permission for
Choose if the permission should govern all the resources of a given type or a set of resource objects of that type
Choose a set of actions that will be protected by the permission
Choose or create the policies (conditions), that will be executed to decide whether or not the access should be granted

As an example, creating permission to allow some realm administrator to manage members of a specific group in a realm would involve:

Choose the Groups resource type
Choose the Sales group, the resource object
Choose the manage-members action
Create or choose a User Policy to check if the MyAdmin is among a whitelist of users

Permissions 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

Introduce the new permissions management section in the admin console.
Improve UI/UX for managing and evaluating permissions.
Review policy enforcement points in the Admin API to align with the new authorization model
Benchmarks and performance improvements when evaluating permissions for realm resources

Future Releases

Expand supported resource types (e.g. Organizations) and actions.
Expand supported use cases based on the additional resource types and operations

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:

Run a server container as follows.

podman run -p 8080:8080 \
-e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
-e KC_BOOTSTRAP_ADMIN_PASSWORD=admin \ 
quay.io/keycloak/keycloak:nightly start-dev \ 
--features=admin-fine-grained-authz:v2

In your browser, navigate to http:/localhost:8080 and authenticate using the admin username and admin password
Create a new fgap realm
Navigate to the Realm settings section and enable Admin Permissions for the realm
Navigate to the Permissions section in the left menu of the admin console.
Experiment with defining permissions managing access.

As an example you may want to allow myadmin to see two users from a realm:

Create user myadmin, create its credentials.
Assign query-users role to the user
Create several realm users alice, bob, charlie
On page Permissions click on Create permission and choose Users resource type
Fill the name and choose Authorization scopes view
Click Specific users in Apply permission to and select users alice and bob
Click Create new policy and fill the name e.g. allow-myadmin, choose Policy type User
For Users field select myadmin, click Save
Click *Assign existing policies * and choose the created policy.
Click Save
Navigate to http://localhost:8080/admin/master/console and log in as myadmin user and click Users
Note that there are alice and bob users found

Your 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.

darius-m · 2025-02-06T17:23:13Z

darius-m
Feb 6, 2025

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).

1 reply

vramik Mar 11, 2025
Collaborator Author

Currently there is only possibility to manage users as such, more fine grained actions (like reset-credentials) are not present, we may add some in future.

Regarding granting access to users that have a particular attribute set, it is not possible in current version, unless you implement your own custom policy or you'd use js one.

Regarding a specific group .. this should be already possible by creating a group policy. So that you can allow/disallows some action to users which are members of specified group(s).

thomasdarimont · 2025-02-07T10:47:13Z

thomasdarimont
Feb 7, 2025
Collaborator

This change looks very promising, thank you for your effort!

Selecting users for permissions:
Regarding the ability to select a "set of users" I'd like to see support for:

Select all users that have a specific realm / client role
Select all users that are a direct or indirect member of a specific group
Select all users with a specific attribute
(Later) select all users from a specific organization
Select all users that have a link to a specific identity provider
Select all users that come from a specific user federation source (LDAP, AD)

User Permission Assignments:
In the context if PAM (Privileged Access Management) there is the need for generating list of users with their permissions.
It would be helpful if we could provide a way to list all users with their permission, or generate a list of users with a specifc (set) of permission.

Permission metadata:
It should be possible to see when a policy / permission was created and last modified.

Permission definition vs. activation:
Other IAM solutions allow admins to define permissions/policies and testing them out without affecting users. For this it is possible activly "activate/enable/publish/enforce" a permission.
As an admin I'd like to be able to define a permission with proper configuration with the permission being enforce for the users. I now want to test the permission with the evaluation feature. After that I want to explicitly enable the permission.

0 replies

AhmedAssaf · 2025-02-17T15:11:30Z

AhmedAssaf
Feb 17, 2025

how to handle Fine Grained Permissions for user attribute?

1 reply

vramik Mar 11, 2025
Collaborator Author

If you mean a scenario when you want to allow/disallow something based on fact what user attribute name/value is, then currently your only option would be to implement custom policy provider or use js policy.

If you are after allowing to manage user attributes, then currently it's not so fine grained and you have only option to manage "whole" user.

kodebach · 2025-03-11T13:48:38Z

kodebach
Mar 11, 2025

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.

1 reply

vramik Mar 11, 2025
Collaborator Author

You are correct, currently there is not such granularity which would allow managing specific actions for users. We may consider to make it more granular in future.

ahus1 · 2025-04-04T06:25:45Z

ahus1
Apr 4, 2025
Collaborator

As of today, the nightly build of the docs contains the documentation for the V2 feature of the fine grained admin permissions:
https://www.keycloak.org/docs/nightly/server_admin/#_fine_grained_permissions

(I also updated the description at the top)

1 reply

vramik Apr 4, 2025
Collaborator Author

Thanks @ahus1!

oculos · 2025-04-04T08:14:09Z

oculos
Apr 4, 2025

One feature that I really look forward to is to have a moderator role to a specific resource. IOW, something like:

an admin creates a group XYZ
he gives user test a role called moderator, which would entitle this user to view, add and delete users of group XYZ, as well as being able to give the same role to to another user

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?

7 replies

vramik Apr 10, 2025
Collaborator Author

I want to create a group A. I want to give permission to user A to manage that group, add users, remove, etc, but only to group A. I want him to be able to create subgroups, only under group A. And I don't want him to see other groups, just group A. Similarly, I want to create group B, with the same rules, now with user B being the admin.

yes, that is fine, for each group you need to create one permission to achieve that. The tricky part (as of today) is delegating the moderator-role-for-group-A to another user of group A. #38806 should help with that.

wschomburg Apr 11, 2025

That is also possible by creating a user-admin (or moderator) group under group A and assign the roles to the group instead directly to the moderator users. With that, the user-admin group members will get the permission to manage other groups and also the user-admin group to add more moderators. We are using this for years with the old FGAP.

oculos May 6, 2025

Hey @oculos, delegating administrative privileges over a group is possible. All you need to do is create specific group permission with manage-members, manage-membership, view-members and view scopes for the group and assign or create role policy allowing access to administrators with this role assigned.

Hi!
Just to clarify:

For every group I need this, I'd need to add these permissions? I cannot simply create a role that I can assign to a user on a group and then get this all assigned automatically?

vramik May 6, 2025
Collaborator Author

Unless you want to grant access to all groups for users who has assigned the role, then yes. There is no way Keycloak would know what role relates to what group.

oculos May 6, 2025

Unless you want to grant access to all groups for users who has assigned the role, then yes. There is no way Keycloak would know what role relates to what group.

Thanks. This makes my scenario not so scalable. It would be nice if we had a role type ("generic resource role"?) that were only enforced on a resource it was applied to.

slaskawi · 2025-04-04T11:57:24Z

slaskawi
Apr 4, 2025

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.

4 replies

wschomburg Apr 11, 2025

We have a similar requirement, not for a service account, but we want to allow our different developer teams to manage their clients. Therefore, we create a manage-client client role in every client and assign this client role to the responsible team. We use FGAP (and it works even better with FGAP v2) to allow the user with the client role to view and manage the dedicated client. This should also work with your service account.

slaskawi Apr 16, 2025

I'm not sure this idea holds when we allow these users to create Clients. Once they start doing it, a malicious actor might use a label belonging to a different user or team.

As I highlighted in my comment below (#37133 (reply in thread)), I think it is vital that the Client assignment happens within a Client Policy and there's no way to bypass it. Otherwise, it's very easy to riddle the system in my opinion.

wschomburg Apr 16, 2025

I missed that, the users aren't allowed to create the clients. The clients are created for them, but they can manage them later.

kgardner May 30, 2025

@slaskawi Could you elaborate a bit more on the risk presented by allowing users to create their own clients? We're still pretty naive in terms of our use and understanding of keycloak, but we're looking to implement a form of multi-tenancy at the ldap group membership level. The intention is to let users create and manage clients owned by ldap groups of which they're members.

pedroigor · 2025-04-07T10:53:43Z

pedroigor
Apr 7, 2025
Collaborator

Hey @slaskawi, nice yo see you around !

I can think about two possible options to achieve what you want:

FGAP v2
Introduce an owner concept to realm resource types

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.

1 reply

slaskawi Apr 7, 2025

Likewise Pedro! Great to hear from you!

The FGAP v2 option doesn't seem to be scalable. The list of applicable Clients might be dynamic and doing any specialized API calls to adjust seems like a cumbersome option.

The "owner" concept seems much more suitable. As a stop-gap solution, I implemented something very similar in UDS Platform where a newly created Client contains a created-by attribute. The value is set to the owner, which could be a Service Account name. Whenever a Client is modified or deleted, this attribute is checked and if there's a mismatch - an exception is thrown (here's the code, it's quite trivial).

If we could have a pre-defined "owner" or "created-by" attribute on every resource, we could probably write a very small add-on to the FGAP to evaluate it.

fMeow · 2025-04-12T15:22:49Z

fMeow
Apr 12, 2025

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 query-users and query-clients roles to a user say realmAdmin. And I create two permissions, one for user type resource and the other for clients. I grant view, map-roles of all users, and also grant Map-roles, View, Map-roles-client-scope, Map-roles-composite of all clients. I create one policy allowing user realmAdmin and set logic to Positive.

When I login as realmAdmin, it can see all users and all clients, and also existing roles of any user. But it cannot see any client role when I tried adding a new role to an existing user. It just show "No roles for this user", "There are no realm roles to assign". Then I tried allowing all permission for user resource and client resource including manage but still no luck.

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 realmAdmin, and with manage-users it can finally see all client roles, but not so with view-users. This is not what we want since manage-users allow realmAdmin to do anything on any users (like completely deleting users).

Am I missing something or is it a bug?

6 replies

vramik Apr 14, 2025
Collaborator Author

PR: #38916

fMeow Apr 24, 2025

Hi, @vramik. Thanks for your hard work.

I tried keycloak 26.2.1 today and it's did partially solve the problem, that it can finally show client roles when a role type permission allows access to all clients. However, when I tried restricting role access to specific clients, it show again that "No roles for this user", "There are no realm roles to assign". Since I can see the roles for selected client when access is enforced to all clients, I assume this is a bug?

Thanks in advance.

vramik Apr 24, 2025
Collaborator Author

Hey @fMeow, I was trying to reproduce it locally and so far I was not able to, would you please create new issue with steps you tried, so that we can triage it properly? That'd help a lot. Thank you.

fMeow Apr 24, 2025

Here is my steps:

grant query-users and query-clients roles to a user say realmAdmin
create a policy allowing user realmAdmin and set logic to Positive
create two permissions with the previously created policy
- user type resource: map-roles, view for any user
- client type resource: grant map-roles, view, map-roles-client-scope, map-roles-composite of a specific client, say FooClient, which has a client role let's say foo
login as realmAdmin
- I can see the FooClient in Clients, and its roles
- go to user management, and enter the management page of a user. Go to role mapping tab, and click assign role. It show no roles for this user. I assume it should show all roles related to client FooClient. I even tried creating a role type resource in permission and grant Map-role-composite, Map-role, Map-role-client-scope to all roles, and it does not help.

vramik Apr 24, 2025
Collaborator Author

#39170

jflueck · 2025-04-20T21:32:26Z

jflueck
Apr 20, 2025

Thank you, really helpful feature and comprehensive!
I am wondering whether there is a way to achieve per-user group-based access controls without creating individual permissions for each group? My use-case is the following:

I use user groups to represent relations between doctors and patients. As example we have the following groups:

-clinic-a
	- doctor-a-group
		- doctor-a
		- patient-1
		- patient-2
	- doctor-b-group
		- doctor-b
		- patient-3
		- patient-4
	- assistant-c-group
		- assistant-c
		- patient-1
		- patient-3
- clinic-b
	- …….

I want to grant doctor-a user-manage permissions for patient-1 and patient-2. For this I created a permission that enforces access to the specific group (doctor-a-group) and contains two policies of type:

Group: to only give users within the group access to members of the group
Role: to only give users with doctor role access to members of the group

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?

8 replies

vramik May 5, 2025
Collaborator Author

For group policy it'd be like this:

{
  "name":"group-policy-example",
  "description":"",
  "groupsClaim":"",
  "groups":[{
    "id":"{GROUP_UUID}",
    "extendChildren":false
  }],
"logic":"POSITIVE"
}

jflueck May 6, 2025

Thank you for the prompt response. I’m attempting to send the following JSON payload to Keycloak version 26.2.3, but I keep encountering a “Cannot parse the JSON” error. Do you have any suggestions on what might be causing this issue?

  config: {
    transitional: {
      silentJSONParsing: true,
      forcedJSONParsing: true,
      clarifyTimeoutError: false
    },
    adapter: [ 'xhr', 'http', 'fetch' ],
    transformRequest: [ [Function: transformRequest] ],
    transformResponse: [ [Function: transformResponse] ],
    timeout: 0,
    xsrfCookieName: 'XSRF-TOKEN',
    xsrfHeaderName: 'X-XSRF-TOKEN',
    maxContentLength: -1,
    maxBodyLength: -1,
    env: { FormData: [Function [FormData]], Blob: [class Blob] },
    validateStatus: [Function: validateStatus],
    headers: Object [AxiosHeaders] {
      Accept: 'application/json, text/plain, */*',
      'Content-Type': 'application/json',
      Authorization: 'Bearer ey............................',
      'User-Agent': 'axios/1.8.4',
      'Content-Length': '226',
      'Accept-Encoding': 'gzip, compress, deflate, br'
    },
    method: 'post',
    url: 'https://keycloak.domain.com/admin/realms/<realm>/clients/c58fd1dd-98f8-4204-a715-ae1516ac6f4c/authz/resource-server/policy',
    data: '{"name":"patient-policy-e577e95e-77d8-4f9e-ae1f-43b2106a1df0","description":"Grants access to users in group","groupsClaim":"","groups":[{"id":"6fbcea69-631f-48a1-b88c-c69d3f097c67","extendChildren":false}],"logic":"POSITIVE"}',
    allowAbsoluteUrls: true
  },

This is how I sent the request:

		const policyRequestBody = {
			"name":policyName,
			"description":"Grants access to users in group",
			"groupsClaim":"",
			"groups":[{
			  "id":userGroupId,
			  "extendChildren":false
			}],
		  "logic":"POSITIVE"
		  }
		
		// Make the API call to create the policy using axios
		const policyResponse = await axios.post(
			`${process.env.KEYCLOAK_URL}/admin/realms/${process.env.KEYCLOAK_REALM}/clients/${process.env.CLIENT_ID_NUMBER}/authz/resource-server/policy`,
			policyRequestBody,
			{
				headers: {
					'Content-Type': 'application/json',
					Authorization: `Bearer ${await getAccessToken()}`,
				},
			}
		);

vramik May 12, 2025
Collaborator Author

I think the url is not correct, it should be something like this.

${process.env.KEYCLOAK_URL}/admin/realms/${process.env.KEYCLOAK_REALM}/clients/${process.env.CLIENT_ID_NUMBER}/authz/resource-server/policy/group

jflueck May 12, 2025

With this, I get a success response saying the policy was created 🚀 but for some reason I do not see the policy within keycloak under Permissions --> Policies.

Can you link me to the corresponding snippet in the code where you found the correct route?
I would also try to check some things on my own for the permissions I need to create. I apologize for all the requests.

vramik May 13, 2025
Collaborator Author

No worries. TBH it's strange that you cannot see the policy even though you get 201.

The endpoint where the request lands is

keycloak/services/src/main/java/org/keycloak/authorization/admin/PolicyService.java

Line 123 in 32a8c12

public Response create(String payload) {

istrilyanyi · 2025-04-28T13:43:01Z

istrilyanyi
Apr 28, 2025

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)

Works as expected
- Manage the specified groups (including membership).
- Manage the specified clients (roles + basic settings).
- Manage users (group-membership management).
Still problematic
- The Role Mappings tab is missing for the groups.
- Cannot map client roles to a client’s dedicated scope (yet managers can grant full scope).
- Cannot map client roles to the client’s service-account roles (realm roles are shown, client roles are not).
- Cannot edit the client’s Advanced Settings tab.

More details were provided withing the existing issue in the comment #22976 (comment)

1 reply

vramik May 5, 2025
Collaborator Author

Hey @istrilyanyi,

Still problematic

The Role Mappings tab is missing for the groups.

That's correct. I've checked it and it seems you need to have manage-users role:

keycloak/js/apps/admin-ui/src/groups/GroupsSection.tsx

Line 72 in 617af85

const canManageRoles = hasAccess("manage-users");

As of today Admin console relies on RBAC to display/hide things. This requires some additional effort to change it. Hopefully in near-ish future.

Cannot map client roles to a client’s dedicated scope (yet managers can grant full scope).

The same here. Admin console displays the dedicated client scope either if you have view-clients role:

keycloak/js/apps/admin-ui/src/clients/scopes/ClientScopes.tsx

Lines 183 to 190 in 62169ca

    
           if (isViewer) { 
        
             rows.unshift({ 
        
               id: DEDICATED_ROW, 
        
               name: t("dedicatedScopeName", { clientName }), 
        
               type: AllClientScopes.none, 
        
               description: t("dedicatedScopeDescription"), 
        
             }); 
        
           }

keycloak/js/apps/admin-ui/src/clients/scopes/ClientScopes.tsx

Line 140 in 62169ca

const isViewer = hasAccess("view-clients") || fineGrainedAccess;

or if you can manage the client:

keycloak/js/apps/admin-ui/src/clients/ClientDetails.tsx

Line 544 in 62169ca

fineGrainedAccess={client!.access?.manage}

but to see the dedicated scope detail you again need to have the role.

Cannot map client roles to the client’s service-account roles (realm roles are shown, client roles are not).
Cannot edit the client’s Advanced Settings tab.

I assume it's the same here. Overall all those issues are about how admin console shows/hides things. If you can please feel free to create new issue (area/admin/ui) for each of the problematic item, so it can be triaged and prioritized appropriately. Thanks a lot.

sventorben · 2025-04-28T21:05:57Z

sventorben
Apr 28, 2025

I would like to ask whether it is (or will be) possible to delegate group management permissions in a more fine-grained way:
Specifically, can we assign an admin permission to manage a parent group and automatically include all existing and newly created sub-groups under that parent?

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?

3 replies

vramik Apr 29, 2025
Collaborator Author

Hey @sventorben, It should be possible today with V2.

sventorben Apr 29, 2025

What would a policy look like for this? I could not get this working.

vramik Apr 30, 2025
Collaborator Author

I've tested it locally and it seems there is a bug. Thanks for bringing that up. I've created #39348

james-callahan · 2025-05-08T02:34:52Z

james-callahan
May 8, 2025

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?

3 replies

vramik May 9, 2025
Collaborator Author

It should be possible by setting up group permission allowing manage-members, view-members, manage-membership and view for the group with group policy allowing access to group members of the group.

Each member of that group will be allowed to create new members for that group. If you'd need to prevent that you'd need to add another policy (e.g. role policy allowing access only if they has the role assigned) to the permission.

greggulrajaniamici May 14, 2025

Hi all,

I'm trying to implement something similar , but I’m running into unexpected behaviour—most likely due to a misunderstanding on my part. Here’s the setup:

🔹 Group Hierarchy:

GroupA
└── Child

Users:

User toplevel
- Member of GroupA
- Has realm roles: query-groups, query-users
User b
- Member of Child
- Has realm roles: query-groups, query-users
User c
- Member of Child
- No realm roles

Permissions Setup:

GroupA-Permission
- Includes only GroupA
- Uses a GroupA-Policy scoped to GroupA only (does not include children)
- Defines all scopes (e.g., view, manage-members)
Child-Permission
- Includes only Child
- Uses a Child-Policy scoped to Child and GroupA (does not include parents)
- Also defines all scopes

Observed Behavior:

When I log in as user toplevel, I can see and modify all users (expected).
When I log in as user b, I can see users b and c, but cannot modify them — I get a "permission denied" error.

My Expectation:

Given that user b is:

A member of the Child group,
Granted query-users, query-groups roles, and
Scoped in a policy/permission that includes manage-members,

I expected user b to be able to modify users b and c (since they're in the same group), but this is not happening.

Note:

If I modify GroupA-Policy to include children then user b is able to modify user b and c but then also has permissions to GroupA

🤔 Question:

Is there something I'm missing in how scopes like manage-members or group policies are evaluated in the admin console?
Do I need to structure the permissions differently to allow user b to manage users in the Child group?

Thanks in advance for any guidance!

vramik May 29, 2025
Collaborator Author

Hey @greggulrajaniamici, I was just testing the described setup and as userB I was able to modify both userB and userC.

knarfi · 2025-05-27T11:17:26Z

knarfi
May 27, 2025

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 view of the user resource everywhere. So not only denying listing all users or viewing a specific user in the "users tab", but also in views like listing client sessions or listing users with a certain role.

It seems the user resource does not apply to such listings, as access is still granted. When clicking a user your are not allowed to view its details. But, you now do know that a user with such a username exists AND has access to a certain client. Information we want to hide for a admin user that only needs access to the clients technical information like the access token settings, for example.

I could imagine a scenario where the view-client realm-role is assigned, and a view of the user resource is denied via permissions. However, realm-roles overrule permissions and thus it would be ignored.

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!

2 replies

vramik May 29, 2025
Collaborator Author

Thank you for bringing that up, I have created an enhancement issue for it: #40058

knarfi Jun 16, 2025

Thank you @vramik, greatly appreciated!

bzolivereckle · 2025-06-05T15:10:40Z

bzolivereckle
Jun 5, 2025

I like the feature very much, but somehow i struggle to achieve what i want.

The Idea is to enable Group Owners to manage the members of their group (and only that particular group) by themselfes.

so i created a user policy

and i created a permission

and i evaluated the permission

Looks very nice so far. Than i logged into the admin console with the user from the policy

so i tried to add some realm roles

Now i see the menu items USER and GROUPS but still error

Next

now i see all groups (not as espected but well ...)

The WEBSHOP_USER Group has also an "Add Member" button (the other groups not, so thats okay for me)
When i try to add any user to the group i get

No i played around with the stuff for two days, checked the doku but well .. i have no clue what to change to make it work.

Regards
Oli

5 replies

vramik Jun 5, 2025
Collaborator Author

Hey @bzolivereckle, thanks a lot for trying the feature out.

I assume the admin.webshop-user.policy has the admin you're then using to log in to admin console, correct?

Could you just double check if the admin.webshop-user.permission does have view-members scope?

Related to roles you need: you should be assigning the query-groups and query-users, not other like view-users. Admin permissions takes precedence over admin permissions. More details in this section of docs: https://www.keycloak.org/docs/latest/server_admin/index.html#_realm_access_control

Sharing the steps I did to make this work:

policy:
permission
myadmin role assignement
when I log in as myadmin, I see the group:
when I go to Users -> Add user and click Join Groups button where I select the /WEBSHOP-USER I can create the user as member of the group

NOTE: Add member button in Group Members tab allows you to add existing users as members of the group, but you need to be able to both view the user(s) and manage-group-membership of that user(s).

bzolivereckle Jun 5, 2025

Hey @vramik
thanks for your reply.

I added everything to the permission

the Exception thrown is

2025-06-05 19:47:26,352 DEBUG [org.keycloak.services.error.KeycloakErrorHandler] (executor-thread-1747) Error response Forbidden: jakarta.ws.rs.ForbiddenException: HTTP 403 Forbidden
	at org.keycloak.services.resources.admin.permissions.UserPermissions.requireManageGroupMembership(UserPermissions.java:486)
	at org.keycloak.services.resources.admin.UserResource.removeMembership(UserResource.java:1151)
	at org.keycloak.services.resources.admin.UserResource$quarkusrestinvoker$removeMembership_ac2581f87947e367eb2e5ea6ddc445b5b9eb27e2.invoke(Unknown Source)
	at org.jboss.resteasy.reactive.server.handlers.InvocationHandler.handle(InvocationHandler.java:29)
	at io.quarkus.resteasy.reactive.server.runtime.QuarkusResteasyReactiveRequestContext.invokeHandler(QuarkusResteasyReactiveRequestContext.java:141)
	at org.jboss.resteasy.reactive.common.core.AbstractResteasyReactiveContext.run(AbstractResteasyReactiveContext.java:147)
	at io.quarkus.vertx.core.runtime.VertxCoreRecorder$15.runWith(VertxCoreRecorder.java:638)
	at org.jboss.threads.EnhancedQueueExecutor$Task.doRunWith(EnhancedQueueExecutor.java:2675)
	at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2654)
	at org.jboss.threads.EnhancedQueueExecutor.runThreadBody(EnhancedQueueExecutor.java:1627)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1594)
	at org.jboss.threads.DelegatingRunnable.run(DelegatingRunnable.java:11)
	at org.jboss.threads.ThreadLocalResettingRunnable.run(ThreadLocalResettingRunnable.java:11)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:1583)

But the evaluation is fine

I am using 26.2.5 (newest Version)

And it still does not work ..

Edit:

For the Users i only see the users that are assigned to the group not all of them.
If i create a new user and add it to the group that works fine.
But if i want to add an already existing one, that fails

vramik Jun 6, 2025
Collaborator Author

Hey @bzolivereckle,

For the Users i only see the users that are assigned to the group not all of them.
If i create a new user and add it to the group that works fine.
But if i want to add an already existing one, that fails

That is expected, the stacktrace and your description indicate that you do not have permission to manage-group-membership of the user. To be able to add existing users to some group you need to also setup User permission to allow view (to be able to see the user) and manage-group-membership (to be able to assign or unassigned the user to any group).

There is the related section of the docs: https://www.keycloak.org/docs/latest/server_admin/index.html#understanding-the-scopes-of-access

bzolivereckle Jun 6, 2025

Hey @vramik yes adding an user permission and assign the manage-group-membership there helped. Thank you very much.

sambalmueslie Jun 7, 2025

I put everything together i a small how to https://medium.com/@iee1394/example-how-to-configure-keycloak-fine-grained-admin-permissions-33425f28e9a5

bickelj · 2025-06-09T20:42:21Z

bickelj
Jun 9, 2025

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?

7 replies

vramik Jun 12, 2025
Collaborator Author

Thank you @bickelj.

"this is a planned feature"

Definitely, not yet clear about the roadmap for it.

bickelj Jun 17, 2025

@vramik While I have no concrete plan for this, is there a way to sponsor a feature/capability in the roadmap to hasten it?

bickelj Jul 3, 2025

@vramik Here's what I did:

Created users
Created two groups, test-group and test-group-admin
Created a permission to view, view members, manage on the test-group using a policy of checking whether a user is in the test-group-admin group.
Verified that the member of one user in test-group-admin was able to list test-group via curl .../admin/realms/the-realm/groups/[group-uuid]/members using a token from the-realm (rather than master realm token).
Found the call in Firefox dev tools that did the PUT /admin... from (3).
Made a call (using a master realm admin token) using cURL substituting the Organization X UUID in place of the Group test-users UUID to replace that permission. This call succeeded with 201 Created.
Tried to list the organization members like (4) above as the user, because (6) essentially said "members of the test-group-admin should be able to view organization X members". Got a 403 Forbidden 😞.
Looked in the Admin UI and the modified permission now shows up as applying to All groups 🤔.
Tried a call to list members of the test-group (I should not have permission to do this) using a realm token for the user in test-group-admin, basically a repeat of (4). This should not have worked because I used the Organization X UUID to replace the rule from (3). But it actually succeeded 😱. So by substituting Organization X UUID I accidentally elevated the privileges of test-group-admin users to be able to do all those things in the permissions to all groups! This does not seem good to me, how about to you?

vramik Jul 4, 2025
Collaborator Author

@bickelj thank you a lot for trying ti out. Even though it does not workaround the issue with missing organization support.

I think we should specifically test the group type upon creation of group permission/policy and prevent ORG ones. Created #40921

vramik Jul 4, 2025
Collaborator Author

@vramik While I have no concrete plan for this, is there a way to sponsor a feature/capability in the roadmap to hasten it?

Thank you for the offer, at this point we need define the requirements for FGAP for Organizations. We haven't started yet due to other priorities, I'll let you know.

aymns · 2025-07-03T15:25:16Z

aymns
Jul 3, 2025

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:

Create the following group structure:

     GroupA 
         Users: [userA1, userA2]
         Child Groups:
              Admin
                  Users: [adminA]
              Dummy:
                  Users: []


     GroupB 
         Users: [userB1, userB2]
         Child Groups:
              Admin
                  Users: [adminB]

Create the following Group Policies:

    GroupA-Admin-Policy:
        Groups [GroupA/Admin]
        Logic: [Positive]

    GroupB-Admin-Policy:
        Groups [GroupB/Admin]
        Logic: [Positive]

Create permission

GroupA-Admin-Permissions:
     Authorization scopes: [manage-membership, view-members, manage, view, manage-members]
     Groups: [GroupA, GroupA/Admin]
     Policies: [GroupA-Admin-Policy]

GroupB-Admin-Permissions:
     Authorization scopes: [manage-membership, view-members, manage, view, manage-members]
     Groups: [GroupB, GroupB/Admin]
     Policies: [GroupB-Admin-Policy]

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 manage-membership states this scope will give permission to add/remove users from groups.

0 replies

bickelj · 2025-07-03T16:35:14Z

bickelj
Jul 3, 2025

@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:

Permissions are on objects.
Policies are on subjects.
Use a fresh token after changing a setting.
Double-check that view is one of the granted Authorization scopes.
Double-check the UUID of the resource used when accessing the admin REST API.

1 reply

aymns Jul 4, 2025

@bickelj thanks for your reply, you are totally right my policy should only permits Groups/Admins.

But still the issue persist. It seems like the policy has to be applied for two different resources (Groups: to allow the admins managing those groups, Users: to allow admins to add them to certain groups/sub-groups). Meaning, we have to create two resources permissions (Group & Users), only creating a Group permissions is not enough to allow admins managing membership (adding/deleting) users from those groups - at least that's what I'm experiencing. Then users permissions (selecting all users) as suggested by @sambalmueslie here https://medium.com/@iee1394/example-how-to-configure-keycloak-fine-grained-admin-permissions-33425f28e9a5 gives access to all realm users (which doesn't fit my case).

Thank you for all the support and great efforts.

ionelacc · 2025-07-08T13:09:33Z

ionelacc
Jul 8, 2025

Hello,

I'm trying to create two roles:

map_user_roles to view users and assign roles to users
manage_users just for creating and updating users

I've created two Role policies:

I also created two permissions:

When I log in with a user that has the role map_user_roles or manage_users, I can see the list of users:

But when I try to see a user's details, I get:

I tried various scenarios, but nothing worked. How can I set these scenarios?

Thank you

0 replies

Fine Grained Admin Permissions #37133

Uh oh!

Uh oh!

vramik Feb 6, 2025 Collaborator

A bit of background

Introducing resource types

Managing permissions from a single place

Roadmap

Keycloak 26.2

Future Releases

Try it out

Conclusion

Replies: 19 comments · 52 replies

Uh oh!

Uh oh!

Uh oh!

vramik Mar 11, 2025 Collaborator Author

Uh oh!

thomasdarimont Feb 7, 2025 Collaborator

Uh oh!

Uh oh!

vramik Mar 11, 2025 Collaborator Author

Uh oh!

Uh oh!

vramik Mar 11, 2025 Collaborator Author

Uh oh!

ahus1 Apr 4, 2025 Collaborator

Uh oh!

vramik Apr 4, 2025 Collaborator Author

Uh oh!

Uh oh!

vramik Apr 10, 2025 Collaborator Author

Uh oh!

Uh oh!

Uh oh!

vramik May 6, 2025 Collaborator Author

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

pedroigor Apr 7, 2025 Collaborator

Uh oh!

Uh oh!

Uh oh!

Uh oh!

vramik Apr 14, 2025 Collaborator Author

Uh oh!

Uh oh!

Uh oh!

vramik Apr 24, 2025 Collaborator Author

Uh oh!

Uh oh!

Uh oh!

vramik
Feb 6, 2025
Collaborator

Replies: 19 comments 52 replies

vramik Mar 11, 2025
Collaborator Author

thomasdarimont
Feb 7, 2025
Collaborator

vramik Mar 11, 2025
Collaborator Author

vramik Mar 11, 2025
Collaborator Author

ahus1
Apr 4, 2025
Collaborator

vramik Apr 4, 2025
Collaborator Author

vramik Apr 10, 2025
Collaborator Author

vramik May 6, 2025
Collaborator Author

pedroigor
Apr 7, 2025
Collaborator

vramik Apr 14, 2025
Collaborator Author

vramik Apr 24, 2025
Collaborator Author