En juin 2018, lors de conférence #Identiverse à Boston (la première conférence annuelle de l’industrie de la sécurité de l’identité), j’ai subitement compris eu une révélation pendant la conférence d’Eve et Mike. J’ai finalement réalisé que le protocole User-Managed Access 2.0 (aussi appelé UMA2.0) n’est pas si compliqué à comprendre et qu’il est très semblable à certains flux OAuth2 que nous connaissons tous. Laissez-moi vous expliquer.
UMA2.0 : une extension d’OAuth2
Avant de creuser davantage le sujet, le point important à garder en tête est le fait que UMA2.0 a été conçu comme un nouveau type d’autorisation d’OAuth2 et non comme un nouveau protocole. Si vous êtes déjà familier avec OAuth 2.0, vous pourrez comprendre UMA2 en moins de 10 minutes. Je vous le promets !
Ci-dessous une illustration d’un flux typique d’UMA2.0 :
- Le client initie une requête contre la ressource sans jeton ;
- Le serveur de ressources sollicite un ticket auprès du serveur d’autorisation en lui envoyant les détails de la ressource demandée (champs d’application et identifiant enregistré de la ressource demandée) ;
- Le serveur de ressources renvoie une réponse d’erreur incluant l’emplacement du serveur d’autorisation accompagné d’un ticket de permission ;
- Le client demande en option un « Requesting Party Token » (RPT – considéré comme la forme personnalisée d’un jeton d’accès d’UMA) directement dans le terminal du serveur d’autorisation grâce au ticket de permission ;
- Le client redirige l’utilisateur vers le endpoint d’autorisation du serveur d’autorisation pour demander un jeton. Le serveur d’autorisation interagit avec le demandeur pour rassembler tout ce qui est nécessaire pour prendre une décision d’autorisation (authentification, collecte des attributs, etc.) – vous allez vous rendre compte que ça nous semble familier !
- Le serveur d’autorisation redirige l’utilisateur vers l’URI de redirection client (URI pour « Uniform Resource Identifier ») incluant un ticket de permission mis à jour – oui, je connais ça !
- Le client demande un « Requesting Party Token » (RPT) contre le terminal du serveur d’autorisation grâce à un ticket de permission mis à jour – je m’en souviens maintenant… !
- Les serveurs d’autorisation répondent avec le « Requesting Party Token » (RPT) et un « Persisted Claims Token » (PCT) (les détails suivent) – nous avons donc un code éphémère contre deux jetons, mmh, ça me semble vraiment familier…
- Le client demande le serveur de ressources avec le « Requesting Party Token » (UMA2 recommande en fait de se conformer à la pratique OAuth2, de manière similaire au RFC 6750 ou au PoP)
- Le serveur de ressources demande facultativement au serveur d’autorisation de valider le jeton demandeur de requête (en utilisant le terminal d’introspection OAuth2 – suivant « RFC 7662 Token Introspection » étendu par UMA2) ou peut le faire localement selon le format du jeton.
Voyez-vous le flux des codes d’autorisation ? Laissez-moi vous monter :
En effet, les étapes 5 à 8 sont TRES semblables à l’attribution du code d’autorisation d’OAuth2.
Si vous passez outre les approximations suivantes, il n’y a vraiment pas d’autres différences majeures :
- L’« Access Token » (AT) devient un « Requesting Party Token » (RPT) (un jeton avec des résultats d’introspection de jeton personnalisés) ;
- Le « Refresh Token » (RT) a maintenant un compagnon : le « Persisted Claims Token » (PCT) (qui est en fait une variante de la classe « refresh token ») ;
- Le code d’autorisation devient une sorte de ticket d’autorisation modifiable.
Donc effectivement, ce n’est pas la même chose : il y a quelques étapes à intégrer avant la partie surlignée et c’est conséquemment un peu plus long.
UMA2.0 : bien plus qu’OAuth2
A présent, User-Managed Access (UMA) a été conçu pour une raison. Et il ne s’agit pas de simplement renommer quelques artefacts OAuth2. Il y a quelques différences qui permettent à UMA2.0 de fonctionner au-delà des capacités standards OAuth2.
Examinons de plus près les différences :
- Étape 1-3 : Le client peut obtenir des informations de manière standardisée sur la manière d’obtenir un jeton (en particulier l’emplacement du serveur d’autorisation) en contactant la ressource avec une demande sans jeton alors que si l’on suit protocole OAuth2 RFC 6750, aucune information ne devrait être retournée par la ressource (un périmètre insuffisant pourrait être couvert seulement si un jeton était fourni).
- Etape 4 : Le client peut essayer d’obtenir un jeton sans se lancer dans une démarche impliquant l’utilisateur. Peut-être qu’aucune autorisation ou qu’aucun consentement de l’utilisateur ne soit nécessaire pour recueillir un nouveau jeton, ou peut-être qu’un jeton déjà délivré (le PCT) était suffisant pour obtenir celui-ci. Si cet appel réussit, vous passerez directement à l’étape 9 et ceci peut être comparé au flux d’assertion OAuth2 (« RFC 7523 JSON Web Token Profile »).
- Étape 5 : Seulement si nécessaire, l’utilisateur final est incité à interagir avec le serveur d’autorisation par l’intermédiaire de l’agent utilisateur, pour s’authentifier, recueillir des réclamations à son sujet, obtenir son consentement, etc. alors que dans OAuth2, l’agent utilisateur est sollicité même si aucune interaction n’est requise et même si cela peut nuire à son expérience utilisateur.
- Étape 8 : Un « Persisted Claims Token » (PCT) supplémentaire peut être remis au client afin de faciliter les livraisons de « Requesting Party Token » (RPT) ultérieures pour le même demandeur mais pour une ressource cible différente (alors qu’un « Refresh Token » (RT) ne ferait que rafraîchir un RPT pour une partie requérante et une ressource cible données).
Avant l’étape 1, une ressource peut enregistrer des endpoints sur un serveur d’autorisation d’une manière standard après l’autorisation fédérée pour UMA2.0 (mais cela pourrait être couvert dans un autre article).
La norme UMA2 permet de (et est en fait conçue pour) séparer le demandeur et le propriétaire de la ressource (alors que OAuth2 considère qu’il s’agit d’une seule et même personne). Cette différenciation nous permet de traiter davantage de cas d’usage que OAuth2 ne peut permettre par défaut :
- Un propriétaire de document peut le partager avec d’autres personnes ; par exemple, un patient peut partager des données médicales (différentes) avec son conjoint, ses proches ou son médecin ;
- Un propriétaire d’application peut concevoir des règles permettant à certains employés de l’entreprise (ou partenaires commerciaux) d’accéder à une application/API ;
- Un propriétaire de ressources peut agréger la gestion du partage des ressources sous un seul serveur d’autorisation, même si les ressources résident dans de nombreux domaines ;
- Une application peut obtenir des permissions supplémentaires et mettre à jour les portées des « Access Token » sans impliquer l’agent utilisateur dans une démarche OAuth2 si les politiques d’autorisation le permettent.
Toutes les permissions ci-dessus peuvent être accordées de manière asynchrone (alors que le consentement de l’utilisateur OAuth2 n’est synchrone que dans le flux de demande de jeton).
Merci à Eve Maler pour ses éclairages dans l’écriture de cet article!
