Plugin Openid-connect não consegue buscar configuração

SSO
1

Tenho tentado resolver este problema há algum tempo e não consigo. Estou tentando integrar o Discourse com uma configuração Keycloak para autenticação usando o plugin discourse-openid-connect. Estou executando a versão 3.0.1 do discourse-docker. No momento, ao clicar no botão de login do OpenID connect, esta mensagem aparece no Discourse: “Incapaz de buscar configuração do provedor de identidade. Por favor, tente novamente.”

Estou migrando para uma nova configuração do Discourse, e o engraçado é que o Discourse consegue alcançar a tela de login do Keycloak usando minha antiga instância Keycloak sem problemas, mas não consegue com a nova. Isso significa que o seguinte deve ser verdade:

  • As configurações do plugin openid-connect estão definitivamente corretas (copiadas do antigo Discourse)
  • As configurações do Keycloak para o cliente Discourse estão definitivamente corretas (copiadas do antigo Discourse)
  • Não há problema de rede
  • Não há firewall ou algo bloqueando o tráfego

Adicionalmente, descobri que consigo fazer curl na URL do documento de descoberta para o Keycloak a partir da instância do Discourse sem problemas. A versão do Keycloak é a mesma da antiga e a autenticação do Keycloak funciona bem para outras ferramentas localizadas na mesma região AWS e AZ que o Discourse. Abaixo está o erro dos logs quando tento fazer login usando o openid-connect.

Pesquisei e testei muito e nada funcionou. O erro sobre IPs não permitidos parece bastante genérico, e tenho quase certeza de que não há firewall bloqueando nada, especialmente porque consigo fazer curl no documento de descoberta sem problemas. Só consigo pensar que possivelmente o Discourse está tentando buscar o documento de algum cache ou não está atingindo a URL de token correta, mas simplesmente não sei. Qualquer ajuda seria apreciada.

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 curtida
2

Existe um patch de segurança que não permite o acesso a endereços em faixas privadas (10.0.0.0/8 e assim por diante) para evitar explorações de rede interna.

Você precisa adicionar o nome do host em Admin - Configurações - Segurança - allowed internal hosts para ignorar a verificação.
Teria sido bom se o plugin fizesse isso por você.

2 curtidas
4

Incrível! Então, se eu adicionar meu keycloak aqui, ele deve funcionar? Eu faria isso com a URL ou com o IP?

EDIT: Deixe pra lá, funcionou. Muito obrigado! Passei tanto tempo nisso e era uma solução tão simples.

2 curtidas
5

@joshml.extra que coincidência, estou enfrentando exatamente o mesmo problema com a integração Keycloak oidc e a solução que @RGJ deu é promissora. Eu tentei, mas funcionou apenas para um IP no meu caso um IP de pod Kubernetes.

@RGJ - É possível ter um DNS funcionando da mesma forma? No meu caso, é uma URL Nginx Ingress e vejo uma falha na verificação do certificado, pois tenho certificados assinados por uma CA interna no meu Nginx Controller. A URL do ingress se resolve para um IP privado.

Obrigado por este tópico!! Realmente aprecio isso :slightly_smiling_face:. Eu quase tinha desistido de encontrar uma solução para o nosso cenário air gapped.

6

Isso não parece ser um problema com seu IP privado. Afinal, se as coisas fossem bloqueadas por causa do IP privado, você nunca chegaria a uma falha na verificação do certificado?

7

Entendido! Faz sentido.

Obrigado pela explicação. Está funcionando bem para mim com um IP/nome de host.

8

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