Wikipédia

User-Managed Access

protocole de gestion d'accès

User-Managed Access (UMA) est un protocole standard de gestion d'accès basé sur OAuth. La version 1.0 de ce standard a été approuvée par l'initiative Kantara (en) le [1].

Comme cela est décrit par la charte du groupe qui a développé UMA[2], l'objet des spécifications du protocole est de « permettre à un propriétaire de ressources de contrôler l'autorisation en ligne d'accès à ses ressources protégées lorsque la requête est faite par un demandeur autonome ».

Cette initiative a des implications quant à la vie privée, le consentement des applications Web et l'internet des objets (IoT), comme le montre l'ensemble des études de cas décrit par les participants du "standards group" de l'initiative Kantara (en)[3].

Historique et contexte modifier

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

Les principes à l'origine d'UMA proviennent d'un projet de protocole antérieur commencé en à 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.

État d'avancement et standardisation modifier

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].

Mise en œuvre et adoption modifier

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.

Comparaison avec OAuth 2.0 modifier

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

Scénarios applicables modifier

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.

Références modifier

  1. ↑ (en) « User Managed Access Work Group »
  2. ↑ « Charter - WG », sur kantarainitiative.org via Wikiwix (consulté le ).
  3. ↑ a et b (en) « WG - User Managed Access »
  4. ↑ http://kantarainitiative.org/confluence/display/uma/Home UMA Work Group Wiki
  5. ↑ http://kantarainitiative.org/confluence/display/uma/Meetings+and+Minutes?src=contextnavchildmode UMA workgroup meeting minutes
  6. ↑ (en) « Home - WG », sur kantarainitiative.org via Internet Archive (consulté le ).
  7. ↑ http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg Internet Draft: OAuth 2.0 Dynamic Client Registration Core Protocol
  8. ↑ (en) P. Hunt, « OAuth 2.0 Dynamic Client Registration Protocol », sur tools.ietf.org, (ISSN 2070-1721, DOI 10.17487/RFC7591, consulté le ).
  9. ↑ (en) « UMA Implementations - WG », sur kantarainitiative.org via Internet Archive (consulté le ).
  10. ↑ « Digital Identity for Consumers and Workforce | ForgeRock »
  11. ↑ (en) « Gluu OSS implementation of UMA »,
  12. ↑ (en) « mitreid-connect / OpenID-Connect-Java-Spring-Server »
  13. ↑ https://github.com/atricore/node-uma/ Atricore OSS implementation of UMA for Node.js
  14. ↑ « Rohe/pyuma », sur GitHub (consulté le ).
  15. ↑ « Home - WG », sur kantarainitiative.org via Internet Archive (consulté le ).
  16. ↑ (en) « HEART WG », sur OpenID - The Internet Identity Layer, (consulté le ).

Liens Externes modifier

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=User-Managed_Access&oldid=211242447 ».