Ativei o SSO no site Discourse da nossa empresa, permitindo que usuários externos do nosso aplicativo façam login. No entanto, alguns membros da equipe com endereços de e-mail corporativos precisam de acesso como moderadores ou administradores. Como esses membros da equipe não estão registrados no aplicativo, não podemos criar contas SSO para eles.
Existe uma solução integrada para lidar com o login deles separadamente, para que possam se autenticar usando seu e-mail corporativo, mesmo com o SSO ativado para usuários externos?
Mas, que eu saiba, isso só funciona para administradores, certo? Quero fazer login para funcionários e moderadores, ou seja, usuários com privilégios, mas não administradores.
Se eu entendi o que você está dizendo, então você não pode usar sso. O primeiro S é para single (único). Você precisará usar múltiplos logins OAuth2, eu acho.
Por que seus administradores não podem usar seu sistema de autenticação?
Não tenho uma solução, mas lembro-me de que essa questão exata surgiu algumas vezes no passado. É lamentável que você não possa tornar os usuários moderadores e dar-lhes acesso ao site pela rota /u/admin-login.
Caso seja relevante, o que você está usando para SSO? É DiscourseConnect, OAuth2 ou OpenID Connect?
Queremos que nossos administradores, funcionários e moderadores usem seus e-mails corporativos para fazer login. No entanto, nosso mecanismo atual de SSO depende de autenticação baseada em OTP por número de telefone, e o usuário deve estar registrado em nosso aplicativo com seu ID de e-mail, o que não é viável para esses usuários.
Embora pudéssemos implementar um tratamento personalizado para colocar certos e-mails em uma lista de permissões em nosso SSO, estamos explorando uma solução mais pronta para uso. Por exemplo, se fosse possível o SSO coexistir com o login local, poderíamos desabilitar o login local para usuários regulares, enquanto permitimos que administradores e usuários externos façam login com seu e-mail e senha. Infelizmente, não acredito que o SSO e o login local possam coexistir dessa forma.
Isso está correto. Quando o DiscourseConnect está habilitado, os usuários só podem fazer login através do site provedor de autenticação DiscourseConnect.
Tive a ideia de que a rota /u/admin-login funcionava para toda a equipe (administradores e moderadores), mas olhando agora, vejo que ela só permite que administradores ignorem os logins do DiscourseConnect. Possivelmente um plugin poderia ser desenvolvido que permitiria que membros de um grupo personalizado fizessem login com o método admin-login, mas provavelmente seria melhor encontrar uma maneira de colocar usuários externos no seu site de autenticação SSO.
Isso parece certo. A melhor solução seria fazer com que seu sso funcione. Não faz muito sentido que não seja “viável” que seu sso não funcione para seus funcionários, mas talvez seja por isso que eu trabalho sozinho. (Mas seus funcionários não usam seu aplicativo? Se usassem, deveria ser fácil o suficiente adicionar o endereço de e-mail deles com a API).
Mas as pessoas que tomam más decisões são quem me mantém no negócio! Quando não estou convencendo as pessoas a usar recursos existentes, o que eu realmente gosto de fazer é fazer o discourse fazer coisas para as quais não foi projetado (como instalar discourse).
Ficarei feliz em desenvolver, ou ajudá-lo a desenvolver, um plugin que faria a rota /u/admin-login (ou outra) funcionar para membros de sua equipe (que inclui automaticamente usuários com seu e-mail corporativo) e criaria uma página que eles poderiam visitar e inserir seu e-mail para obter um link de login.
Talvez pudesse até redirecionar usuários anônimos em sua vpn para a página de login automaticamente ou algo mais para torná-lo mais transparente para seus funcionários.
(Mas seus funcionários não usam seu aplicativo? Se usassem, deveria ser fácil o suficiente adicionar o endereço de e-mail deles com a API).