UMA

Si nous avons vu qu’avec OAuth2 [1] et OpenID Connect [2], il était possible de gérer des autorisations et de l’authentification d’utilisateurs, pourtant ces deux protocoles trouvent vites certaines limites lorsqu’il s agit de partager les ressources entre les utilisateurs.

C’est ce use case que va remplir UMA [3] (User Management Access, en version 2 depuis 2017) en proposant une forme d’encapsulation de OAuth2 au sein d’un processus un peu plus complexe mais permettant, en s’appuyant sur ce dernier, de fournir les mécanismes de partages de ressources.

Dans ce nouveau use case, par rapport à OAuth2, l’utilisateur du client qui veut consommer la ressource n’est plus le propriétaire de celle-ci mais seulement un acteur auquel le propriétaire a octroyer des droits et des permissions auprès du serveur d’autorisation et d’authentification.

Ce contexte peut alors se décrire un peu sous la forme suivante:

On voit ici qu’en fait par rapport à OAuth2, nous sommes dans une configuration très similaire. La différence notable es que l’Utilisateur Requesting Party n’est pas le Resources Owner qui a du préalablement configurer des permissions qui devront être vérifier lors du processus d’accès aux données.

Pour voir les différences, le mieux est de reprendre le processus proposé par UMA qui en fait se décline en 2 spécifications:

la première [3] traite du process global d’acquisition des permissions par le client (demandant un accès a une ressource) pour l’obtention des ressources fournit par le serveur de ressources
la seconde [4] traite de la gestion des interactions entre le serveur de ressources et le serveur d’authentification en détaillant :
- comment enregistrer une ressource et définir ses permissions,
- comment sur une demande de ressource, le serveur de ressources va renvoyé après communication avec le serveur d’autorisation un token au client
- comment le serveur de ressource, sur une demande d’accès a une ressource avec un token, va aller vérifier la légitimité de ce token auprès du serveur d’autorisation afin de pouvoir fournir la ressource demandé au client.

Ces deux spécifications peuvent ainsi se résumer au diagramme de séquence suivant:

Resource registration endpoint

Un utilisateur possédant au sein d’un server de ressource va pousser vers ce dernier la déclaration d’une ressource a protéger partageable. Associée a cette ressource, le propriétaire va définir au sein du serveur d’authentification des les policy ou permissions permettant de connaître comment cette ressources peut être consommée et par qui.

Permission Endpoint

Une fois les policy déclarés, l’utilisateur en demande de la ressource va alors pouvoir démarrer le processus de demande de droit sur celle ci. Cela passe par le server de ressource qui en conséquence de la demande de la ressource va demander au serveur d’auth un ticket de permission qu’il repoussera a l’utilisateur.

Core flow

Avec ce ticket et sur la base de son propre bearer de connexion, l ‘utilisateur demandeur va alors devoir demander un token spécifique le RPT (Requesting Parting token) au serveur d’authentification qui consolidera a la fois les autorisation et l’authentification de l’utilisateur ainsi que ses permissions effectives sur la ressource.

Token introspection endpoint

Avec le RPT, l’utilisateur va alors pouvoir refaire une requête d’access a la ressource auprès du serveur de ressources qui aura la charge de s’assurer que ce token est bien legit auprès du serveur d’authentification.

Exemple

Tout ce la peut paraître encore un peu obscure. Pour rendre cela plus accessible, le plus simple est de l’illustrer via un exemple simple ou nous déroulerons a la main chacune de ces étapes.

Pour cela nous utiliserons Keycloak dans lequel nous consoliderons:

Un royaume de test avec l’option UMA activée

Un client configurer avec les autorisation d’activé en mode service account.

un utilisateur bob auquel on aura donné le rôle uma-protection associé au client précédemment construit

Et enfin un utilisateur Marcel qui sera consommateur de la ressource.

Maintenant il faut déclarer une ressource. Cela est realisé par le serveur de ressource aupres du serveur d’auth pour l’utilisateur Bob. On va donc devoir recuperer un bearer token pour Bob

que nous utiliserons pour créer la ressource.

Cela nous renvoie en réponse la description json de la resource (exemple issus de la documentation keycloak):

