mirror/keycloak
1
0
Fork 0
mirror of https://github.com/keycloak/keycloak.git synced 2026-01-05 22:39:52 -06:00
Code Issues Packages Projects Releases Wiki Activity

More information to docs

Browse Source 
Closes #38798

Signed-off-by: Pedro Igor <pigor.craveiro@gmail.com>
This commit is contained in:
Pedro Igor
2025-04-10 15:03:05 -03:00
committed by GitHub
parent e68e43cbc8
commit 288b6dae12
2 changed files with 188 additions and 149 deletions
Download Patch File Download Diff File Expand all files Collapse all files

335
docs/documentation/server_admin/topics/admin-console-permissions/fine-grain-v2.adoc
View File

@@ -1,38 +1,28 @@
[[_fine_grained_permissions]]
=== Fine grained admin permissions V2
=== Delegating realm administration using permissions
With fine-grained admin permissions, you can delegate realm management to other administrators, the realm administrators.
Different from the regular Role-Based Access Control Mechanism provided through the Global and Realm specific roles
(<<_master_realm_access_control, Master realm access control>>), this feature provides a more fine-grained control over
You can delegate realm management to other administrators, the realm administrators, using the fine-grained admin permissions
feature.
Different from the Role-Based Access Control (RBAC) Mechanism provided through the
<<_master_realm_access_control, Global and Realm specific roles>>, this feature provides a more fine-grained control over
how realm resources can be accessed and managed based on a well-defined set of operations that can be performed on them.
By relying on a Policy-Based Access Control, server administrators can define permissions to realm resources such as users,
groups, and clients, using different policy types, or access control methods, so that a realm administrator is limited to
access a subset of realm resources and their operations.
Here are some key points to understand about fine-grained admin permissions:
The feature provides an alternative to the aforementioned RBAC mechanism, but it does
not replace it. You are still able to grant administrative roles like `view-users` or `manage-clients` to delegate access
to realm administrators but doing so will skip the mechanisms provided by this feature.
* Fine grained admin permissions are only available within <<_per_realm_admin_permissions, dedicated admin consoles>> or
realm-specific admin APIs and administrators defined within those realms. You cannot define cross-realm fine grained permissions.
* Fine grained admin permissions are used to grant additional permissions. You cannot override the default behavior of the
built-in admin roles.
* Fine-grained admin permissions V2 do not support federated resources. This restriction is a known limitation under consideration
for future improvement.
[NOTE]
====
To maximize the effectiveness of fine-grained admin permissions while minimizing the impact of broad admin roles,
it is recommended to assign the *query-clients*, *query-groups*, and *query-users* roles (along with roles required
for realm management) to allow querying. All other administrative access could be managed through fine-grained permissions.
See <<_realm_access_control, Accessing a Realm Admin Console as a Realm Administrator>> for more information.
====
Enforcing access to realm resources only applies when managing resources through the administration console or the Admin API.
==== Understanding the Realm Resource Types
In a realm, you can manage different types of resources such as users, groups, clients, client scopes, roles, and so on.
As a realm administrator, you are constantly managing these resources to manage your identities and how they authenticate
and authorize to a realm and your applications.
As a realm administrator, you are constantly managing these resources when managing identities and how they authenticate
and are authorized to access a realm and applications.
This feature provides the necessary mechanisms to enforce access controls when managing realm resources, limited to:
@@ -41,35 +31,53 @@ This feature provides the necessary mechanisms to enforce access controls when m
* Clients
* Roles
It allows you to manage permissions for all resources of a given resource type, such as all users in a realm, or
You can manage permissions for all resources of a given resource type, such as all users in a realm, or
for a specific realm resource, such as a specific user or set of users in the realm.
Each realm resource supports a well-defined set of management operations, or actions, that can be performed on them,
such as view, manage, and resource-specific operations such as view-members if you take groups as an example.
==== Understanding the scopes of access
Each realm resource supports a well-defined set of management operations, or scopes, that can be performed on them,
such as `view`, `manage`, and resource-specific operations such as `view-members`, if you take groups as an example.
When managing permissions, you are selecting a set of one or more scopes from a resource type to allow realm administrators
to perform specific operations on a resource type. For instance, granting a `view` scope will give access to realm administrators
to list, search, and view a realm resource. On the other hand, the `manage` scope will allow administrators to perform updates
and deletes on them.
The scopes are completely independent of each other. If you give access to `manage` a realm resource, that does not mean the
`view` scope is granted automatically. No transitive dependency exists between scopes. Although this might impact the
overall user experience when managing permissions because you need to select individual scopes,
the benefit is that you can more easily identify the permissions that enforce access to a specific scope.
Certain scopes from a resource type have a relationship (not a transitive dependency) to scopes in another resource type.
This relationship is mainly true when you manage a resource type that represents a group of realm resources, such as realm groups
and their members.
===== Users Resource Type
The *Users* realm resource type represents the users in a realm. You can manage permissions for users based on the following
set of management operations:
set of scopes:
[cols="30%,70%"]
[cols="30%,50%,20%"]
|===
| *Operation* | *Description*
| *Scope* | *Description* | *Also granted by*
| *view* | Defines if a realm administrator can view users.
| *manage* | Defines if a realm administrator can manage users.
| *manage-group-membership* | Defines if a realm administrator can assign or anassign users into groups.
| *map-roles* | Defines if a realm administrator can assign or anassign roles to users.
| *impersonate* | Defines if a realm administrator can impersonate other users.
| *view* | Defines if a realm administrator can view users. This scope should be set whenever you want | `view-members`
to make users available from queries.
| *manage* | Defines if a realm administrator can manage users. | `manage-members`
| *manage-group-membership* | Defines if a realm administrator can assign or unassign users to/from groups. | None
| *map-roles* | Defines if a realm administrator can assign or unassign roles to/from users. | None
| *impersonate* | Defines if a realm administrator can impersonate other users. | `impersonate-members`
|===
The user resource type has a strong relationship with some of the permissions you can set to groups. Most of the time,
users are members of groups and granting access to `view-members` or `manage-members` of a group should also allow
a realm administrator to `view` and `manage` members of that group.
[NOTE]
====
- The *view* operation also considers group-related permissions, specifically *view-members* for viewing group members.
The evaluation takes permissions for specific resources (specific user permissions and specific group permissions) first.
See <<_resolving-conflicting-permissions, Resolving Conflicting Permissions>> for more information.
- The *manage* operation takes *manage-members* into account when managing group members.
- The *impersonate* operation takes *impersonate-members* into account when managing group members.
This feature does not support enforcing access to federated resource, however, this limitation is being considered
for future improvement.
====
===== Groups Resource Type
@@ -81,21 +89,21 @@ set of management operations:
|===
| *Operation* | *Description*
| *view* | Defines if a realm administrator can view groups.
| *view* | Defines if a realm administrator can view groups. This scope should be set whenever you want
to make groups available from queries.
| *manage* | Defines if a realm administrator can manage groups.
| *view-members* | Defines if a realm administrator can view group members.
This operation applies to any child group in the group hierarchy.
This can be prevented by explicitly denying permission for specific subgroups.
| *manage-members* | Defines if a realm administrator can manage group members.
This operation applies to any child group in the group hierarchy.
This can be prevented by explicitly denying permission for specific subgroups.
| *impersonate-members* | Defines if a realm administrator can impersonate group members.
This operation applies to any child group in the group hierarchy.
This can be prevented by explicitly denying permission for specific subgroups.
| *manage-membership* | Defines if a realm administrator can add or remove members from groups.
|===
[NOTE]
====
- The *view-members* and *manage-members* operations apply to the entire group hierarchy. In other words, if an administrator has
permission to manage members of a group, they can also manage members of all its subgroups. This can be prevented by
explicitly denying permission for specific subgroups.
====
===== Clients Resource Type
The *Clients* realm resource type represents the clients in a realm. You can manage permissions for clients based on the following
@@ -105,20 +113,17 @@ set of management operations:
|===
| *Operation* | *Description*
| *view* | Defines if a realm administrator can view clients.
| *view* | Defines if a realm administrator can view clients. This scope should be set whenever you want
to make clients available from queries.
| *manage* | Defines if a realm administrator can manage clients.
| *map-roles* | Defines if a realm administrator can assign any role defined by a client (or multiple clients) to a user.
| *map-roles-composite* | Defines if a realm administrator can assign any role defined by a client (or multiple clients) as a composite to
| *map-roles* | Defines if a realm administrator can assign any role defined by a client to a user.
| *map-roles-composite* | Defines if a realm administrator can assign any role defined by a client as a composite to
another role.
| *map-roles-client-scope* | Defines if a realm administrator can assign any role defined by a client (or multiple clients) to the scope of
another client.
| *map-roles-client-scope* | Define if a realm administrator can assign any role defined by a client to a client scope.
|===
[NOTE]
====
- The *map-roles* operation does not grant the ability to manage users or assign roles arbitrarily; the administrator must also
have user role mapping permissions.
====
The *map-roles* operation does not grant the ability to manage users or assign roles arbitrarily. The administrator must also
have user role mapping permissions on the user.
===== Roles Resource Type
@@ -130,16 +135,14 @@ The *Roles* realm resource type represents the roles in a realm. You can manage
| *map-role* | Defines if a realm administrator can assign a role (or multiple roles) to a user.
| *map-role-composite* | Defines if a realm administrator can assign a role (or multiple roles) as a composite to another role.
| *map-role-client-scope* | Defines if a realm administrator can apply a role (or multiple roles) to an another client’s scope.
| *map-role-client-scope* | Defines if a realm administrator can apply a role (or multiple roles) to a client scope.
|===
[NOTE]
====
* The *map-role* operation does not grant the ability to manage users or assign roles arbitrarily; the administrator must also have
user role mapping permissions.
* When mapping client roles, if an administrator has permission to *map-roles*, *map-roles-composite*, or *map-roles-client-scope* for
a client, permissions for specific roles within that client are not evaluated.
====
The *map-roles* operation does not grant the ability to manage users or assign roles arbitrarily. The administrator must also
have user role mapping permissions on the user.
If there is a client resource type permission for the *map-roles*, *map-roles-composite*, or *map-roles-client-scope* scopes,
it will take precedence over any role resource type permission if the role is a client role.
==== Enabling admin permissions to a realm
@@ -155,10 +158,15 @@ Once enabled, a *Permissions* section appears in the left-side menu of the admin
image:images/fine-grain-permissions-tab.png[Fine grain permissions tab]
From this section, you can manage the permissions for realm resources.
[[_managing-permissions]]
==== Managing Permissions
The *Permissions* tab provides an overview of all active permissions within a realm. From here, administrators can create,
update, delete, or search for permissions.
update, delete, or search for permissions. You can also pre-evaluate the permissions you have created to check
if they are enforcing access to realm resources as expected.
For more details, see link:#_managing-permissions[Evaluating Permissions].
To create a permission, click on the `Create permission` button and select the resource type you want to protect.
@@ -178,47 +186,39 @@ assigning only *manage* without *view* will prevent the user from being visible.
* *Enforce access to*: Defines if the permission should enforce access to all resources of the selected type or to specific resources in a realm.
* *Policies*: Defines a set of one or more policies that should be evaluated to grant or deny access to the selected resource(s).
==== Managing Policies
The *Policies* tab allows administrators to define conditions using different access control methods to determine whether
a permission should be granted to an administrator attempting to perform operations on a realm resource. When managing permissions,
you must associate at least a single policy to grant or deny access to a realm resource.
Policies are basically conditions that will evaluate to either a `GRANT` or a `DENY`. Their outcome will decide whether
a permission should be granted or denied. A permission is only granted if all its associated policies evaluate to a `GRANT`.
Otherwise, the permission is denied and a realm administrator will not be able to access the protected resource.
{project_name} provides a set of built-in policies that you can choose from:
image:images/select-policy-type.png[Selecting a policy type]
For more details about each policy type, take a look at link:{authorizationguide_link}#_policy_overview[Managing policies].
==== Evaluating Permissions
The *Evaluation* tab provides a testing environment where administrators can verify that permissions are correctly enforcing access
control as expected.
The administrator could see what permissions were involved in evaluation and what the outcome is by specifying a `username` of a user they
want to verify, *Resource type*, resource (usermane of a *User* in this case) and optionally an authorization scope.
image:images/fine-grain-evaluation.png[Fine grained permissions evaluation tab]
In the example above it is visible that the user `myadmin`, can *manage* user `user-1`. There is also information what permissions were involved
in the evaluation, what outcome it had and what scopes were granted or denied.
After creating the permission, it will automatically take effect when enforcing access to (all) resources and scopes you selected.
Keep that fact in mind when creating and updating permissions in production.
===== Defining permissions for viewing realm resources
When listing or searching for realm resources (such as clients, groups, or users) via the Admin Console or Admin API, {project_name}
evaluates permissions that contain the *view* scope for the specific resource. For this operation, only role, user, and group policy types are
considered, while other policy types are ignored due to partial evaluation performed at the database level. Because of this, only policies that
reference the resource directly—whether through user association, group membership, or role assignment—are found and permissions associated with
those are used to filter the resources.
This feature relies on a partial evaluation mechanism to partially evaluate the permissions that a realm administrator has
when listing and viewing realm resources. This mechanism will pre-fetch all the permissions set for view-related scopes where the realm administrator
is referenced either directly or indirectly.
The partial evaluation mechanism helps identify and load relevant permissions from the database by using the resource
identifiers that the realm administrator has permission to "view". These identifiers are then applied in the subsequent
database query to fetch the actual stream of resources. Partial evaluation is not supported for federated resources, which
is a limitation of the current implementation.
Permissions that grant access to `view` a realm resource of a certain type must use one of the following policies to
make them available from queries:
* `User`
* `Group`
* `Role`
By using any of the policies above, {project_name} can pre-calculate the set of resources that a realm administration can view
by looking for a direct (if using a user policy) or indirect (if using a role or group policy) reference to the realm administrator.
Therefore, the partial evaluation mechanism involves decorating queries with access controls that will run at the database level. This capability is mainly important to
properly allow paginating resources as well as avoid an additional overhead on the server-side when evaluating permissions for each
realm resource returned by queries.
Partial evaluation and filtering occurs only if the feature is enabled to a realm, and if the user is not granted
with view-related administrative roles like `view-users` or `view-clients`. For instance, it will not happen for regular server administrators granted
with the `admin` role.
When querying resources, the partial evaluation mechanism works as follows:
* Resolve all the permissions for a certain resource type that reference the realm administrator
* Pre-evaluate each permission to check if the realm administrator does or does not have access to the resources associated with the permission
* Decorate database queries based on the resources granted or denied
As a result, the result set of a query will hold only the realm resources where realm administrators have access to any of the view-related scopes.
===== Searching Permissions
@@ -229,10 +229,67 @@ The Admin Console provides several ways to search for permissions, supporting th
* Search for permissions of a specific resource type that apply to a particular resource (such as *Users* resource type for user `myadmin`).
* Search for permissions of a specific resource type with a given scope (such as *Users* resource type permissions with the *manage* scope).
* Search for permissions of a specific resource type that apply to a particular resource and have a specific scope (such as *Users* resource
type permissions with the *manage* scope for user `myadmin`).
type permissions with the *manage* scope for user `myadmin`).
.Fine grained permissions search
image:images/fine-grain-search.png[Fine grained permissions search]
These capabilities allow server administrators to perform queries on their universe of permissions and identify which ones
are enforcing access to a set of one or more realm resources and their scopes. Combined with the evaluation tool on the
*Evaluation* tab, they provide a key management tool for managing permissions in a realm. See <<_evaluating-permissions, Evaluating Permissions>>
for more details.
==== Managing Policies
The *Policies* tab allows administrators to define conditions using different access control methods to determine whether
a permission should be granted to an administrator attempting to perform operations on a realm resource. When managing permissions,
you must associate at least a single policy to grant or deny access to a realm resource.
Policies are basically conditions that will evaluate to either a `GRANT` or a `DENY`. Their outcome will decide whether
a permission should be granted or denied.
A permission is only granted if all its associated policies evaluate to a `GRANT`. Otherwise, the permission is denied
and a realm administrator will not be able to access the protected resource.
{project_name} provides a set of built-in policies that you can choose from:
image:images/select-policy-type.png[Selecting a policy type]
Once you have a well-defined and stable permission model for your realm, less need exists to create policies. You can instead reuse existing policies to create more permissions.
For more details about each policy type, see link:{authorizationguide_link}#_policy_overview[Managing policies].
[[_evaluating-permissions]]
==== Evaluating Permissions
The *Evaluation* tab provides a testing environment where administrators can verify that permissions are enforcing access
as expected. The administrator can see what permissions are involved when enforcing access to a particular resource and what the outcome is.
You need to provide a set of fields in order to run an evaluation:
* `User`, the realm administrator or the subject trying to access a resource
* `Resource Type`, the resource type you want to evaluate
* `Resource Selector`, depending on the selected `Resource Type` you will be prompted to select a specific realm resource like a user, group, or client.
* `Authorization scope`, the scope or the operation you want to evaluate. If not provided, the evaluation will happen for all the scopes of the selected resource type.
.Fine grained permissions evaluation tab
image:images/fine-grain-evaluation.png[Fine grained permissions evaluation tab]
By clicking the `Evaluate` button, the server will evaluate all the permissions associated with the selected resource and scopes
just like if the selected `User` were trying to access the resource when using the administration console or the Admin API.
For instance, in the example above you can see that the user `myadmin` can *manage* user `user-1` because a `Allow managing all realm users` permission
voted to a `PERMIT`, therefore granting access to the `manage` scope. However, all the other scopes were denied.
Combined with the searching capabilities from the *Permissions* tab, you can perform troubleshooting to identify any permission that
is not behaving as expected.
When evaluating permissions, the following rules apply:
* The outcome from resource-specific permissions have precedence over broader permissions that give access to all resources of a certain type
* If no permissions exist for a specific resource, access will be granted based on the permission that grants access to all resources of a certain type
* The outcome from different permissions that enforce access to a specific resource will only grant access if they all permit access to the resource
[[_resolving-conflicting-permissions]]
===== Resolving conflicting permissions
@@ -248,65 +305,45 @@ during evaluation. If no specific permission exists, the fallback is to the "all
allowing members of the `realm-admins` group to manage members of realm groups, but preventing them from managing members of the `realm-admins` group
themselves.
*View and Manage users and group members*
When evaluating *view* or *manage* permissions for users the group *view-members* and *manage-members* permissions are taken into an account.
The evaluation follows:
* Specific user/group permissions take precedence over broader all-resource permissions.
* If multiple permissions apply to a given user or group (such as multiple user-specific permissions, or a permission covering a set of
users/groups where the user is member of), all of them are evaluated, and all of them must grant access for the outcome to be GRANTED.
* If no user/group-specific permissions exist, the evaluation falls back to all-resource permissions ("all-users", "all-groups").
* When both all-users and all-groups permissions exist, both must grant access for the outcome to be GRANTED.
* If only one of them exists, the outcome is determined by that permission alone.
[[_realm_access_control]]
==== Accessing a Realm Admin Console as a Realm Administrator
==== Accessing a Realm administration console as a Realm Administrator
Realm administrators can access a dedicated realm-specific Admin Console, which allows them to manage resources within their assigned realm.
This is separate from the main Keycloak Admin Console, which is typically used by server administrators.
Realm administrators can access a dedicated realm-specific administration console that allows them to manage resources within their assigned realm.
This console is separate from the main {project_name} Admin Console, which is typically used by server administrators.
For more details on dedicated realm admin consoles and available roles, refer to: <<_per_realm_admin_permissions, Dedicated admin consoles>>.
For more details on dedicated realm administration consoles and available roles, refer to: <<_per_realm_admin_permissions, Dedicated admin consoles>>.
To access the Admin Console, a realm administrator must have at least one of the following roles assigned, depending on the resources they
To access the administration console, a realm administrator must have at least one of the following roles assigned, depending on the resources they
need to administer:
- *query-users* – Required to query realm users.
- *query-groups* – Required to query realm groups.
- *query-clients* – Required to query realm clients.
If an administrator is responsible for multiple resource types (such as both users and groups), they must have all corresponding "query-*"
roles assigned.
By granting any of these roles to a realm user, they will be able to access the administration console, but only for the
areas that correspond to roles granted. For instance, if you assign the `query-users` role, the realm administrator
will only have access to the `Users` section in the administration console. If an administrator is responsible for
multiple resource types (such as both users and groups), they must have all the corresponding "query-*" roles assigned.
These roles enable basic access to query resources but do not grant permission to view or modify them. To configure more fine-grained
administrative access, additional permissions must be granted using fine-grained admin permissions.
These roles enable basic access to query resources but do not grant permission to view or modify them. To grant or deny access
to realm resources you need to set up the permissions for any of the operations available from each resource type.
For more details, see link:#_managing-permissions[Managing Permissions].
===== Granting Administrative Roles to a Realm Administrator
A realm administrator’s access must be configured by someone with permission to assign administrative roles. At a minimum, the administrator
must have:
- The appropriate "query-*" roles, depending on the resource types they need to administer.
Beyond these foundational roles, *fine-grained admin permissions* can be used to define specific administrative capabilities. While fine-grained
permissions allow for more granular control over access, they cannot override the default behavior of built-in admin roles.
This means that if an respective admin role is assigned to a realm administrator, permission evaluation will be bypassed, and access will be
granted.
====== Roles and Permission relationship
===== Roles and Permission relationship
Fine grained permissions are used to grant additional permissions. You cannot override the default behavior of the built-in admin roles.
If a realm admin is assigned one or more admin roles, it prevents the permissions from being evaluated.
If a realm administrator is assigned one or more admin roles, it prevents the permissions from being evaluated. This means that
if a respective admin role is assigned to a realm administrator, permission evaluation will be bypassed, and access will be granted.
[cols="30%,70%"]
|===
| *Admin Role* | *Description*
| *query-users* | A realm administrator can see the *Users* section in Admin Console and can search for users in the realm.
| *query-users* | A realm administrator can see the *Users* section in administration console and can search for users in the realm.
It does not grant the ability to *view* users.
| *query-groups* | A realm administrator can see the *Groups* section in Admin Console and can search for groups in the realm.
| *query-groups* | A realm administrator can see the *Groups* section in administration console and can search for groups in the realm.
It does not grant the ability to *view* groups.
| *query-clients* | A realm administrator can see the *Clients* section in Admin Console and can search for clients in the realm.
| *query-clients* | A realm administrator can see the *Clients* section in administration console and can search for clients in the realm.
It does not grant the ability to *view* clients.
| *view-users* | A realm administrator can *view* all users and groups in the realm.
| *manage-users* | A realm administrator can *view*, *map-roles*, *manage-group-membership* and *manage* all users in the realm,
@@ -321,11 +358,11 @@ If a realm admin is assigned one or more admin roles, it prevents the permission
Consider a situation where an administrator wants to allow a group of administrators to manage all users in the realm except those that
belong to the administrators group. This example includes a `test` realm and a `test-admins` group.
===== Allow manage users by group of administrators
===== Allowing to manage users by group of administrators
Create user permission permission, allowing to view and manage all users in the realm for members of the `test-admins` group:
* Navigate to the *Permissions* tab in the Admin Console.
* Navigate to the *Permissions* tab in the administration console.
* Click *Create permission* and choose *Users* resource type.
* Fill in the name, such as `Disallow managing test-admins`.
* Choose *view* and *manage* authorization scopes, keep checked *All Users*.
@@ -334,7 +371,7 @@ Create user permission permission, allowing to view and manage all users in the
* Click *Add groups* button and select `test-admins` group, click *Save*.
* Click *Save* on *Create permission* page.
===== Allow manage users by group of admins but not group members
===== Allowing to manage users by group of admins but not group members
Let's exlude the members of the group itself, so that `test-admins` cannot manage other admins.
@@ -348,38 +385,38 @@ Let's exlude the members of the group itself, so that `test-admins` cannot manag
* Switch to *Negative Logic* for the policy, *Save* the policy
* *Save* the permission
===== Allow impersonation of users for members of admin group with specific role assigned
===== Allowing to impersonate users for members of a group with a specific role assigned
- Create a "User Permission" for specific users (or all users) you want to allow impersonation.
- Create a "Group Policy" allowing access to members of `test-admins`.
- Create a "Role Policy" allowing access to users assigned the `impersonation-admin` role.
- Assign both policies to the permission.
===== Blacklist specific users from being impersonated
===== Blacklisting specific users from being impersonated
- Create a *User Permission* for the specific users you want to prevent from being impersonated.
- Create any policy that evaluates to deny (such as a user policy with no users selected).
- Assign the policy to the permission to effectively block impersonation for the selected users.
===== Allow viewing users but not managing them for admins with defined role assigned
===== Allowing to view users but not managing them for admins with a defined role assigned
- Create a "User Permission" with the *view* scope for all users.
- Create a "Role Policy" allowing access to users with specific role assigned.
- Do _not_ assign the `manage` scope to prevent modification of user details.
===== Allow managing users and role assignment for members of a group
===== Allowing to manage users and role assignment for members of a group
- Create a "User Permission" with the *manage*, *map-roles* scopes for all users.
- Create a "Group Policy" allowing access to members of `test-admins`.
===== Allow viewing and managing members of a group but not members of its subgroups
===== Allowing to view and manage members of a group but not members of its subgroups
- Create a "Group Permission" with the *view-members* and *manage-members* scopes for specific group `mygroup`.
- Assign a "Group Policy" targeting `test-admins` to it.
- Create another "Group Permission" with the *view-members* and *manage-members* scopes for specific group, select all subgroups of the `mygroup`.
- Create negative "Group Policy" for `test-admins` and assign it to the "subgroups" permission.
===== Allow impersonating members of a specific group
===== Allowing to impersonate members of a specific group
- Create a "Group Permission" with the *impersonate-members* for specific group `mygroup`.
- Assign a "Group Policy" targeting `mygroup-helpdesk` to it.

2
docs/documentation/upgrading/topics/changes/changes-26_2_0.adoc
View File

@@ -143,6 +143,8 @@ Due to fundamental changes in the permission model, **automatic migration from V
** The *user-impersonated* user permission has been _removed_.
** The *configure* client permission has been _removed_. With the introduction of explicit operation scoping in V2, the distinction between manage and configure became ambiguous.
** The *user-impersonated* user permission has been _removed_. Instead, you can use the `impersonate-members` scope of the `Groups` resource type to allow or deny impersonation of group members.
** Permissions to `manage-members` of a group do not allow a realm administrator to unassign members from groups. The reason for that is that in V1 this was allowing a member of a group to become
a regular realm user, and workaround permissions to create users in a realm. In the future, we will be working to provide additional scopes to allow deleting members from groups.
* Flexible resource scoping:
** Unlike V1, where permissions were granted either to *a single resource* (for clients, groups, and roles) or *all resources* (for users), V2 introduces greater flexibility.
** Administrators can now define permissions for: