Lab004 - Control de acceso basado en roles.

En este laboratorio, realizaremos la creación de roles para controlar y restringir este consumo, a clientes específicos.

1. Creación de roles en Keycloak.

1.1. Activar el Keycloak que instalamos en el laboratorio 001.

1.2. Acceder usando las siguientes credenciales; y seleccionar el realm de labs:

• user: admin
• password: admin

1.3. En la barra de navegación, seleccionar la opción Realm Roles y presionar el botón de

1.4. En la pantalla de Create role, introducir el siguiente valor en el formulario:

• Role name*: lab-admin-role
• Description: Rol de pruebas para la nivel administrador.

1.5. Presionar el botón

1.6. Repetir el procedimiento para crear otro rol con la siguiente información:

• Role name*: lab-read-role
• Description: Rol de pruebas para la nivel usuario.

2. Creación de un usuario en Keycloak.

2.1. Seguir el procedimiento de la laboratorio 001 Paso 4, crear el siguiente usuario:

• Email verified: true
• Username: useradmin
• Email: useradmin@g6flow.com
• First name: Admin
• Last name: Demostración

2.2. Crear la contraseña del usuario desde la pestaña de Credential, y presionando el botón de , justo como se realizo en el laboratorio 001, colocando la contraseña Pass1234 y desactivando la opción de Temporary.

2.3. En la pestaña de Role mapping, asignar el role de lab-admin-role al usuario useradmin, presionando el botón

2.4. En la ventana de selección de roles, presionar el selector del control combinado de Filter by clients, y seleccionar la opción Filter by realm roles.

2.5. Seleccionar el role de lab-admin-role y presionar el botón

2.6. Como podemos observar en la imagen, se asigno el role seleccionado, con lo que concluimos este paso.

3. Asignar role de lectura a userdemo en keycloak.

Seleccionar al opción de Users desde la barra de navegación del Keycloak y buscar el usuario userdemo y presionar en la columna de Username sobre el:

Dar clic en la pestaña de Role mapping y repetir los pasos de asignación de role de procedimiento anterior, pero esta vez, seleccionado el role de lab-read-role

4. Mapeo de roles para el token de keycloak.

Para poder tener acceso a la información de roles del token, es necesario habilitar desde los ámbitos de cliente (Client scopes) mediante un mapper que permita dicha visibilidad. A continuación realizaremos el siguiente procedimiento para si activación.

4.1. Acceder a la opción desde la barra de navegación de Keycloak; de Client scopes, y seleccionar el que dice profile

4.2. En la pestaña de Mappers, presionar el botón de y seleccionar la opción de .

En el cuadro de dialogo de Add predefined mappers, introducir en la barra de búsqueda "roles", seleccionar realm roles y presionar el botón de

Una vez asignado el mapper, se debe cambiar el Token Claim Name a realm_roles y se debe seleccionar para activar la opción de Add to userinfo y que aparezca al momento de solicitar la información del usuario mediante ese endpoint. Al activar la opción, presionar el botón de

5. Verificación de visibilidad de realm roles en el token.

5.1 Desde el swagger ui del xposer, buscar la sección de OpenID Connect que configuramos en el lab002 y repetir los pasos para solicitar el token y copiarlo para realizar la consulta de los datos en userinfo en el body del response.

5.2. En el método GET, llenar las opciones como sigue y presionar el botón de execute button:

• authorization: bearer [[pegar el token seleccionado en el paso previo]]
• *: userinfo

Y como podemos apreciar, ya aparece el listado de roles en nuestra información de usuario.

5.3. Repetir los pasos, calculando el token con las credenciales del usuario useradmin que fabricamos en pasos previos de este laboratorio.

6. Actualización de regla con roles.

A continuación, generaremos una ruta que impida el consumo, a menos que se tenga asignado el rol de lab-admin-role fabricado en el punto 3 de este laboratorio.

6.1. Desde la sección de Xposer Admin RULE del swagger ui del Xposer, utilizaremos el endpoint de PUT /xposer-admin/v1/rules para editar la regla rule::mockwsecuritytoken::001 que creamos en el laboratorio 003, y utilizaremos el siguiente payload para realizar la petición de actualización:

{
  "name": "rule security  token w/roles",
  "description": "Regla de Servidor de consumo de OAuth2 API aplicando roles.",
  "endpointType": "mockup",
  "mockup": "mockup::testingaccount::001",
  "groups": [],
  "consumers": [],
  "authorizationType": "token",
  "roles": ["lab-admin-role"],
  "route": "route::mockuptest::001",
  "id": "rule::mockwsecuritytoken::001"
}

6.2. Colocar el identificador de la regla en el campo de id y presionar el botón de execute button

6.3. Debemos obtener una respuesta como la que se muestra en la imagen, con lo que tendremos la certeza de que se han aplicado los cambios.

Nota: Recuerda introducir el APIKEY en el botón de , de lo contrario recibirás errores de acceso no autorizado al intentar consumir los servicios.

7. Pruebas de acceso y consumo.

En esta sección, realizaremos las pruebas necesarias para validar que se estén aplicando correctamente los controles de acceso al servicio que protegimos mediante la regla de acceso basada en roles.

Calcularemos un token para el usuario useradmin utilizando la siguiente información

• client_id: consumidor_autorizado_oauth
• client_secret: [[EL-SECRET-QUE-GENERARON]]
• grant_type: password
• scope: openid email
• username: useradmin
• password: Pass1234

Copiamos el token y procedemos a ejecutar el servicio de la sección Lab003 y probamos el servicio de GET /labs/core/accounts y observamos que nos permite ejecutarlo correctamente.

Ahora ejecutaremos con el usuario userdemo, al que le asignamos el role de lab-read-role y que no cuenta con permiso especifico para poder consumir los servicios relacionados con la regla que configuramos anteriormente.

• client_id: consumidor_autorizado_oauth
• client_secret: [[EL-SECRET-QUE-GENERARON]]
• grant_type: password
• scope: openid email
• username: userdemo
• password: Pass1234

Copiamos el token y en el servicio de GET /labs/core/accounts pegamos el token en la opción de authorization

Y como podemos observar en la imagen a continuación, se rechazo el role, debido a que no cuenta con el role necesario para utilizar el servicio.