Le plugin Openid-connect ne peut pas récupérer la configuration

SSO
1

J’essaie de résoudre ce problème depuis un moment et je n’arrive pas à le résoudre. J’essaie d’intégrer Discourse avec une configuration Keycloak pour l’authentification à l’aide du plugin discourse-openid-connect. J’utilise la version 3.0.1 de discourse-docker. Actuellement, lorsque je clique sur le bouton de connexion OpenID Connect, le message suivant s’affiche dans Discourse : « Impossible de récupérer la configuration du fournisseur d’identité. Veuillez réessayer. »

Je migre vers une nouvelle configuration Discourse, et le plus drôle, c’est que Discourse parvient à atteindre l’écran de connexion Keycloak en utilisant mon ANCIENNE instance Keycloak sans problème, mais pas avec ma NOUVELLE. Cela signifie que les points suivants devraient être vrais :

  • Les paramètres du plugin openid-connect sont corrects (copiés de l’ancien Discourse)
  • Les paramètres Keycloak pour le client Discourse sont corrects (copiés de l’ancien Discourse)
  • Il n’y a aucun problème réseau
  • Il n’y a pas de pare-feu ou quoi que ce soit qui bloque le trafic

J’ai en outre constaté que je peux curl avec succès l’URL du document de découverte pour Keycloak depuis l’instance Discourse sans problème. La version de Keycloak est la même que l’ancienne, et l’authentification Keycloak fonctionne bien pour d’autres outils situés dans la même région AWS et la même zone de disponibilité que Discourse. Voici l’erreur des journaux lorsque j’essaie de me connecter en utilisant OpenID Connect.

J’ai fait des recherches et testé beaucoup de choses, mais rien n’a fonctionné. L’erreur concernant les IP non autorisées semble assez générique, et je suis presque certain qu’aucun pare-feu ne bloque quoi que ce soit, d’autant plus que je peux curl le document de découverte sans problème. Je ne peux que penser que Discourse essaie peut-être de récupérer le document à partir d’un cache quelque part ou qu’il n’atteint pas la bonne URL de jeton, mais je ne sais tout simplement pas. Toute aide serait appréciée.

Started GET "/session/csrf" for <my_ip> at 2023-02-01 18:02:24 +0000
Processing by SessionController#csrf as JSON
Completed 200 OK in 2ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 406)
Started POST "/auth/oidc" for 10.158.133.85 at 2023-02-01 18:02:24 +0000
(oidc) Setup endpoint detected, running now.
OIDC Log: Fetching discovery document from https://<keycloak_URL>.com/auth/realms/<my_realm>/.well-known/openid-configuration
OIDC Log: Fetching discovery document raised error Faraday::ConnectionFailed FinalDestination: all resolved IPs were disallowed
OIDC Log: Discovery document is

---

(oidc) Request phase initiated.
(oidc) Authentication failure! openid_connect_discovery_error: OmniAuth::OpenIDConnect::DiscoveryError, Discovery document is missing
Started GET "/auth/failure?message=openid_connect_discovery_error&strategy=oidc" for <my_ip> at 2023-02-01 18:02:24 +0000
Processing by Users::OmniauthCallbacksController#failure as HTML
  Parameters: {"message"=>"openid_connect_discovery_error", "strategy"=>"oidc"}
  Rendered users/omniauth_callbacks/failure.html.erb within layouts/no_ember (Duration: 0.1ms | Allocations: 17)
  Rendered layout layouts/no_ember.html.erb (Duration: 17.3ms | Allocations: 5113)
Completed 200 OK in 24ms (Views: 19.7ms | ActiveRecord: 0.0ms | Allocations: 6610)
1 « J'aime »
2

Il y a un correctif de sécurité qui interdit de contacter des adresses dans les plages privées (10.0.0.0/8 et ainsi de suite) pour empêcher l’exploration du réseau interne.

Vous devez ajouter le nom d’hôte dans Admin - Paramètres - Sécurité - allowed internal hosts pour contourner la vérification.
Il aurait été agréable que le plugin le fasse pour vous.

2 « J'aime »
4

Génial ! Donc si j’ajoute ma clé d’authentification ici, cela devrait fonctionner ? Est-ce que je devrais le faire avec l’URL ou avec l’adresse IP ?

EDIT : Laissez tomber, ça a fonctionné. Merci beaucoup ! J’ai passé tellement de temps là-dessus et c’était une solution si simple.

2 « J'aime »
5

@joshml.extra quelle coïncidence, j’ai exactement le même problème avec l’intégration Keycloak oidc et la solution que @RGJ a donnée est prometteuse. Je l’ai essayée, mais elle n’a fonctionné que pour une IP, dans mon cas une IP de pod Kubernetes.

@RGJ - Est-il possible d’avoir un DNS qui fonctionne de la même manière ? Dans mon cas, il s’agit d’une URL Nginx Ingress et je vois un échec de vérification de certificat car j’ai des certificats signés par une CA interne sur mon contrôleur Nginx. L’URL d’ingress se résout en une adresse IP privée.

Merci pour ce sujet !! Je l’apprécie vraiment :slightly_smiling_face:. J’avais presque abandonné à trouver une solution pour notre scénario air gapped.

6

Cela ne semble pas indiquer que votre problème est une adresse IP privée. Après tout, si les choses étaient bloquées à cause de l’adresse IP privée, vous n’arriveriez jamais à un échec de vérification du certificat ?

7

Compris ! C’est logique.

Merci pour l’explication. Cela fonctionne bien pour moi avec une IP / un nom d’hôte.

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.