Openid-connect plugin can't fetch configuration

I’ve been trying to figure this out for a while and can’t seem to resolve this issue. I’m trying to integrate discourse with a Keycloak setup for authentication using the discourse-openid-connect plugin. I’m running the discourse-docker version 3.0.1. Right now when clicking the OpenID connect login button, this message pops up in discourse: “Unable to fetch configuration from identity provider. Please try again.”

I’m migrating to a new discourse setup, and the funny thing is, discourse is able to reach the Keycloak login screen using my OLD keycloak instance just fine, but can’t with my new one. This means the following should be true:

  • openid-connect plugin settings are definitely correct (copied from old discourse)
  • keycloak settings for the discourse client are definitely correct (copied from old discourse)
  • there is no networking issue
  • there is no firewall on or anything blocking traffic

I’ve additionally found I can successfully curl the discovery document URL for keycloak from the discourse instance just fine. Keycloak version is the same as the old one, and keycloak authentication works fine for other tools located in the same AWS region and AZ as discourse. Below is the error from the logs when I try to login using openid-connect.

I’ve done research and tested so much and nothing has worked. The error about disallowed IPs seems pretty generic, and I’m almost certain there is no firewall blocking anything, especially since I can curl the discovery document just fine. I can only think that possibly discourse is trying to pull the document from a cache somewhere or is not hitting the right token URL, but I just don’t know. Any help would be appreciated.

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 Like

There is a security patch that disallows reaching out to addresses in the private ranges (10.0.0.0/8 and so on) to prevent internal network explorations.

You need to add the hostname to Admin - Settings - Security - allowed internal hosts to bypass the check.
It would have been nice if the plugin did that for you.

2 Likes

Awesome! So if I add my keycloak into here then it should work? Would I be doing this with the URL or with the IP?

EDIT: Nevermind, this worked. Thank you so much! I’ve spent so much time on this and it was such a simple solution.

2 Likes

@joshml.extra what a coincidence I am facing exactly
the same problem with Keycloak oidc integration and the solution which @RGJ has given is promising. I have tried it, but it only worked for an IP in my case a Kubernetes pod IP.

@RGJ - Is it possible to have a DNS work the same way ? In my case it’s an Nginx Ingress URL and I see a certificate verification failure as I have an internal CA signed certs on my Nginx Controller. The ingress URL resolves to a private IP.

Thank you for this topic!! Really appreciate it :slightly_smiling_face:. I had almost given up finding a solution for our air gapped scenario.

This does not sound as if your issue is a private IP. After all, if things got blocked because of the private IP, you would never get as far as a certificate verification failure?

Got it! Makes sense.

Thanks for the explanation. It’s working well for me with an IP / hostname.

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