Une alternative temporaire à WebID-OIDC?

Projets SemApps
1

Il est clair que l’interopérabité que nous sommes en train de mettre en place avec SemApps aura un intérêt très limité tant que WebID-OIDC ne sera pas actif. En effet, les utilisateurs connectés sur une instance ne pourront pas modifier des données sur d’autres instances, sauf si les WebACL sont désactivés.

Etant donné que la plupart des projets actuels utilisent le SSO des Communs, une idée qui a émergé serait d’utiliser temporairement ce SSO, en y ajoutant le WebID de l’utilisateur (l’URL de son profil). Il suffirait, lors de la connexion, de vérifier si l’utilisateur a déjà un WebID attaché à son profil:

  • Si oui, on le considère comme un utilisateur distant. Les droits WebACL peuvent s’appliquer.
  • Si non, on crée un nouveau compte sur le serveur local, et on attache le WebID généré au profil de l’utilisateur.

La condition reste donc de pouvoir attacher un WebID à l’inscription. J’ai fait une heure ou deux de recherches hier sur ce sujet, car cela me tendait un peu. J’ai d’abord eu de bons espoirs, mais finalement je suis tombé sur ce post Stackoverflow qui indique que la mise à jour des données utilisateurs ne sont pas prévues dans la spec OIDC, mais qu’il faut passer par d’autres services ou par des implémentations spécifiques:

The userinfo endpoint should support GET and POST request methods, but they both just return information about a user. The specification doesn’t speak about the possibility to update the data.

An OpenID Connect server implementation can either keep the user data in its own storage or fetch it from a remote identity management system (IAM). So there can be an OpenID Connect server implementation specific endpoint for updating the user data or the IAM server can provide some API. In both cases you will probably need a special OAuth2 scope to perform the update.

C’est un peu déprimant cette complexité… :confused: Il y a pleins de choses qui semblent possibles via KeyCloak, il est même question de « federated identities », mais il est difficile de comprendre par où prendre la bête. Peut-être que @fluidlog aura plus de chances que moi sur ce sujet ? :slight_smile:

@balessan nous a expliqué que Startin’Blox était aussi passé par ces réflexions, mais qu’ils étaient finalement passé à WebID-OIDC parce qu’ils avaient découvert des limitations à ce système de SSO unique. Benoît, est-ce que tu as plus d’informations sur le sujet ? Peux-tu éventuellement pointer les autres membres de SIB sur cette discussion ?

2 « J'aime »
2

il me semble que « federated identities » c’est partager un annuaire type ldap ou un autre keycloak pour gérer les user. Ca permet d’avoir un seul référentiel de user pour plusieurs realms et plusieurs instance keycloak. ce n’est pas une authentification distribuée.

3

Attacher un webid dans les infos du user par API me parait effectivement la bonne piste et semble faisable. Par contre, je n’ai jamais trouvé le moyen de mettre des informations du user dans le tocken et c’est un prérequis.

4

J’ai trouvé comment mettre des données utilisateur dans le(s) token(s), ça s’appelle des « user claims », suivre ce tuto : jwt - add claims to access token keycloak - Stack Overflow.

Voici ce que ça donne :
image

On voit bien le webid retourné dans le token.

3 « J'aime »
5

Et pour modifier un user claim depuis l’API admin de Keycloak c’est ici : How to update custom attribute via Keycloak REST API - Stack Overflow.

J’ai testé ça fonctionne ! Mais avec un token d’admin. Je cherche si c’est possible avec un token de simple user.

1 « J'aime »
6

C’est super ça !! :smiley: :fireworks:

Ping @fluidlog

1 « J'aime »
7

bravo maxime!! Tu viens d’apporter une pierre précieuse à semapps!

2 « J'aime »
8

Super, du coup, ce serait cool d’avoir une présentation, ce qui nous permettrait de tous nous présenter, car on te connait assez peu @lecoqlibre :slight_smile:

1 « J'aime »
9

Ouais c’est cool ! C’est une bonne nouvelle, il me reste à vérifier qu’on peut modifier un user claim avec un user token.

