User-Managed Access

Le groupe de travail UMA[4] de l'initiative Kantara (en) a tenu sa première réunion le 6 août 2009[5].

Les principes à l'origine d'UMA proviennent d'un projet de protocole antérieur commencé en mars 2008 à l'initiative d'employés de Sun Microsystems intitulé ProtectServe. ProtectServe a lui-même été influencé par le mouvement Vendor Relationship Management et un projet associé appelé "feeds-based VRM".

Les premières versions de ProtectServe et de UMA se sont inspirées du protocole OAuth 1.0. Comme OAuth a subi des changements significatifs lors de la publication de la spécification Web Resource Authorization Protocol (WRAP), et par la suite des modifications associées à OAuth 2.0, UMA utilise désormais les spécifications OAuth 2.0 pour plusieurs protocoles clés de flux.

UMA n'utilise pas ou ne dépend pas d'OpenID 2.0 comme moyen d'identification de l'utilisateur. Cependant, UMA utilise de façon optionnelle le protocole OpenID Connect comme moyen de recueillir les requêtes d'identité lorsqu'il s'agit de satisfaire les politiques d'accès des utilisateurs.

UMA n'utilise pas non plus ou ne dépend pas de XACML (eXtensible Access Control Markup Language) comme moyen d'encoder le contrôle d'accès et les décisions associées à la politique de sécurité. UMA ne dicte pas le format du contrôle d'accès puisque l'évaluation de l'accès est effectuée en interne par le serveur d'accès (AS). Toutefois, les flux du protocole UMA pour demander l'autorisation d'accès partagent certaines caractéristiques en commun avec le protocole XACML.

Le groupe de travail UMA fait partie de l'initiative Kantara [6] et a également contribué à une série de spécifications pour IETF (Internet Engineering Task Force) comme un cadre éventuel pour les travaux de normalisation. À cette fin, le groupe de travail a contribué et soumis plusieurs propositions à IETF. L'un d'elles est une spécification pour l'enregistrement dynamique d'un client OAuth[7] qui a servi d'introduction pour un mécanisme plus général finalement développé pour OAuth [8].

Le protocole de base d'UMA a plusieurs implémentations[9] y compris certaines open source. Les sources d'implémentations open-source disponibles comprennent ForgeRock[10], Gluu[11], MITREid Connect[12], Atricore, Node-UMA [13] and Roland Hedberg[14].

Une initiative du groupe Kantara (en) travaille sur le développement de “free and open-source software" (FOSS) dans plusieurs langages de programmation qui permet aux développeurs d'intégrer la protection de UMA et son API d'autorisation dans les applications, les services et les appareils connectés[15].

Des produits logiciels utilisant UMA sont offerts Gluu, Jericho Systems et ForgeRock.

Le diagramme (voir à droite) met en évidence des ajouts clés qu'UMA apporte à OAuth 2.0.

Dans un flux de OAuth typique, un propriétaire de ressources ou "Resource Owner" (RO) qui opère une application cliente est redirigé vers un serveur d'autorisation ou "Authorization Server"(AS) pour se connecter et consentir à la délivrance d'un jeton d'accès afin que l'application cliente gagne accès au serveur de ressource ou "Resource Server" (RS) au nom du propriétaire de ressources (RO) et ceci d'une façon limitée. Le serveur de ressource (RS) et le serveur d'autorisation opèrent généralement dans le même domaine de sécurité, de plus, aucune des communications entre ces deux serveurs ne sont standardisées par les principales spécifications OAuth.

UMA ajoute trois concepts principaux, structures et flux spécifiques:

• Premièrement UMA définit une API normalisée associée au serveur d'autorisation (AS) appelée l'API de protection avec lequel le serveur de ressource interagit. Cette API permet à plusieurs serveurs de ressources (RS) de communiquer avec un serveur d’autorisation (AS) particulier et vice versa. Et parce que l'API est elle-même sécurisée avec OAuth, ceci permet l'établissement de la confiance formelle entre chaque pair. Cela permet également à un serveur d’autorisation (AS) de présenter une interface utilisateur centralisée à un propriétaire de ressources (RO).
• Deuxièmement UMA définit une notion formelle de demandeur de requête ou "Requesting party" (RqP) qui est autonome du point de vue du serveur de ressource (RO) ce qui permet le partage de ressources de parti à parti et la délégation de l'autorisation d'accès. Un propriétaire de ressources (RO) n'a pas besoin de consentir à l'émission de jetons en temps réel, mais peut définir la politique d'accès à l'avance par l’intermédiaire du serveur d’autorisation (AS), ce qui permet à un demandeur de requête (RqP) de tenter un accès asynchrone.
• Troisièmement, UMA permet en réponse à des tentatives d'accès à des ressources, l'émission de jetons d'autorisation associés à des données sur la base d'un processus d'élévation de confiance pour le demandeur de requête, y compris la collecte de revendications d'identité ou d'autres réclamations similaires.

Vue d'ensemble de haut niveau des entités et des relations impliquées dans la spécification UMA

L'architecture UMA peut servir une grande variété de scénarios à la fois pour les consommateurs, mais aussi dans le domaine de l'entreprise. Le groupe UMA rassemble de nombreuses études de cas sur son wiki[3].

Un ensemble d'exemples d'utilisation se situe dans le domaine de l'informatique médicale et du bien être des consommateurs. Faisant partie de l'organisation OpenID Foundation, un groupe de travail appelé "Health Relationship Trust" (HEART) [16] travaille à harmoniser et développer un ensemble de spécifications de la vie privée et de sécurité qui permettent à un individu de contrôler l'autorisation d'accès aux données relatives à la santé grâce à des APIs de type RESTful, et qui est construit à partir de plusieurs standards dont UMA.

Un autre ensemble d'exemples de cas d'utilisation, qui ont influencé l'origine du développement de l'UMA, se situe dans le domaine des « bases de données personnelles » du type « vendor relationship management » (gestion des relations fournisseurs) qui est capable d'accepter des demandes de connexions à partir d'une variété d'hôtes de ressources numériques et offre un tableau de bord avec des capacités de gestion du partage des ressources.

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « User-Managed Access » (voir la liste des auteurs).

• UMA FAQ
• User-Managed Access (UMA) Profile of OAuth 2.0 Recommendation
• OAuth 2.0 Resource Set Registration Recommendation
• Venn of access control
• UMA Implementations