Acceso gestionado por el usuario

El Acceso Gestionado por el Usuario (UMA) es un protocolo estándar de gestión de acceso basado en OAuth para la autorización entre partes. ^{[ 1 ]} La versión 1.0 del estándar fue aprobada por la Iniciativa Kantara el 23 de marzo de 2015. ^{[ 2 ]}

Como se describe en el acta constitutiva del grupo que desarrolló UMA, ^{[ 3 ]} el propósito de las especificaciones del protocolo es “permitir que el propietario de un recurso controle la autorización del intercambio de datos y otros accesos a recursos protegidos entre servicios en línea en nombre del propietario o con su autorización por parte de un solicitante autónomo”. Este propósito tiene implicaciones en materia de privacidad y consentimiento para las aplicaciones web y el Internet de las Cosas (IoT), como se explora en la recopilación de estudios de caso aportados por los participantes del grupo de estándares. ^{[ 4 ]}

El diagrama de ^{[ 5 ]} (ver a la derecha) destaca las adiciones clave que UMA hace a OAuth 2.0.

En un flujo típico de OAuth: el propietario del recurso (RO), un usuario de una aplicación cliente, es redirigido a un servidor de autorización (AS) para iniciar sesión y autorizar la emisión de un token de acceso . Este token permite que la aplicación cliente acceda a la API del servidor de recursos (RS) en nombre del propietario del recurso en el futuro, probablemente con un alcance limitado. El servidor de recursos y el servidor de autorización suelen operar dentro del mismo dominio de seguridad, y la comunicación entre ellos no está necesariamente estandarizada por la especificación principal de OAuth.

El acceso gestionado por el usuario añade tres conceptos principales y sus correspondientes estructuras y flujos:

API de protección

UMA define una API de protección estandarizada para los servidores de autorización con los que los servidores de recursos se comunican en materia de seguridad de datos . Esta API permite que varios servidores de recursos se comuniquen con un servidor de autorización y viceversa. Dado que la propia API de protección está protegida mediante OAuth, permite establecer una relación de confianza formal entre cada par. Esto también permite que un servidor de autorización presente una interfaz de usuario centralizada para los propietarios de recursos.

Parte solicitante (RqP)

UMA define a las partes solicitantes por separado de los propietarios de los recursos. Esto permite compartir información entre partes y delegar la autorización de acceso de forma precisa . El propietario de un recurso no necesita dar su consentimiento para la emisión de tokens en tiempo de ejecución (es decir, cada vez que se solicitan sus datos), sino que puede definir una política en el servidor de autorización para permitir a las partes solicitantes el acceso asíncrono a ámbitos de autorización específicos y limitados.

Elevación de la confianza

UMA permite que los intentos de acceso resulten en la emisión exitosa de tokens de autorización mediante un proceso de elevación de confianza para las partes solicitantes. Este proceso puede implicar la recopilación de datos de identidad u otros datos de la parte solicitante, lo que facilita una mayor seguridad de los datos de los propietarios de los recursos.

El Grupo de Trabajo UMA de la Iniciativa Kantara ^{[ 3 ]} celebró su primera reunión ^{[ 6 ]} el 6 de agosto de 2009. Los principios de diseño y el diseño técnico de UMA se basaron en trabajos previos de empleados de Sun Microsystems , iniciados en marzo de 2008, sobre un protocolo llamado ProtectServe. A su vez, ProtectServe se vio influenciado por los objetivos del movimiento de Gestión de Relaciones con Proveedores (VRM) y una iniciativa derivada denominada VRM basada en feeds.

Las primeras versiones de ProtectServe y UMA utilizaban el protocolo OAuth 1.0. A medida que OAuth experimentó cambios significativos con la publicación de la especificación del Protocolo de Autorización de Recursos Web (WRAP) y, posteriormente, con los borradores de OAuth 2.0, la especificación de UMA se ha mantenido al día y ahora utiliza la familia de especificaciones de OAuth 2.0 para varios flujos de protocolo clave.

UMA no utiliza ni depende de OpenID 2.0 como método de identificación de usuarios. Sin embargo, opcionalmente utiliza el protocolo OpenID Connect, basado en OAuth, para recopilar información de identidad de la parte solicitante e intentar cumplir con la política de acceso del usuario que autoriza el acceso.

