Acabei de configurar uma instância do Discourse e adicionei o discourse-openid-connect, conectando o Keycloak como provedor OIDC.
Após seguir as 3 condições mencionadas aqui com uma atualização recente, obtenho o comportamento de autenticação via Keycloak ou, se já estiver logado, ao clicar no botão “Login”, sou solicitado a “Criar Nova Conta” com os campos preenchidos com base nas informações do usuário provenientes do Keycloak.
Existe alguma maneira de pular essa etapa que exige uma ação adicional do usuário? Esses campos já são naturalmente preenchidos pelo Keycloak, então não deveria haver necessidade de o usuário modificá-los especificamente para o Discourse.
A criação da conta deveria ser tratada implicitamente, de forma semelhante ao que o Grafana consegue fazer? Meu objetivo é que cada serviço oferecido pela comunidade suporte essa experiência fluida, de modo que a conta original da comunidade, com a qual o usuário se cadastrou, seja tudo o que ele precise lidar.
Isso pode não fazer sentido se você estiver pensando em autenticação externa, como Google / Facebook / GitHub / etc. Um usuário pode registrar sua conta da comunidade via Keycloak usando um desses provedores, mas o próprio Keycloak, que é usado apenas internamente, é o que se destina a funcionar com todos os serviços individuais, sendo, portanto, desejável o consentimento e o cadastro implícitos/automatizados.
Sou novo no Discourse e configurei meu provedor SSO OAuth2, que já está funcionando. Novos usuários veem a tela de confirmação na primeira vez que acessam e se autenticam no Discourse. Como posso simplificar esse processo e fazer com que o usuário seja criado automaticamente? Os valores exibidos nessa tela estão corretos e são necessários apenas uma vez. O que posso fazer para eliminar essa tela e agilizar o processo de criação de contas para os usuários da minha comunidade?
Isso não é possível no momento. Quando os usuários criam uma conta pela primeira vez, precisarão clicar no botão “Criar Nova Conta” no formulário de cadastro.
O comportamento que você procura é semelhante ao da implementação de SSO do Discourse. Nesse caso, as contas são criadas em segundo plano, sem que o usuário preencha o formulário de cadastro. Parece ser possível implementar funcionalidade semelhante para logins via OAuth2, mas pode haver casos em que o provedor OAuth2 não transmite informações suficientes para criar uma conta.
Não dediquei muito tempo a isso desde meu post aqui, mas acabei optando pela funcionalidade de SSO do Discourse para usar um serviço de ponte que encontrei para OpenID-Connect. Era um serviço em Python com um container Docker, o que facilitou a implantação com minha configuração do docker-compose.
Então, o Keycloak já fornecia a conta registrada e logada; ao visitar o Discourse, o usuário era cadastrado com os detalhes fornecidos pela ponte, se bem me lembro. Faz algum tempo que não lido com isso, mas esse era um processo um pouco melhor do que o suporte nativo do Discourse a OAuth/OpenID-Connect, pelo que sei (pelo menos na época; não verifiquei se algo foi feito para melhorá-lo desde então).
De qualquer forma, você não obtém a sincronização dos detalhes da conta conforme o esperado. O usuário precisa sair do Discourse e fazer login novamente para que qualquer sincronização ocorra, e mesmo assim, acho que havia algumas coisas que não podiam ser sincronizadas do provedor de SSO para o Discourse (grupos/roles, algo assim, se bem me lembro, apresentava algumas armadilhas).
Acredito que você precisaria detectar quando os detalhes do usuário são atualizados no provedor para acionar a atualização no Discourse por meio de suas APIs, a fim de configurar uma sincronização adequada. Caso contrário, você pode ter detalhes duplicados que não estão sincronizados ou uma sincronização confusa para os usuários.
Então, hum, se a integração OAuth2 SSO que você tem atualmente não for a funcionalidade de SSO do Discourse (que geralmente requer uma ponte de SSO, pelo que sei), mas sim essa alternativa de plugin, mudar para a versão sem plugin com uma ponte de SSO deve proporcionar a experiência desejada que você procura, se bem me lembro.
Também estou interessado em evitar essa janela de “Criar Nova Conta” ao usar OAuth2.
Talvez seja possível adicionar uma opção em algum lugar para pulá-la se todos os campos já estiverem disponíveis?
Acabei de adicionar algumas novas configurações do site que ajudarão com isso. Para pular a tela ‘criar nova conta’, ative sso_overrides_username, sso_overrides_email e sso_overrides_name.
Em seguida, para pular completamente o popup, ative external_auth_skip_create_confirm.
Se você não vir essa opção, certifique-se de estar na versão mais recente do tests-passed.
Já existe uma conta criada test__EMAIL__ no nosso Discourse.
Se eu fizer login com OpenID e o nome de usuário: test, e-mail: test__EMAIL__,
aparece uma janela de “Nova conta” pedindo um novo nome de usuário test1 e e-mail test__EMAIL__.
O seu provedor de OpenID Connect verifica os e-mails dos usuários? Só podemos ‘confiar’ no e-mail do OIDC se ele tiver sido verificado e o booleano de verificação estiver definido corretamente.
Sem provedor OID - Keycloak com federação de usuários LDAP
Encontramos a solução: o usuário antigo pode conectar o OpenID na interface de configurações do usuário.
@david, temos a versão 2.5.2 estável — essa opção está ausente… É possível migrar essa opção para a branch estável? Precisamos dela, mas não usamos nada em produção, exceto a branch estável…
Temo que não, não fazemos backport de novos recursos para a versão estável. Fique de olho em #releases para informações sobre quando a próxima versão estável será lançada.
