Provisionar contas automaticamente com provedor de SSO externo? (pular o prompt de Criar Nova Conta)

I’ve just setup a Discourse instance and added the discourse-openid-connect to it, connecting Keycloak as the OIDC provider.

After following the 3 conditions stated here with a recent update, I get the behaviour to authenticate via Keycloak, or if already logged in, clicking the “Login” button will prompt me to “Create New Account” with the fields filled in sourced from Keycloak info on the user.

Is there a way to skip this part requiring an additional step from the user? These are fields are naturally already populated from Keycloak, so there shouldn’t be a need for the user to modify them specifically for Discourse.

The account creation should be handled implicitly, similar to how Grafana is able to do it? I am aiming for each service provided by the community to support this seamless experience, that the original community account that is signed-up is all they have to deal with.

This might not make sense if you’re thinking about external auth such as Google / Facebook / Github / etc. A user can register their community account via Keycloak with one of those, but Keycloak itself which is only used internally is what is intended to work with all the individual services, so implicit/automated consent and sign-up is desirable.

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.

external_auth_skip_create_confirm está ativado

Temos um problema:

  1. Já existe uma conta criada test__EMAIL__ no nosso Discourse.
  2. 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__.

E não há como conectar a conta antiga ao OpenID.

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.

@david
Não está totalmente claro sobre o que trata a próxima versão estável… Versão menor 2.5.3? Ou versão 2.6.0?

A próxima versão principal será a 2.6.0. Versões secundárias (2.5.x) serão lançadas apenas para correções de segurança.

@david
Obrigado! Agora está claro. O 2.6.0 será lançado este ano ou não? )))

Nós não temos uma data confirmada, mas sim, há uma boa chance de ser este ano :slight_smile: