Skip to content

Commit

Permalink
Files groups
Browse files Browse the repository at this point in the history
  • Loading branch information
herver1971 committed Nov 12, 2024
1 parent dc917a1 commit 92eaf37
Show file tree
Hide file tree
Showing 16 changed files with 205 additions and 0 deletions.
Binary file added docs/images/add_roles.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/assign_roles.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/create_role.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/developers.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/group_details.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/group_user.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/group_user2.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/group_user3.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/groups.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/scopes2.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/user_details.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/user_master.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
89 changes: 89 additions & 0 deletions docs/permisos/grupos.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,89 @@
# Grupos

Los grupos en Keycloak gestionan un conjunto común de atributos y asignaciones de roles para cada usuario. Los usuarios pueden ser miembros de cualquier número de grupos y heredan los atributos y asignaciones de roles asignados a cada grupo.

Para gestionar grupos, haz clic en **Groups** en el menú.

![Groups](../images/groups.png)

Los grupos son jerárquicos. Un grupo puede tener múltiples subgrupos, pero un grupo solo puede tener un padre. Los subgrupos heredan los atributos y asignaciones de roles de su padre. Los usuarios heredan los atributos y asignaciones de roles de su padre también.

Si tienes un grupo padre y un grupo hijo, y un usuario que pertenece solo al grupo hijo, el usuario en el grupo hijo hereda los atributos y asignaciones de roles tanto del grupo padre como del grupo hijo.

La jerarquía de un grupo a veces se representa usando la ruta del grupo. La ruta es la lista completa de nombres que representa la jerarquía de un grupo específico, de arriba hacia abajo y separada por barras inclinadas / (similar a los archivos en un sistema de archivos). Por ejemplo, una ruta puede ser /superior/nivel1/nivel2, lo que significa que superior es un grupo de nivel superior y es padre de nivel1, que a su vez es padre de nivel2. Esta ruta representa de manera inequívoca la jerarquía para el grupo nivel2.

Debido a razones históricas, Keycloak no escapa las barras inclinadas en el nombre del grupo. Por lo tanto, un grupo llamado nivel1/grupo bajo superior usa la ruta /superior/nivel1/grupo, lo que es engañoso. Keycloak puede iniciarse con la opción --spi-group-jpa-escape-slashes-in-group-path=true y entonces las barras inclinadas en el nombre se escapan con el carácter . El carácter de escape marca que la barra inclinada es parte del nombre y no tiene un significado jerárquico. El ejemplo anterior de la ruta sería /superior/nivel1/grupo cuando está escapado.

```bash
bin/kc.[sh|bat] start --spi-group-jpa-escape-slashes-in-group-path=true
```

El siguiente ejemplo incluye un grupo de nivel superior Ventas y un subgrupo hijo, Norteamérica.

1. Haz clic en el grupo.

2. Haz clic en **Create group**.

3. Introduce un nombre para el grupo.

4. Haz clic en Create.

5. Haz clic en el nombre del grupo.

Se muestra la página de gestión del grupo.

![Groups](../images/group_details.png)

Los atributos y asignaciones de roles que definen son heredados por los grupos y usuarios que son miembros del grupo.

Para agregar un usuario a un grupo:

1. Haz clic en **Users** en el menú.

2. Haz clic en el usuario al que deseas realizar una asignación de roles. Si el usuario no aparece, haz clic en **View all users**.

3. Haz clic en **Groups**.

![Groups](../images/group_user.png)

4. Haz clic en **Join Group**.

5. Selecciona un grupo en el diálogo.

6. Selecciona un grupo del árbol **Available Groups**.

7. Haz clic en **Join**.

Para eliminar un grupo de un usuario:

1. Haz clic en **Users** en el menú.

2. Haz clic en el usuario que deseas eliminar del grupo.

3. Haz clic en **Leave** en la fila de la tabla de grupos.

En este ejemplo, el usuario jimlincoln está en el grupo Norteamérica. Puedes ver a jimlincoln bajo la pestaña Miembros del grupo.

![Groups](../images/group_user2.png)

## Comparación entre grupos y roles

Los grupos y roles tienen algunas similitudes y diferencias. En Keycloak, los grupos son una colección de usuarios a los que se les aplican roles y atributos. Los roles definen tipos de usuarios y las aplicaciones asignan permisos y control de acceso a los roles.

Los roles compuestos son similares a los grupos ya que brindan la misma funcionalidad. La diferencia entre ellos es conceptual. Los roles compuestos aplican el modelo de permisos a un conjunto de servicios y aplicaciones. Usa roles compuestos para gestionar aplicaciones y servicios.

Los grupos se enfocan en colecciones de usuarios y sus roles en una organización. Usa grupos para gestionar usuarios.

## Uso de grupos predeterminados

Para asignar automáticamente la pertenencia a un grupo a cualquier usuario que sea creado o importado a través de la intermediación de identidad, utiliza grupos predeterminados.

1. Haz clic en **Realm settings** en el menú.

2. Haz clic en la pestaña **User registration**.

3. Haz clic en la pestaña **Default Groups**.

![Groups](../images/group_user3.png)


8 changes: 8 additions & 0 deletions docs/permisos/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
# Asignación de permisos utilizando roles y grupos

Los roles y grupos tienen un propósito similar, que es otorgar a los usuarios acceso y permisos para utilizar aplicaciones. Los grupos son una colección de usuarios a los que se les aplican roles y atributos. Los roles definen permisos específicos de aplicaciones y control de acceso.

Un rol típicamente se aplica a un tipo de usuario. Por ejemplo, una organización puede incluir roles de administrador, usuario, gerente y empleado. Una aplicación puede asignar acceso y permisos a un rol y luego asignar múltiples usuarios a ese rol para que todos los usuarios tengan el mismo acceso y permisos. Por ejemplo, la Consola de Administración tiene roles que otorgan permiso a los usuarios para acceder a diferentes partes de la Consola de Administración.

Hay un espacio de nombres global para los roles, y cada cliente también tiene su propio espacio de nombres dedicado donde se pueden definir roles.

104 changes: 104 additions & 0 deletions docs/permisos/roles.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,104 @@
# Roles

## Creación de un rol de ámbito

Los roles a nivel de ámbito son un espacio de nombres para definir tus roles. Para ver la lista de roles, haz clic en Roles de ámbito en el menú.

![Create Role](../images/create_role.png)

1. Haz clic en **Create Role**.

2. Introduce un **Role Name**.

3. Introduce una **Description**.

4. Haz clic en **Save**.

![Create Role](../images/developers.png)

El campo de descripción se puede localizar especificando una variable de sustitución con cadenas ${var-name}. El valor localizado se configura en tu tema dentro de los archivos de propiedades de los temas.

## Roles de cliente

Los roles de cliente son espacios de nombres dedicados a los clientes. Cada cliente obtiene su propio espacio de nombres. Los roles de cliente se gestionan en la pestaña Roles de cada cliente. Interactúas con esta IU de la misma manera que con los roles a nivel de ámbito.

## Conversión de un rol a un rol compuesto

Cualquier rol a nivel de ámbito o cliente puede convertirse en un rol compuesto. Un rol compuesto es un rol que tiene uno o más roles adicionales asociados con él. Cuando un rol compuesto se asigna a un usuario, el usuario adquiere los roles asociados con el rol compuesto. Esta herencia es recursiva, por lo que los usuarios también heredan cualquier compuesto de compuestos. Sin embargo, recomendamos que no se abuse de los roles compuestos.

1. Haz clic en **Realm Roles** en el menú.

2. Haz clic en el rol que deseas convertir.

3. En la lista de Acciones, selecciona **Add associated roles**.

![Create Role](../images/add_roles.png)

La IU de selección de roles se muestra en la página y puedes asociar roles a nivel de ámbito y a nivel de cliente con el rol compuesto que estás creando.

