Ich versuche schon seit einiger Zeit, dieses Problem zu lösen, und es scheint mir nicht zu gelingen. Ich versuche, Discourse mit einer Keycloak-Einrichtung für die Authentifizierung über das discourse-openid-connect-Plugin zu integrieren. Ich verwende die discourse-docker-Version 3.0.1. Wenn ich derzeit auf die Schaltfläche “OpenID Connect Login” klicke, erscheint in Discourse folgende Meldung: “Unable to fetch configuration from identity provider. Please try again.”
Ich migriere zu einer neuen Discourse-Einrichtung, und das Seltsame ist, dass Discourse über meine ALTE Keycloak-Instanz problemlos auf den Keycloak-Login-Bildschirm zugreifen kann, aber nicht mit meiner neuen. Das bedeutet, dass Folgendes zutreffen sollte:
- Die OpenID Connect-Plugin-Einstellungen sind definitiv korrekt (kopiert von altem Discourse)
- Die Keycloak-Einstellungen für den Discourse-Client sind definitiv korrekt (kopiert von altem Discourse)
- Es gibt kein Netzwerkproblem
- Es gibt keine Firewall oder etwas, das den Datenverkehr blockiert
Ich habe zusätzlich festgestellt, dass ich die Discovery-Dokument-URL für Keycloak von der Discourse-Instanz aus erfolgreich per curl abrufen kann. Die Keycloak-Version ist dieselbe wie die alte, und die Keycloak-Authentifizierung funktioniert für andere Tools, die sich in derselben AWS-Region und AZ wie Discourse befinden, einwandfrei. Nachfolgend finden Sie den Fehler aus den Protokollen, wenn ich versuche, mich über OpenID Connect anzumelden.
Ich habe recherchiert und so viel getestet, und nichts hat funktioniert. Die Fehlermeldung über nicht zulässige IPs scheint ziemlich generisch zu sein, und ich bin mir ziemlich sicher, dass keine Firewall etwas blockiert, besonders da ich das Discovery-Dokument per curl abrufen kann. Ich kann nur vermuten, dass Discourse möglicherweise versucht, das Dokument aus einem Cache abzurufen oder nicht die richtige Token-URL aufruft, aber ich weiß es einfach nicht. Jede Hilfe wäre willkommen.
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)
. Ich hatte fast aufgegeben, eine Lösung für unser Air-Gapped-Szenario zu finden.