1 « J'aime »
10

@Alice sera également intéressée par cette super nouvelle !

11

A priori KC ne prévoit pas la modification par API d’un attribut d’un simple utilisateur par lui même. J’ignore pourquoi. Je continue de creuser.

Pour l’instant, la seule API qui permet de le faire semble être l’API d’administration qui, comme son nom l’indique, est réservée aux administrateurs (dans ce cas précis, l’user qui fait la demande doit avoir le rôle manage_users).

Si c’est bien le cas, cela signifie que l’on ne pourrait pas attribuer directement depuis Semapps un webid à l’utilisateur qui s’enregistre sur le SSO pour le stocker dans un attribut utilisateur (user claim).

Par contre on peut facilement donner la possibilité à l’utilisateur de définir lui-même son webid dans un champ de formulaire prévu à cet effet au moment de son enregistrement sur le SSO (via la customisation du thème KC). Il est aussi possible de lui permettre de le modifier par la suite via la console de compte (account console).

Si on veut générer automatiquement un webid pour le stocker dans un user claim, il faudrait à première vue le faire depuis le SSO et là plusieurs solutions peuvent s’entrevoir : depuis le thème ou peut être en étendant le code de KC (qui est prévu pour).

1 « J'aime »
12

Ahah… je suis sur la piste d’une API non documentée pour autoriser un utilisateur à modifier son propre profil, c’est l’account_api qu’il faudrait activer dans un fichier .properties sur le serveur… Je vous tiens au courant !

BINGO ! Je viens de faire le test sur un Keycloak v15, il est possible de modifier un attribut utilisateur (user claim) via l’account_api avec un token utilisateur !

On peut donc modifier le profil d’un utilisateur par API avec son access token.

Donc on a tous les éléments pour gérer le webid sur le SSO !

A priori on pourrait l’activer sur le serveur des communs qui est en version 9 :

image

Testé sous Keycloak v9, ça fonctionne.

1 « J'aime »
13

C’est excellent tout ça @lecoqlibre ! :slight_smile:
La prochaine étape serait donc d’activer cette fonctionnalité sur le login des Communs. J’ai un accès administrateur, sans doute limité, et je ne vois pas l’option, tu peux dire où elle se trouve ? Ensuite il faudra demander aux responsables si on peut l’activer. Ping @simon.louvet.zen ?

1 « J'aime »
14

Maintenant que tout les feux sont au vert, il faudrait attendre que la V 0.4 soit stable et publié puis que @lecoqlibre implemente un authadapter si il est d’accord.

1 « J'aime »
15

Pas besoin d’attendre, on peut travailler sur la branche next sans souci. :slight_smile:
A priori il suffira d’adapter le AuthSsoMixin et le AuthOidcService, en ajoutant un setting à l’un ou à l’autre pour gérer ce type de configuration.

Par contre @simon.louvet.zen ce serait bien d’activer l’Account API sur les Communs pour que @lecoqlibre puisse travailler sur un serveur réel. Tu penses que tu peux voir ça ?

1 « J'aime »
16

D’apres ce que je comprends de ce que dit @lecoqlibre , c’est déjà fait

1 « J'aime »
17

Tu veux faire évoluer AuthOidcService ou en faire un autre?

1 « J'aime »
18

Effectivement l’API est bien en prod sur login.lescommuns.org, je viens de vérifier.

3 « J'aime »
19

Qui s’occupe d’implémenter l’authadapter ? Y’a une presta possible pour ça ? Est-ce qu’on définit un cahier des charges ou c’est plus ou moins libre ?

1 « J'aime »
20

Pour le financement il faudrait que @guillaume.rouyer @pierre ou @simon.louvet.zen se prononcent.

Je pense que ce serait plus efficace qu’on fasse une réunion en amont pour parler de l’implémentation. Je suis bien occupé avant Noël, mais je pourrai quand même y accorder 30 minutes lundi, mardi ou mercredi. Tu serais dispo aussi @simon.louvet.zen ? Pendant les vacances je travaillerai un peu mais l’horaire est incertain. Sinon après le 5 janvier.