Wikipédia

Utilisateur:Fandry/Brouillon

Cette page est un brouillon appartenant à Fandry
Conseils de rédaction
  • → N'hésitez pas à publier sur le brouillon un texte inachevé et à le modifier autant que vous le souhaitez.
  • → Pour enregistrer vos modifications au brouillon, il est nécessaire de cliquer sur le bouton bleu : « Publier les modifications ». Il n'y a pas d'enregistrement automatique.

Si votre but est de publier un nouvel article, votre brouillon doit respecter les points suivants :

  • Respectez le droit d'auteur en créant un texte spécialement pour Wikipédia en français (pas de copier-coller venu d'ailleurs).
  • Indiquez les éléments démontrant la notoriété du sujet (aide).
  • Liez chaque fait présenté à une source de qualité (quelles sources  – comment les insérer).
  • Utilisez un ton neutre, qui ne soit ni orienté ni publicitaire (aide).
  • Veillez également à structurer votre article, de manière à ce qu'il soit conforme aux autres pages de l'encyclopédie (structurer – mettre en page).
  • → Si ces points sont respectés, pour transformer votre brouillon en article, utilisez le bouton « publier le brouillon » en haut à droite. Votre brouillon sera alors transféré dans l'espace encyclopédique.

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 le 23 mars 2015.[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 à ces 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.[3]

Historique et Contexte

modifier

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

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.

É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. A cette fin, the groupe de travail (WG) a contribute et soumis plusieurs propositions à IETF. L'un d'elles est une specification 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 Oeuvre 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 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 [16], Jericho Systems [17] et ForgeRock.

Comparaison avec OAuth 2.0

modifier

Le diagramme (voir à droite) met en évidence des ajouts clés que 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 resource ou "Resource Server" (RS) au nom du propriétaire de ressources (RO) et ceci d'une facon limitée. Le serveur de resource (RS) et le serveur d'autorisation opèrent généralement dans le même domaine de sécurité, de plus, aucunes des communications entre ces deux serveurs ne sont standardisées par les principales specifications 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 resource interagit. Cette API permet à plusieurs serveur de ressources (RS) de communiquer avec un serveur d'autorization (AS) particulier et vice versa. Et parce que l'API est elle-même securisée avec OAuth, ceci permet l'établissement de la confiance formelle entre chaque paire. Cela permet également à un serveur d'autorization (AS) de présenter une interface utilisateur centralisée à un propriétaire de resources (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 resource (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'intermediaire du serveur d'autorization (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 resources, 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.
 
Ce diagramme fournit une 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.[18]

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) [19] 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 relation fournisseur) qui est capable d'accepter des demandes de connections à 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.


References

modifier
  1. ↑ https://kantarainitiative.org/confluence/display/LC/User+Managed+Access+V1.0
  2. ↑ http://kantarainitiative.org/confluence/display/uma/Charter
  3. ↑ http://kantarainitiative.org/confluence/display/uma/Case+Studies
  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. ↑ http://kantarainitiative.org/confluence/display/uma/Home
  7. ↑ http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg Internet Draft: OAuth 2.0 Dynamic Client Registration Core Protocol
  8. ↑ https://tools.ietf.org/html/rfc7591
  9. ↑ http://kantarainitiative.org/confluence/display/uma/UMA+Implementations
  10. ↑ http://forgerock.org/openuma/
  11. ↑ http://www.gluu.org/open-source/open-source-vs-on-demand/ Gluu OSS implementation of UMA
  12. ↑ https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/tree/uma
  13. ↑ https://github.com/atricore/node-uma/ Atricore OSS implementation of UMA for Node.js
  14. ↑ https://github.com/rohe/pyuma
  15. ↑ http://kantarainitiative.org/confluence/display/umadev/Home
  16. ↑ http://www.gluu.org/gluu-server/access-management/
  17. ↑ https://www.jerichosystems.com/company/pr04082015.html
  18. ↑ http://kantarainitiative.org/confluence/display/uma/Case+Studies
  19. ↑ http://openid.net/wg/heart/

Liens Externes

modifier

[[Category:Cloud standards]] [[Category:Computer access control]] [[Category:Identity management]] [[Category:Federated identity]] [[Category:Identity management systems]]

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Utilisateur:Fandry/Brouillon&oldid=128487202 ».