{
    "name": "Tweedl Social Service",
    "type": "http://www.example.com/rsrcs/socialstream/140-compatible",
    "owner": {
        "id": "0a4d3ca3-9799-42fe-a8ee-d7a57783317c",
        "name": "bob"
    },
    "ownerManagedAccess": false,
    "_id": "832c3aea-3704-42e0-a1fb-9ee3800bfd8b",
    "uris": [],
    "resource_scopes": [
        {
            "id": "96451c48-a5f5-4566-8df8-ed43d2c86a5f",
            "name": "read-private"
        },
        {
            "id": "4d213bfb-4c66-4f7d-92da-808e0bab91ce",
            "name": "post-updates"
        },
        {
            "id": "dc86dc9c-4ca4-4c33-bc14-e1024ce148ad",
            "name": "read-public"
        },
        {
            "id": "0d96cebf-1ebd-4128-8a0f-4ab45b684502",
            "name": "http://www.example.com/scopes/all"
        }
    ],
    "scopes": [
        {
            "id": "96451c48-a5f5-4566-8df8-ed43d2c86a5f",
            "name": "read-private"
        },
        {
            "id": "4d213bfb-4c66-4f7d-92da-808e0bab91ce",
            "name": "post-updates"
        },
        {
            "id": "dc86dc9c-4ca4-4c33-bc14-e1024ce148ad",
            "name": "read-public"
        },
        {
            "id": "0d96cebf-1ebd-4128-8a0f-4ab45b684502",
            "name": "http://www.example.com/scopes/all"
        }
    ],
    "icon_uri": "http://www.example.com/icons/sharesocial.png"
}

Sur cette ressource, Bob pourra faire des recherches comme pour toutes ressources REST. Par exemple:

ou encore:

Et maintenant que Bob a une ressource, Marcel va pouvoir lui demander un accès. Pour cela, Keycloak [5] fourni une interface de gestion permettant de gérer les autorisations sur les ressources partagées.

Il reste maintenant a Marcel la tache de dérouler le processus OAuth2/ UMA pour obtenir la ressource. Comme nous l’avons vu, cela commence par faire une demande directement sur la ressource qui forcement n’aboutira pas car nécessairement les permissions ne sont pas connus a ce moment la.

Le serveur de ressource va donc faire une requête permettant de récupérer un ticket consolidant les permissions existantes sur la ressource en fonction des droits accordés à Marcel le demandeur.

Marcel se voit maintenant en possession d’un ticket signé décrivant les droits accordés à l’utilisateur.

{
  "exp": 1665241512,
  "nbf": 0,
  "iat": 1665241212,
  "permissions": [
    {
      "scopes": [
        "read-public"
      ],
      "rsid": "832c3aea-3704-42e0-a1fb-9ee3800bfd8b"
    }
  ],
  "jti": "31361fdd-e612-4e15-80a2-2571f2d7a0f8-1665241237353",
  "aud": "http://localhost:8080/auth/realms/UMA-REALM",
  "sub": "3beac458-2930-4dd1-a524-afaf816978a8",
  "azp": "RS-Client-4-UMA"
}

Cela lui permettant sur la base de son identité sur le serveur (via son bearer token) d’obtenir un nouveau bearer token (RPT) auprès du serveur d’authentification.

Avec ce nouveau bearer token, Marcel va enfin pouvoir récupérer la ressource. Pour cela il va réaliser la même requête déjà réalisé sur le serveur de ressources. Ce dernier ayant alors la charge, avant de fournir la dite ressource, de vérifier ce token via le endpoint d’introspection.

Conclusions

Voila, nous avons parcouru l’utilisation de UMA grace a Keycloak et de ses capacités fonctionnelles plus qu’intéressantes pour le partage de ressources tout en restant compatible avec OAuth2 et OpenIdConnect.

La dernière cible sera pour un prochain article, le protocole Ciba qui, on le verra, apporte lui aussi sa réponse a de nouveaux use cases intégrant des devices

En attendant si vous avez besoin d’aller plus loin dans ce protocole, je vous invite a consulter les ressources suivantes qui m’ont aide a construire cet présent article : [6,7,8]