En este ejemplo, el rol a nivel de ámbito empleado está asociado con el rol compuesto desarrollador. Cualquier usuario con el rol desarrollador también hereda el rol empleado.

!!! note

Al crear tokens y aserciones SAML, cualquier compuesto también tiene sus roles asociados agregados a las reclamaciones y aserciones de la respuesta de autenticación enviada de vuelta al cliente.

## Asignación de asignaciones de roles

Puedes asignar asignaciones de roles a un usuario a través de la pestaña **Role Mappings** para ese usuario.

1. Haz clic en **Users** en el menú.

2. Haz clic en el usuario al que deseas realizar una asignación de roles.

3. Haz clic en la pestaña **Role mappings**.

4. Haz clic en **Assign role**.

5. Selecciona el rol que deseas asignar al usuario en el diálogo.

6. Haz clic en **Assign**.

![Create Role](../images/assign_roles.png)

En el ejemplo anterior, estamos asignando el rol compuesto desarrollador a un usuario. Ese rol fue creado en el tema de Roles Compuestos.

![Create Role](../images/user_details.png)

Cuando se asigna el rol desarrollador, el rol empleado asociado con el rol compuesto desarrollador se muestra con Heredado **True**. Los roles heredados son los roles asignados explícitamente a los usuarios y los roles que se heredan de los compuestos.

## Uso de roles predeterminados
Utiliza roles predeterminados para asignar automáticamente asignaciones de roles de usuario cuando se crea o importa un usuario a través de la intermediación de identidad.

1. Haz clic en **Realm settings** en el menú.

2. Haz clic en la pestaña **User registration**.

![Create Role](../images/user_master.png)

## Asignaciones de ámbito de roles

Al crear un token de acceso OIDC o una aserción SAML, las asignaciones de roles de usuario se convierten en reclamaciones dentro del token o aserción. Las aplicaciones utilizan estas reclamaciones para tomar decisiones de acceso sobre los recursos controlados por la aplicación. Keycloak firma digitalmente los tokens de acceso y las aplicaciones los reutilizan para invocar servicios REST seguros de forma remota. Sin embargo, estos tokens tienen un riesgo asociado. Un atacante puede obtener estos tokens y utilizar sus permisos para comprometer tus redes. Para evitar esta situación, utiliza Asignaciones de Ámbito de Roles.

Las Asignaciones de Ámbito de Roles limitan los roles declarados dentro de un token de acceso. Cuando un cliente solicita una autenticación de usuario, el token de acceso que recibe contiene solo las asignaciones de roles que se especifican explícitamente para el ámbito del cliente. El resultado es que limitas los permisos de cada token de acceso individual en lugar de otorgar al cliente acceso a todos los permisos de los usuarios.

De manera predeterminada, cada cliente obtiene todas las asignaciones de roles del usuario. Puedes ver las asignaciones de roles para un cliente.

1. Haz clic en **Clients** en el menú.

2. Haz clic en el cliente para ver los detalles.

3. Haz clic en la pestaña **Client scopes**.

4. Haz clic en el enlace en la fila con el alcance dedicado y los asignadores para este cliente.

5. Haz clic en la pestaña **Scope**.

![Create Role](../images/scopes.png)

De manera predeterminada, los roles efectivos de los ámbitos son todos los roles declarados en el ámbito. Para cambiar este comportamiento predeterminado, cambia **Full Scope Allowed** a **OFF** y declara los roles específicos que deseas en cada cliente. También puedes usar los alcances de cliente para definir las mismas asignaciones de ámbito de rol para un conjunto de clientes.

![Create Role](../images/scopes2.png)




4 changes: 4 additions & 0 deletions mkdocs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,10 @@ nav:
- clientes/index.md
- clientes/clientes_openid_connect.md
- clientes/clientes_saml.md
- Permisos:
- index.md
- roles.md
- grupos.md

markdown_extensions:
- admonition
Expand Down

0 comments on commit 92eaf37

Please sign in to comment.