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.