UMS

O por su forma extendida User Managemente System, busca ser la aplicación central que administrara los usuarios, permisos y roles que tienen las aplicaciones de explorax. O en palabras más técnicas, se encarga de proveer los servicios de autenticación y autorización para las apps de Explorax ¡Bienvenido el manual de usuario del UMS!

¿Qué hace realmente?

El UMS no funciona muy diferente a las instituciónes de gobierno que registran a los ciudadanos de una nación; en Guatemala es el RENAP, en España la Dirección General de Policía. Estas instituciones registran la existencia de cada ciudadano en el pais, y les provee de un documento personal de identificación que luego puedes usar para acceder otras partes del Estado.

De forma similar, se puede ver a Explorax como un Estado con muchos ciudadanos (exploradores, maestros, administradores...) y organizaciones a las que se les quiere dar acceso (Sistemas), y no solo eso! También nos interesa saber que permisos tiene en cada organización, por ejemplo el presidente tiene más permisos que un ciudadano. El lugar donde todo eso es registrado y consultado es el UMS.

👤 Autenticación

De la misma manera que cuando quieres ir a hacer un trámite gubernamental te piden el documento de identificación para demostrar que eres tú, las aplicaciones de Explorax requieren que tu envies un documento de identificación en forma de JWT Token para saber quien realiza las peticiones, este token es creado por el UMS. De tal manera que cuando un usuario se loguea a cualquier aplicación primero se autentica contra el UMS, si las credenciales son correctas, se retorna un JWT Token con un tiempo de expiración variable.

El UMS solo guarda información mínima de cada usuario (nombre, contraseña...) información extra de cada usuario debe ser manejado por cada sistema independientemente.

🔒 Autorización

El UMS además de soportar registrar usuarios, permite gestionar un sistema de permisos, y roles, para facilitar mayor granularidad en el proceso de autorización.

Cada aplicación es responsable de gestionar su propia autorización, y puede usar el UMS para lograrlo.

A continuación se muestra el modelo del sistema de permisos.

• Usuario: Unidad minima de identidad, representa a un persona que busca interactuar con Explorax.

• Sistema: Representa una aplicación cualquiera de Explorax. Cada sistema tiene sus propios permisos y roles que son ESPECÍFICOS para ese sistema.

• Permiso: Unidad mínima de autorización. Representa una acción o conjunto de acciones. Se le puede asignar permisos directamente a usuarios o a roles. El permitir un acción dependerá de si el usuario tiene el permiso o no.

• Roles: Representa un conjunto de permisos predeterminados que se le pueden asignar o quitar a diferentes usuarios, pueden verse como sombreros que los usuarios pueden vestir o no. Un usuario puede tener varios roles a la vez, los permisos resultantes serán las sumas de los permisos de todos los roles.

• Usuarios Administrador: Usuarios especiales, que tienen acceso ilimitado al UMS, son ajenos al sistema de permisos, haciendo imposible eliminarlos, crearlos o restringirlos.

La UI fue construida justo para poder interactuar con estas entidades:

El Token JWT , ya contiene los permisos de un usuario al momento de autenticación, sin embargo, para casos donde se requiere que la edición de permisos de un usuario sea instantánea se recomienda validar los permisos del usuario directamente al UMS para cada petición, para tener la información más reciente.

Este es un ejemplo del token de acceso:

{
	"sub":            "1234567890",
	"username":       "test_user",
	"permissions":    [
            { 
                PermissionId: "1", 
                AccessLevel: "write", 
                PermissionName : "createStudents"
            }
        ]
	"iat":            1719428400, // example epoch timestamp
	"exp":            1719428520, // iat + 2 minutes
	"system_id":      1,
	"access_version": {
            "UserVersion" : 3
            "Roles": [
                {
                    "RoleId": 1, 
                    "AccessVersion": 4, 
                }
            ]
        },
	"is_root":        true,
}

Evaluación de permisos para una acción

Así como en la vida real, los permisos solo tienen sentido si hay un centinela que velé porque sean cumplidos, papel que normalmente hacen los guardias o recepcionistas.

De la misma forma, el UMS solo provee a cada sistema la información de que permisos tiene un usuario, esta en responsabilidad de cada aplicación implementar su centinela para permitir o denegar dependiendo de los permisos que el UMS revelé.

Orden de evaluación

Cuando se quiere saber el nivel de acceso para un permiso, se hace una union de los permisos directos y permisos dados roles, este es el orden de evaluación:

1. Permisos directos: Los permisos directamente asignados a un usuario tienen la mayor prioridad SIEMPRE.
2. Roles: Los roles cuentan con un atributo númerico de prioridad, a más pequeño el número, mayor su prioridad. Si varios roles hacen referencia al mismo permiso, se escogera la versión del role con mayor prioridad.

Invalidación de tokens

Como se ha mencionado, se utiliza tokens JWT como método de autenticación, al ser stateless ya no se tienen necesidad de llevar un registro en tiempo real de los usuario que se encuentran usando la aplicación. Sin embargo, por el mismo hecho de ser stateless es muy díficil invalidarlos, en escencia mientras un token no haya expirado puede seguirse utilizando e incluso compartirse para usos malintencionados.

Esto puede ser peligroso 💀 en situaciones donde se quiere modificar los permisos de un usuario y que estos cambios surtan efecto inmediatamente, aun cuando el token no ha expirado. En el modelo tradicional de JWT esto sería imposible, dado que la aplicación no tiene control sobre que hace el cliente con JWT.

La solución

Se implementó un sistema de versiones, los permisos, roles y usuarios estan versionados, y cada vez que se modifican, su versión incrementa, esto se ve reflejado en la seccion de access_version del JWT:

	"access_version": {
            "UserVersion" : 3
            "Roles": [
                {
                    "RoleId": 1, 
                    "AccessVersion": 4, 
                }
            ]
        },

De tal manera que si se quiere saber si la información del token es la más actualizada al momento de procesar una petición, solo basta comparar las versiones dadas por el token con las registradas en el presente por el UMS, si se encuentra una diferencia, se rechaza la petición y se solicita reiniciar sesión. Esto viene con el contra hacer siempre una consulta a la DB del UMS, lo cual no es inherentemente malo, es la forma en que sistemas que usan sesiones también solventan este problema.

Los sistemas

Una confusión recurrente, es creer que REGISTRAR un sistema en el UMS crea una aplicación real sobre la que ya se puede desarrollar y utilizar, pero nada más alejado de la realidad. Registrar un sistema solo consiste en hacerle saber al UMS la existencia de dicha aplicación, al hacerlo el UMS genera un ID para dicho sistema, este ID debe ser luego utilizado en la implementación del sistema real, para hacer consultas al UMS.

De la misma forma, durante la autenticación de un usuario, es obligatorio indicar el ID del sistema al que quiere ingresar.