C’est super, bien mieux que le plugin oauth2, qui ne fonctionnait pas. Mais celui-ci fonctionne (avec Keycloak).
Cependant, plusieurs sources oidc seraient une fonctionnalité très appréciée.
C’est une idée intéressante. Pouvez-vous nous en dire plus sur votre cas d’utilisation pour expliquer les avantages, et si possible, quelles sources de connexion vous aimeriez utiliser ?
En réponse à la question du message n° 2 ci-dessus : notre cas d’usage et les sources de connexion dont nous avons besoin.
Nous exploitons un forum communautaire public pour une initiative de recherche de l’UE, hébergé sur une solution Discourse managée au sein de l’UE.
Nous devons activer simultanément deux fournisseurs OIDC :
- EU Login, le fournisseur d’identité de la Commission européenne. Il est utilisé par le personnel de la Commission, les parties prenantes en matière de politique et les participants aux projets financés par l’UE. Il s’agit d’OIDC standard, avec son document de découverte situé à
https://ecas.ec.europa.eu/cas/oauth2/.well-known/openid-configuration. - EGI Check-in, un proxy d’identité académique fédéré qui met en avant les comptes institutionnels et ORCID. Il est utilisé dans l’ensemble des infrastructures de recherche européennes. Là encore, il s’agit d’OIDC standard.
Aucun des deux ne couvre les utilisateurs de l’autre. Un responsable politique se connecte via EU Login et ne dispose pas d’identité de recherche institutionnelle. Un chercheur se connecte avec un compte universitaire ou via ORCID à travers notre proxy et ne possède pas de compte EU Login. Notre communauté est composée des deux groupes, si bien que choisir un fournisseur unique reviendrait à exclure la moitié des personnes pour lesquelles le forum est destiné.
Les deux fournisseurs utilisent l’OIDC ordinaire, et chacun fonctionne indépendamment. Ce qui nous bloque, c’est que discourse-openid-connect expose un seul espace de noms de paramètres non numéroté : openid_connect_client_id, au lieu de openid_connect_1_client_id et openid_connect_2_client_id. Un seul fournisseur OIDC peut être configuré par site.
Nous souhaiterions un support pour plusieurs fournisseurs. La forme la plus naturelle serait un espace de noms de paramètres par fournisseur, soit des paramètres numérotés, soit une liste gérée par un administrateur, où chaque fournisseur aurait son propre document de découverte, ses identifiants de client, son périmètre (scope) et le titre de son bouton.
Il existe un antécédent antérieur dans Multiple openid-connect authentication providers de 2021, où le besoin concernait plusieurs domaines (realms) Keycloak. Il s’agit de la même limitation sous une forme différente.
Nous pouvons fournir plus d’informations si nécessaire, ou tester des implémentations si cela peut aider.
1 « J'aime »
Une chose que vous pourriez essayer est de configurer un service Authentik et de le « fédérer » avec ces deux fournisseurs. De cette manière, vous pourriez disposer d’un SSO interne pour votre équipe et d’un SSO proxifié pour les utilisateurs externes. Ce serait un peu plus compliqué, compte tenu de la nécessité d’héberger votre propre SSO, mais peut-être plus rapide que de faire appliquer un correctif au plugin OIDC, selon vos capacités.
Cela dit, je vois des paramètres (Corporate Login Provider) partout dans les paramètres de Discourse, il serait donc effectivement agréable de pouvoir ajouter les nôtres. Peut-être en forkeant le plugin OIDC et en changeant les noms ?
4 « J'aime »
Merci pour l’astuce. Le service EGI Check-in est déjà un proxy IdP permettant l’utilisation de nombreux IdP.
La contrainte actuelle est que la politique EU Login n’autorise pas l’utilisation d’un proxy. Ils souhaitent une connexion directe avec le service.
1 « J'aime »
Dans ce cas, si l’autre service prend en charge OAuth2, vous pouvez le configurer via Discourse OAuth2 Basic, afin de conserver OIDC pour l’UE EIDAS. Il existait également un plugin SAML, mais il a probablement été déprécié.
2 « J'aime »
Merci pour la suggestion. En effet, nous explorons actuellement l’utilisation de Discourse OAuth2 Basic avec EGI Check-in.
Je souhaitais porter ce cas à l’attention de la communauté, car la possibilité de prendre en charge plusieurs fournisseurs OIDC profitera probablement à davantage d’organisations à l’avenir et simplifiera les choses.
L’option SAML n’avait pas été envisagée, elle pourrait constituer une troisième option à considérer. J’ai trouvé le plugin suivant : GitHub - discourse/discourse-saml: Support for SAML in Discourse · GitHub
2 « J'aime »