El acceso administrado por el usuario, UMA, brinda a sus clientes y empleados una forma conveniente de determinar quién y en qué momento obtiene acceso a los datos personales, durante cuánto tiempo y bajo qué circunstancias. Los usuarios delegan el acceso a través de un simple botón de compartir en su aplicación, y pueden monitorear y administrar las preferencias de uso compartido a través de una consola central.
UMA: Qué es y por qué es importante
UMA (User Managed Access) es un protocolo estándar de autorización homologado por la Kantara Initiative, una agrupación profesional que tiene por objeto la promoción de relaciones empresariales basadas en la gestión de la identidad digital y la privacidad de los datos teniendo como base la innovación técnica y legal. Construida sobre OAuth 2.0, facilita el uso de datos, información y accesos de manera compartida entre varias partes.
Con UMA se establecen flujo de trabajos en los que los propietarios de ciertos recursos gestionan el acceso que tienen los demás integrantes de los equipos a una serie de recursos que, de otra manera, estarían protegidos. En UMA son clave las políticas de autorización que se establecen desde un servidor de autorización centralizado.
Estructura user-managed access
Dentro de las funciones establecidas dentro de un flujo de trabajo de UMA destacan 5 roles principales; el propietario de los recursos, que establece el control de éstos de manera que, desde un único servidor de autorización, gestiona diferentes recursos que se encuentran en varios servidores; el servidor de autorización o WSO2 Identity Server, que protege los recursos en el servidor de recursos; el servidor de recursos, que alberga los recursos protegidos y responde a las solicitudes de recursos protegidos; el cliente, que es una aplicación que actúa en nombre de la parte solicitante; y la parte solicitante, aquella entidad que desea acceder a un recurso protegido utilizando un cliente.
UMA 2 vs. OAuth2: Diferencias
OAuth2 es un protocolo de delegación de acceso a datos que proporciona el acceso a aplicaciones de terceros, a los que denomina ‘OAuth2 Clients’. La diferencia principal con UMA es que , mientras éste permite a los propietarios de recursos delegar el acceso a terceros basándose en políticas de autorización bien definidas y mantenidas en el servidor de autorización (AS), OAuth2 permite ese acceso en nombre del ‘resource owner’ (RO) utilizando un token de acceso temporal emitido por un servidor de autorización que cuenta con la aprobación del propietario.
UMA y OAuth2 no compiten entre sí, por el contrario, UMA se amplía desde OAuth2 mediante la introducción de un nuevo tipo de soporte llamado ‘UMA 2.0 Grant for OAuth 2.0’. OAuth2 cuenta con lo que denomina ‘Scope’, que se puede usar para nombrar varios permisos asociados con un recurso. UMA, por su parte, cuenta con la posibilidad de denominar recursos para representarlos y con una API para gestionarlos.
UMA & WSO2 Identity Server
Asegurar la privacidad de los datos se ha convertido en una prioridad y al mismo tiempo en un gran reto para numerosas organizaciones públicas y privadas. WSO2 Identity Server permite hacerlo mediante su colaboración con un user-managed access. Cuando el propietario de un recurso desea compartir con permiso de vista un recurso que se encuentra dentro de un servidor de recursos, por ejemplo la nube, con una parte solicitante, puede aprovechar las ventajas que le ofrece el identity server de WSO2. En este caso, el propietario de los datos utilizaría el UMA para externalizar la autorización y gestionar de manera proeactiva los recursos, así como su acceso desde un único servidor de autorización.
Definir las políticas de acceso
Como servidor de autorización se utiliza el WSO2 Identity Server, que sirve para definir las políticas en cuanto a quién puede acceder a qué recurso y con qué alcance de permiso. Si es una tercera parte la que utiliza una aplicación móvil para acceder a los datos en nombre de otra persona, y esta tercera parte realiza una solicitud de recurso sin un token de acceso con las credenciales de seguridad o un RPT (Request Party Token) válido, el servidor de recursos se dirige al servidor de autorización para solicitar uno o más permisos.
A cambio, el servidor de recursos recibe un ticket de permiso y el servidor de recursos envía al cliente un ticket de permiso recién creado y la URL del servidor de autorización.
A continuación, el cliente solicita un RPT proporcionando las reclamaciones válidas y el ticket de permiso. El cliente recibirá un RPT si la evaluación de autorización resulta ser exitosa. A partir de este momento, el cliente puede solicitar de nuevo al servidor de recursos el acceso a la información protegida con el token de acceso válido.
