Los sistemas de software para la gestión de múltiples proyectos son complejos, al menos en el aspecto técnico. Hay que proporcionar una multitud de funciones para planificar proyectos individuales, gestionar tareas, crear informes, por nombrar sólo algunas. Al mismo tiempo, no sólo un usuario trabaja con él. No, normalmente hay docenas de usuarios que comparten todas estas funciones y los datos del sistema, a menudo trabajando con él simultáneamente y desde diferentes lugares. Y, por supuesto, la aplicación debe ser "superfácil" de usar para todos los implicados y tener una excelente experiencia de usuario, según los requisitos de la empresa, por supuesto.

Los sistemas multiusuario requieren un concepto de autorización

Con esta posición de partida, no es de extrañar que el sistema de software que se busque deba tener un concepto de autorización flexible pero también fácilmente comprensible. ¿Qué queremos decir con esto? En el contexto de un sistema de software, el concepto de autorización se define de forma sencilla,

1. qué usuario
2. a los que los datos
3. qué tipo de acceso.

Esto plantea varias cuestiones de comprensión que deben ser explicadas. En primer lugar, el usuario del sistema debe ser identificado por el sistema. Esto también se denomina autentificación. El usuario se conecta al sistema diciendo quién es y el sistema le pide que lo demuestre. Esto parece complicado, pero lo hacemos varias veces al día introduciendo nuestro nombre de usuario y una contraseña para ello en una ventana de acceso. Con el nombre de usuario le digo al sistema quién soy, y con la contraseña proporciono la prueba. Este sencillo proceso se denomina autentificación. Si queremos aportar un poco más de seguridad, entonces exigimos una prueba más al usuario, por ejemplo pidiéndole que teclee un código adicional de un solo uso que el sistema envía a su teléfono móvil. Aquí es donde hablamos entonces de la autenticación de 2 factores. Pero este no es el tema aquí.

¿Qué son los permisos?

Con la autentificación, ahora sabemos a quién tenemos enfrente. Pero, ¿qué puede hacer este usuario en el sistema? Aquí es donde entra la autorización , es decir, la asignación de autorizaciones con respecto a los datos y las funciones que contiene el sistema. Ahora se complica un poco más (al menos desde el punto de vista técnico). Básicamente, se define un conjunto básico de autorizaciones (también llamadas permisos ). A partir de este bote, se asignan una serie de permisos al usuario. Hasta aquí todo bien. Pero, ¿qué es exactamente un permiso?

Este es el primer gran reto de este tema. Una autorización puede definirse de muchas maneras diferentes. Algunos ejemplos:

• Ver un proyecto
• modificar una tarea
• generar un informe
• crear un nuevo usuario
• asignar una autorización

Sólo el último ejemplo demuestra que los permisos funcionan incluso de forma recursiva: Podemos definir permisos que permitan conceder otros permisos.... Pero también son interesantes los primeros ejemplos, porque nos muestran que un permiso suele actuar sobre un tipo de objeto (un proyecto, una tarea, un informe, etc.) e incluye una acción (ver, modificar, generar, etc.). Así que básicamente podemos enumerar todos los tipos de objetos de datos en nuestro sistema y tomar todas las acciones posibles para ello. Las combinaciones de éstas dan como resultado el conjunto básico de autorizaciones. Aunque esto sea sencillo de escribir, es complejo en la realidad. Incluso los sistemas sencillos de almacenamiento de datos contienen docenas de tipos de objetos y son posibles muchas acciones diferentes sobre ellos. La simple multiplicación de estos conjuntos conduce a una explosión de posibilidades. Añada a esto el hecho de que, naturalmente, le gustaría conceder permisos sobre objetos individuales (es decir, instancias de tipos de objetos). Por ejemplo, "cambiar el proyecto X", no generalmente "cambiar los proyectos". Esto añade otra dimensión de complejidad.

Esta plétora de permisos debe estar bien estructurada para poder controlarla y seguirla. Lo que podemos hacer, por ejemplo, es lo siguiente. Los permisos pueden estar relacionados entre sí en una estructura de árbol. Un permiso B puede definirse como una rama de un permiso A. De esta manera expresamos que si un usuario está autorizado a hacer B, entonces implícitamente también está autorizado a hacer A. De nuevo un ejemplo sencillo: "B = modificar un proyecto" y "A = modificar una tarea". Por lo tanto, si un usuario está autorizado a modificar un proyecto, implícitamente también debería modificar todas las tareas contenidas. Esto puede hacerse de forma similar con las acciones: "B = modificar un proyecto" y "A = ver un proyecto". En este caso, también el permiso B implica el permiso A, es decir, si alguien tiene permiso para modificar un proyecto, entonces también tiene permiso para verlo (claramente).

¿Cómo obtiene un usuario sus permisos?

Así que vamos a suponer que hemos definido y estructurado el conjunto básico de permisos y por lo tanto los conocemos. ¿Cómo puedo asignarlas a un usuario? A primera vista, se podría hacer una asignación directa. Por ejemplo: "El usuario Meier tiene los permisos B, D, E y H". Esto es fácil de entender, pero sólo porque el ejemplo es muy trivial. De nuevo, la complejidad reside en el gran número de combinaciones posibles. Si tenemos docenas o incluso cientos de usuarios y muchos más permisos, tenemos que lidiar con tablas de permisos exorbitantes. La visión de conjunto está entonces garantizada para desaparecer. El problema puede eliminarse si te conformas con un pequeño conjunto básico de permisos. Pero, por experiencia, podemos decir que todos los compradores de este tipo de sistemas de software exigen tanta flexibilidad en términos de "control y seguimiento del acceso" que necesitamos una solución mejor.

La mejor solución es la que funciona con rodillos . Este enfoque se remonta a principios de los años 90 y ha demostrado su eficacia en la práctica. Se utiliza en muchos, si no en la mayoría, de los sistemas de gestión de datos. Este enfoque se conoce como Control de Acceso Basado en Funciones (RBAC). El principio puede explicarse así: Definimos diferentes roles (por ejemplo, gestor de proyectos, gestor de cartera, administrador del sistema) y luego asignamos permisos a estos roles. Sólo entonces tomamos los usuarios y les damos uno o más roles. De esta manera, los usuarios obtienen sus permisos indirectamente a través de sus roles. Este principio tiene la gran ventaja de que puedo manejar la interacción entre usuarios y permisos más fácilmente, especialmente en caso de cambios. Y como todos sabemos, a menudo hay cambios. Así que si quiero revocar el permiso de los gestores de proyectos para cambiar de proyecto, lo hago en el rol "gestor de proyectos". Todos los usuarios con este rol tendrán inmediatamente los permisos modificados.

Por lo tanto, se requiere una estructura adecuada

Es el gran número de posibilidades para definir las autorizaciones y asignarlas a los usuarios lo que hace que la cuestión sea tan compleja. Sin embargo, con una estructura sofisticada, es decir, un buen concepto de autorización, podemos afrontar este gran reto. Las explicaciones anteriores sólo arañan la superficie del tema y el simple ejemplo de la introducción de roles no pretende en absoluto dar la impresión de que se trata de la última palabra en sabiduría. Es un enfoque posible y bueno. Lo que tampoco hemos abordado aquí es la visualización de todos los estados y funcionalidades del sistema desde el punto de vista del usuario. ¿Cómo puede un administrador de sistemas mantener fácilmente los usuarios, las funciones y los permisos y estar siempre seguro de que ha realizado la configuración correcta? Llegaremos al fondo de esta cuestión en un próximo artículo y mostraremos cómo lo resolvemos utilizando PQFORCE. Así que manténgase en sintonía.