Roles & permissions: diseñar acceso mínimo
Objetivo y permisos
Roles & permissions separa Roles, conjuntos de capacidades, de Permissions, catálogo consultable. La navegación usa admin.roles.view; mutaciones requieren la autorización administrativa correspondiente. La autoridad efectiva depende además del rol activo y del tenant permitido. Una membresía secundaria potente no equivale a utilizar ese rol como contexto activo.
Un rol debe responder a un trabajo reconocible. No lo diseñe marcando todas las casillas de un administrador existente. La ausencia de un botón no reemplaza la comprobación del servidor; mostrarlo tampoco concede acceso si la sesión carece de permiso.
Campos
| Campo | Regla visible |
|---|---|
| Key | Obligatorio; letra minúscula inicial, después minúsculas, números o guion bajo; 3–64 caracteres |
| Label | Nombre obligatorio, hasta 80 caracteres |
| Scope | Alcance ofrecido; formulario estático muestra Tenant |
| Tenant | Workspace obligatorio |
| Description | Explicación opcional, hasta 500 caracteres |
| Permissions | Selección desde catálogo disponible |
La clave no es una contraseña. Use una convención estable como operador_laboratorio y una etiqueta descriptiva. La descripción debe explicar tareas, sin datos personales ni excepciones secretas.
Diseño y revisión
- Liste tareas necesarias: consultar, crear, modificar o administrar.
- Consulte Permissions y distinga lectura de gestión; no infiera que una contiene la otra.
- Cree el rol en Roles, elija tenant y asigne el conjunto mínimo.
- Guarde y revise. Asigne el rol a una cuenta sintética autorizada desde Users.
- Compruebe el camino permitido y el rechazado. Verifique rol activo y cierre la sesión de prueba al terminar.
Modificar un rol usado por varias personas es un cambio compartido. Una sola pantalla no prueba todo el alcance. Mantenga una matriz de tarea, permiso y resultado esperado que permita revisar cambios posteriores.
POC sintético
El laboratorio necesita consultar cuentas y auditoría sin crear workers. Prepare una cuenta ficticia y un rol con capacidades de lectura disponibles para esas tareas. Compruebe Users y Audit dentro del alcance esperado y ausencia de gestión de Cloud workers. Si falta una lectura, añada únicamente el permiso identificado y repita.
La evidencia debe mostrar nombres sintéticos y resultados de autorización, nunca sesiones ni tokens. No use una cuenta de plataforma para representar menor privilegio: ocultaría errores. Repita la comprobación tras cambiar contexto de workspace cuando la cuenta de prueba tenga más de una membresía autorizada.
Errores, recuperación y límites
Ajuste una clave inválida antes de enviar. Si tenant no aparece, confirme alcance delegado; no introduzca identificadores manuales para sortear el selector. Ante rechazo revise la sesión y rol activo del administrador que realiza la acción.
Eliminar un rol tiene confirmación propia. Revise asignaciones y efecto sobre usuarios: no asuma que puede eliminar cualquier rol ni que se sustituirá automáticamente. Un error del servidor no se resuelve quitando verificaciones. Para recuperar acceso tras un cambio incorrecto utilice una vía administrativa autorizada y documente la corrección, sin compartir credenciales.
Separe permisos técnicos de responsabilidades organizativas. La aplicación valida capacidades, pero el operador debe justificar el motivo del cambio. Revise periódicamente roles que ya no correspondan al trabajo actual y retire capacidades mediante el proceso aprobado.