En una aplicación B2B, decidir quién puede consultar, modificar o aprobar un recurso afecta al producto, la operación y el riesgo. Un modelo demasiado simple puede conceder acceso de más; uno excesivamente detallado puede resultar difícil de administrar y explicar. La decisión entre roles o permisos por contexto no consiste en escoger una etiqueta técnica: consiste en representar las reglas reales del negocio de forma comprensible, verificable y sostenible.
La opción adecuada depende de cuánto varía el acceso entre usuarios, recursos y situaciones, y de quién tendrá que gestionar esas diferencias. Conviene empezar por los casos reales, no por una lista de controles. Después se puede adoptar el modelo más sencillo que los cubra y definir señales concretas para evolucionarlo.
Autenticación y autorización resuelven preguntas distintas
La autenticación comprueba quién es el usuario, por ejemplo, mediante una sesión o un proveedor de identidad. La autorización determina qué puede hacer esa identidad sobre un recurso concreto. Haber iniciado sesión no implica tener permiso para ver todas las facturas, proyectos o datos de una empresa.
Para diseñar la autorización, describid cada decisión con cuatro elementos: el actor, la acción, el recurso y las condiciones aplicables. Por ejemplo: “una persona con permiso de facturación puede descargar facturas de su organización”. Esta frase obliga a aclarar si el permiso se aplica a todas las organizaciones, a una organización seleccionada o solo a determinados documentos.
También conviene definir desde el inicio el ámbito de los datos. En un producto con varias empresas clientes, una comprobación correcta del rol no basta si la consulta devuelve recursos de otro cliente. La autorización debe cubrir tanto la acción como el acceso al recurso y su pertenencia al ámbito correspondiente.
Permisos basados en roles: claridad cuando los patrones se repiten
En el control de acceso basado en roles, o RBAC, se agrupan permisos en roles y se asignan roles a usuarios. Un rol como “administrador de organización” podría permitir gestionar miembros y configuración; otro, como “analista”, podría dar acceso de lectura a informes. La aplicación comprueba si el rol del usuario incluye el permiso necesario para la acción.
Este enfoque funciona bien cuando los puestos o responsabilidades del producto se repiten y las diferencias entre usuarios son relativamente estables. Facilita explicar el acceso en la interfaz, crear perfiles habituales y revisar asignaciones. También ofrece un vocabulario compartido entre producto, soporte y tecnología: es más fácil discutir “editor” que mantener una lista opaca de permisos individuales.
Pero los roles no deberían convertirse automáticamente en etiquetas laborales. Una misma persona puede tener responsabilidades distintas en cada organización, y un rol global puede conceder demasiado. Es habitual que el rol tenga un ámbito: por ejemplo, “administrador” dentro de una organización, no de toda la plataforma. Definid con precisión quién asigna roles, a qué recursos se aplican y si una persona puede acumular varios.
Elegid roles cuando los permisos formen conjuntos reconocibles, cambien poco y puedan administrarse sin crear un rol nuevo para cada excepción. Si las combinaciones se multiplican (“editor con acceso solo a dos proyectos, salvo durante una aprobación”), quizá el rol esté intentando representar demasiadas dimensiones.
Reglas contextuales: acceso según el usuario, el recurso o la situación
Una regla contextual toma en cuenta atributos además de la identidad o el rol. El acceso puede depender de quién solicita la acción, qué recurso intenta usar y bajo qué condiciones. Por ejemplo, se podría permitir editar un proyecto solo si la persona pertenece al equipo asignado y el proyecto está en estado de borrador. Este enfoque suele relacionarse con el control de acceso basado en atributos, o ABAC.
Las reglas contextuales son útiles cuando los mismos usuarios tienen distintos permisos sobre recursos diferentes, o cuando el estado del negocio cambia lo permitido. Pueden representar pertenencia a un equipo, propiedad de un registro, clasificación de datos o fase de aprobación. Así se evita crear un rol distinto para cada combinación de usuario y recurso.
La flexibilidad tiene un coste: las decisiones se vuelven menos visibles si dependen de atributos dispersos o de condiciones difíciles de explicar. Una regla puede fallar porque el estado del recurso está desactualizado, falta un dato o no se ha definido el comportamiento ante un valor desconocido. Para cada condición, identificad su fuente, responsable, actualización y tratamiento de errores. Si falta un dato necesario para conceder acceso, la política debe denegar la acción de forma segura.
“Permisos por contexto” no significa necesariamente implantar un motor complejo. Puede ser una comprobación explícita de pertenencia y estado dentro de una aplicación pequeña. Lo importante es que la regla sea coherente, centralizable y comprobable, no que adopte una arquitectura determinada.
Cómo comparar los enfoques en casos reales
Preparad una matriz pequeña con usuarios representativos, acciones y recursos. Incluid casos normales y excepciones: un usuario de dos organizaciones, un recurso compartido, una persona que cambia de equipo y una acción de aprobación. Para cada fila, anotad el resultado esperado y la razón. Comparad entonces cuánto cuesta expresar y administrar las reglas en cada enfoque.
- Variabilidad: ¿los permisos dependen principalmente de responsabilidades estables o cambian según el recurso y su estado?
- Administración: ¿un administrador de cliente puede entender y mantener las asignaciones sin ayuda técnica constante?
- Excepciones: ¿son ocasionales y controlables, o se repiten hasta formar un segundo sistema de roles informal?
- Auditoría: ¿podéis explicar por qué se permitió o denegó una operación y reconstruir qué regla se aplicó?
- Impacto de errores: ¿qué datos quedarían expuestos o qué operación se bloquearía si una condición se configura mal?
No comparéis solo el número de roles o reglas. Un modelo con pocos elementos puede ser difícil de entender si sus efectos se combinan de manera implícita. Valorad también la experiencia de quien configura el acceso y la facilidad para responder una pregunta de soporte: “¿por qué esta persona no puede abrir este documento?”.
Señales de exceso y de complejidad prematura
Los roles probablemente están creciendo en exceso cuando aparecen nombres casi idénticos para pequeñas variaciones, cuando cada cliente solicita un rol exclusivo o cuando las condiciones del recurso se codifican como excepciones dentro del rol. También es una señal que nadie pueda explicar la diferencia entre dos perfiles sin consultar el código.
En sentido contrario, las reglas contextuales pueden ser prematuras si casi todos los usuarios comparten permisos, no hay una necesidad de acceso por recurso y el equipo no dispone de datos fiables para evaluar atributos. En ese escenario, construir un sistema general de políticas añade puntos de fallo y costes de mantenimiento sin resolver un problema real.
Usad estas señales como motivo para revisar el modelo, no como una orden automática de migración. Agrupar roles, aclarar ámbitos o corregir asignaciones puede bastar. Si las excepciones expresan diferencias legítimas y repetidas, entonces merece la pena diseñar reglas más explícitas.
Evolucionar sin romper permisos existentes
Una evolución gradual reduce sorpresas. Primero, inventariad los permisos actuales y describid los casos esperados con ejemplos. Separad las políticas de autorización de la presentación de la interfaz: ocultar un botón mejora la experiencia, pero no sustituye la comprobación en el servidor cada vez que se ejecuta la acción.
- Definid una decisión central: estableced cómo se consulta si un actor puede realizar una acción sobre un recurso, evitando comprobaciones contradictorias repartidas por la aplicación.
- Escribid pruebas de acceso: cubrid casos permitidos, denegados, límites entre organizaciones, cambios de estado y atributos ausentes. Revisad también operaciones de lectura y escritura.
- Comparad antes de sustituir: durante una transición, evaluad el modelo nuevo en paralelo con el anterior y registrad discrepancias sin conceder acceso adicional por esa comparación.
- Migrad por casos acotados: trasladad una acción o tipo de recurso, verificad resultados con responsables del negocio y mantened una forma controlada de revertir el cambio.
- Registrad decisiones relevantes: conservad información útil para investigar denegaciones o accesos sensibles, evitando incluir datos personales innecesarios en los registros.
Antes de desplegar, preguntad: ¿quién puede conceder acceso y con qué alcance?, ¿qué sucede al retirar a una persona de un equipo?, ¿cómo se comporta el sistema si falta un atributo?, ¿puede una organización acceder a recursos de otra?, ¿se puede explicar y probar cada excepción? Si no hay respuestas claras, el siguiente paso es concretar las reglas, no añadir más roles o condiciones.
Como criterio práctico, empezad con roles cuando las responsabilidades sean estables y legibles. Añadid reglas contextuales cuando una necesidad repetida dependa de recursos o circunstancias que los roles no representen bien. En ambos casos, priorizad ámbitos explícitos, denegación segura, pruebas y administración comprensible. El mejor modelo es el más sencillo que refleje las decisiones reales del negocio y pueda revisarse cuando cambien.