UMA tampoco utiliza ni depende del Lenguaje de Marcado de Control de Acceso Extensible ( XACML ) para codificar políticas de usuario o solicitar decisiones sobre políticas. UMA no impone el formato de las políticas, ya que la evaluación de las mismas se realiza internamente en el servidor de autorización (AS) desde la perspectiva de UMA. Normalmente, XACML se usaría para implementar las políticas dentro del AS. Su implementación queda fuera del alcance de UMA. Los flujos del protocolo UMA para solicitar permisos de acceso comparten algunas características con el protocolo XACML.

El grupo UMA lleva a cabo su trabajo en la Iniciativa Kantara ^{[ 7 ]} y también ha contribuido con una serie de especificaciones de Internet-Draft al Grupo de Trabajo de Ingeniería de Internet (IETF) como un eventual hogar para el trabajo de estandarización de UMA. Con este fin, el WG ha contribuido con varios Internet-Drafts individuales al IETF para su consideración. Uno de ellos, una especificación para el registro dinámico de clientes OAuth, ^{[ 8 ]} sirvió como insumo para el mecanismo más generalizado que finalmente se desarrolló para OAuth. ^{[ 8 ]} UMA fue presentado al Grupo de Trabajo de OAuth ^{[ 9 ]} en la conferencia IETF 104 en marzo de 2019, ^{[ 10 ]} pero eso no resultó en que el IETF adoptara ninguna especificación de UMA.

El protocolo central UMA tiene varias implementaciones, ^{[ 11 ]} incluyendo varias implementaciones de código abierto. Las fuentes de implementaciones de código abierto activas y disponibles incluyen ForgeRock , ^{[ 12 ]} Gluu, ^{[ 13 ]} IDENTOS Inc., ^{[ 14 ]} MITREid Connect, ^{[ 15 ]} Atricore , Node-UMA, ^{[ 16 ]} Roland Hedberg, ^{[ 17 ]} Keycloak , ^{[ 18 ]} y WSO2 Identity Server . ^{[ 19 ]} Un grupo de Kantara Initiative está trabajando en el desarrollo de " software libre y de código abierto (FOSS), en varios lenguajes de programación populares, que permite a los desarrolladores incorporar la protección UMA y la habilitación de la API de autorización en aplicaciones, servicios y dispositivos". ^{[ 20 ]}

Los productos habilitados para UMA están disponibles de Gluu, ^{[ 21 ]} Jericho Systems, ^{[ 22 ]} ForgeRock, ^{[ 23 ]} IDENTOS Inc. ^{[ 24 ]} y WSO2 Identity Server ^{[ 19 ].}

El protocolo UMA tiene múltiples implementaciones. Forgerock ofrece una primera implementación de código abierto bajo OpenUMA. ^{[ 25 ]} Una primera implementación del servidor de autorización se probará con OpenAM en la compilación nocturna. ^{[ 26 ]}

Gluu ha implementado UMA para proteger y gestionar el acceso a las API. ^{[ 27 ]} Cloud Identity Limited cuenta con una implementación completa de UMA para proteger y gestionar el acceso a la información personal y las API web. Varias otras empresas han manifestado interés en realizar pruebas de implementación e interoperabilidad al grupo de trabajo.

La arquitectura de UMA puede servir para una variedad de casos de uso orientados al consumidor y a la empresa. El grupo UMA recopila estudios de caso en su wiki. ^{[ 28 ]}

Un ejemplo de casos de uso se encuentra en la informática sanitaria y la salud del consumidor. En la organización OpenID Foundation, un grupo de trabajo llamado Health Relationship Trust (HEART) ^{[ 29 ]} está trabajando para "armonizar y desarrollar un conjunto de especificaciones de privacidad y seguridad que permitan a un individuo controlar la autorización de acceso a las API RESTful de intercambio de datos relacionados con la salud", basándose, entre otros estándares, en UMA.

Otro ejemplo de casos de uso, que influyó originalmente en el desarrollo de UMA, se centra en el ámbito de los "almacenes de datos personales" al estilo de la gestión de relaciones con proveedores . En este concepto, un usuario puede elegir un operador de un servicio de autorización que acepte conexiones de diversos proveedores de recursos digitales orientados al consumidor, con el fin de ofrecer un panel de control con capacidades de gestión de recursos compartidos.

• Preguntas frecuentes de UMA
• Perfil de acceso gestionado por el usuario (UMA) de la recomendación OAuth 2.0
• Recomendación para el registro de conjuntos de recursos de OAuth 2.0
• Implementaciones de UMA