J’ai donc essayé de trouver un plugin SSO qui me permettrait d’exploiter les revendications provenant de mon IdP pour mes utilisateurs Discourse.
Dans le plugin OIDC, vous êtes pratiquement limité au point de terminaison userinfo. Ce n’est pas mal, mais j’essayais d’utiliser d’autres informations de notre magasin d’identité et le résultat de userinfo ne peut pas être ajusté. J’avais essayé de forcer le plugin OIDC à utiliser id_token_info pour fabriquer l’utilisateur, mais sans succès.
Je suis revenu au plugin oauth, mais en surface, il semble avoir la même restriction de base, à savoir qu’il dépend des informations utilisateur d’un point de terminaison spécifique. J’essaie de trouver un plugin qui renvoie le contenu des revendications JWT, mais ce n’est pas vraiment un cas d’utilisation normal, donc je ne m’attends pas à grand-chose.
J’avais initialement pensé que les « chemins userinfo de rappel » sur l’oauth basic pouvaient être utilisés pour mapper les revendications à l’utilisateur, mais j’obtiens toujours des nulls dans la réponse et l’insertion échoue. Je peux décoder le jeton de l’IdP et voir les revendications correctes et dans ce cas à la racine du JSON comme iss, exp, etc., mais je ne peux pas les connecter au côté ActiveRecord.
Je regarde jwt mais il ne semble pas avoir le mappage des revendications à l’utilisateur du tout. Essentiellement, si vous obtenez un 200, vous êtes bon, ce qui n’est pas non plus ce que je cherchais.
Quelqu’un pourrait-il m’orienter vers un plugin actuellement maintenu pour mapper les revendications JWT à un utilisateur ou me dire où je pourrais me tromper avec l’un des plugins existants ?
À moins que je ne sois particulièrement lent aujourd’hui, il ne couvre que l’authentification avec des attributs fixes. Aucun moyen de faire un mappage de revendication que j’ai pu trouver. Si je devais forker quelque chose, ce serait probablement là que je commencerais, mais je voulais m’assurer que je ne manquais pas quelque chose d’évident.
Et pour ajouter un peu de contexte pour ceux qui tombent sur ce sujet.
Le plugin OAuth de base semble ne prendre en charge que l’extraction des attributs à partir d’un point de terminaison de données utilisateur défini et ne prend pas en charge le mappage des revendications JWT. Il est donc similaire au plugin OIDC, mais au lieu de l’emplacement des informations utilisateur fourni par le document de découverte, vous pouvez cibler n’importe quel point de terminaison JSON, puis mapper par chemin. En ajoutant les paramètres pour inclure l’authentification dans l’en-tête, vous pouvez accéder à des endroits comme https://graph.microsoft.com/v1.0/me que nous utilisons pour l’authentification OAuth basée sur Entra.
Maintenant, Entra ID offre une certaine extensibilité pour les objets principaux, mais ce n’est pas aussi simple que d’ajouter une revendication facultative et ce serait un changement global d’après ce que je vois. Je ne suis donc pas sûr que ce soit une option viable pour nous. En reculant encore plus sur le chemin de la maturité et en utilisant simplement le plugin JWT semble être la seule voie, mais cela nécessiterait un travail de PR pour ajouter la prise en charge du mappage des revendications. Essentiellement, de la même manière que le plugin oauth2-basic permet de personnaliser le mappage du champ Discourse à un attribut JSON, il faudrait permettre plus de personnalisation du champ aux revendications JWT.
C’est maintenant une voie possible pour nous, mais j’ai rencontré un problème différent qui, je pense, bloque tout.
Après avoir fait fonctionner le plugin oauth2-basic, il demande un nouvel utilisateur et constate qu’il existe déjà un utilisateur utilisant l’e-mail du compte existant du plugin OIDC. Même s’ils partagent le même attribut d’e-mail, je pense qu’il ne peut pas passer d’un fournisseur à l’autre pour le même utilisateur Discourse. Obliger tout le monde à recommencer n’est pas une option viable et bien que je puisse probablement pirater une migration d’un enregistrement de fournisseur OAuth à partir d’un fournisseur OIDC, cela me semble être une invitation aux ennuis. Donc, même si JWT avait la prise en charge du mappage des revendications, tous les utilisateurs existants sont liés au fournisseur OIDC sans quelques manipulations de base de données ou la création d’un gestionnaire d’« utilisateur existant » pour permettre le changement de compte associé, il semble que vous soyez bloqué.
C’est étrange. Il devrait correspondre à l’adresse e-mail et se connecter au même compte, semble-t-il. Les connexions oauth fonctionnent de cette façon.
J’espérais qu’ils se connecteraient soit en autorisant plus d’un enregistrement user_associated par utilisateur Discourse (par provider_id), soit par une invite de « liaison » pour permettre de passer d’un fournisseur à un nouveau. Cependant, lors de mes tests, ce n’était pas le cas et cela indique simplement que l’e-mail est utilisé et invite à créer un nouvel utilisateur.
Si je restais sur le même plugin, je suis sûr que ce serait transparent, mais dans ce cas, ce sont des provider_id uniques avec leurs propres métadonnées.