Estou tentando obter uma compreensão mais clara das nossas opções para um projeto de reestruturação em que estou trabalhando. Tenho procurado nos fóruns para obter mais insights e, embora tenha encontrado uma consulta semelhante, o cenário do OP é um pouco diferente do nosso, então estou criando este tópico como novo.
Atualmente, temos um site WordPress em domain.com configurado como cliente SSO para a instância do Discourse em community.domain.com, mas o site do WP está sendo reorganizado como uma rede multisite, por exemplo, sub1.newdomain.com, sub2.newdomain.com, etc., e uma instância separada do Discourse para cada site, por exemplo, forum.sub1.newdomain.com (ou idealmente sub1.newdomain.com/forum, se conseguirmos resolver a configuração de subpasta).
Queremos que nossos usuários tenham uma única identidade em todas as comunidades e sabemos como sincronizar usuários que se registram em um subsite do WP em toda a rede. Entendo que uma instância do Discourse pode atuar como servidor SSO para outra, mas não consegui encontrar confirmação de como isso é configurado ou se isso funciona para múltiplos clientes do Discourse.
Então, vamos às minhas perguntas:
No cenário descrito, é possível configurar uma instância do Discourse em, digamos, auth.newdomain.com para atuar tanto como servidor SSO para a rede WPMS quanto para todas as instâncias do Discourse vinculadas aos subsites?
Se a resposta à pergunta anterior for sim, seria viável configurar essa instância “servidor” para fornecer apenas funcionalidades relacionadas à autenticação? Ou seja, ela não teria outro propósito além de ser a “fonte da verdade” de autenticação para toda a rede, independentemente de qual site o usuário deseja autenticar. Ou seria mais apropriado confiar em uma solução de autenticação externa neste ponto?
Olá – isso apareceu para mim já que você linkou ao meu tópico original. Vou deixar o @simon dar sua opinião, mas uma opção que pode ou não funcionar para você (e seria muito mais simples) é configurar uma única instância do Discourse e usar grupos para separar os fóruns. Você pode enviar informações do grupo no payload do SSO.
No entanto, ter vários fóruns com um único fornecendo SSO deve ser bastante direto (embora eu não tenha tentado antes). Acredito que os passos seriam:
Adicionar o plugin WP Discourse e configurá-lo como um cliente SSO (nas opções de rede)
Configurar o fórum Discourse que você deseja que funcione como provedor de SSO (adicionar chaves secretas ao WP + Discourse, etc.)
A partir daí, ao adicionar fóruns subsequentes, eles seriam configurados como clientes SSO (e como o WP Discourse está configurado no nível da rede, você não precisaria alterar nenhuma configuração ao adicionar novos sites).
Muito obrigado por compartilhar suas sugestões, @jakeols. Sei que os grupos são a alternativa mais frequentemente sugerida, mas não se encaixam no nosso caso de uso específico.
Espero que @simon possa oferecer algumas informações sobre o que é ou não possível aqui.
É possível usar o Discourse como provedor de SSO em uma rede multisite. Ele só é ativado se você configurar um único site do Discourse como provedor de SSO para todos os sites da rede. A razão para isso é que, em uma rede multisite, todos os usuários são armazenados em uma única tabela de banco de dados. Se múltiplos sites do Discourse forem permitidos como provedores de SSO para vários sites de uma rede, não há uma maneira direta de garantir que os IDs de usuário do Discourse salvos no WordPress sejam únicos.
Quando o plugin WP Discourse é instalado em uma rede multisite, uma aba do Discourse é adicionada ao menu de Administração da Rede. Para configurar o Discourse como provedor de SSO para todos os sites da rede, acesse a página de Administração da Rede e selecione Discourse no menu. Selecione a opção ‘Ativar Configuração Multisite’ e preencha as Configurações de Conexão. Em seguida, role a página até a seção Configurações de SSO. Selecione a opção ‘Ativar Cliente SSO’. Insira sua Chave Secreta de SSO e salve a página de configurações.
Uma coisa a ter em mente é que ativar a funcionalidade de Cliente SSO em uma rede multisite pode potencialmente conceder acesso a qualquer usuário do seu fórum Discourse a qualquer site da sua rede.
Essencialmente, se você está tentando realizar algo diferente disso ao usar o Discourse como provedor de SSO para uma rede multisite do WordPress, você estará por conta própria. Seria tecnicamente possível permitir que múltiplos sites do Discourse funcionem como provedores de SSO para sites individuais em uma rede do WordPress, mas a configuração necessária para isso seria excessivamente complexa. Não acredito que isso seja algo que será adicionado ao plugin do WordPress.
Muito obrigado pela sua resposta. O post que você citou foi exatamente o que eu mencionei no meu post original. Não tenho realmente nenhum problema do lado do WordPress — sabemos como fazer a conexão no nível da rede e, em seguida, sincronizar os usuários em todos os subsites. O que estou tentando entender é como podemos configurar um Discourse para servir como servidor SSO para outro? Eu estava tentando esclarecer se é possível fazer isso enquanto o Discourse de “autenticação” também atua como servidor SSO para o WordPress ao mesmo tempo.
Não consegui encontrar nenhuma documentação sobre a configuração Discourse-Discourse. Se você puder me indicar onde encontrar mais informações ou apenas descrever os passos necessários, ficaria extremamente grato.
Entendo seu ponto de vista, mas o Discourse não foi projetado para ser usado exclusivamente para fins de autenticação. Sugiro que dedique algum tempo a considerar um serviço de autenticação dedicado, ao qual você conectaria suas várias instâncias do Discourse e do Wordpress. Um pequeno investimento em pesquisa agora pode valer a pena no futuro.
No entanto, meu principal conselho é que o que você está propondo é complexo, e independentemente do caminho que escolher, é necessário configurar um ambiente de staging que espelhe seu ambiente de produção pretendido para experimentar diferentes configurações antes de implementá-lo. Esse tipo de configuração pode ser afetado por várias variáveis diferentes, e é difícil dar conselhos sobre isso de forma abstrata.
Sei que a ideia de configurar um ambiente de staging completamente separado para uma rede interconectada de servidores pode parecer trabalhosa, mas o trabalho envolvido nisso é muito menor do que tentar resolver problemas imprevistos que surgem depois de lançar algo assim.
Sim, reconheço que o Discourse não é um serviço de autenticação puro. Estamos considerando três opções potenciais:
Usar o Discourse como nosso provedor de identidade
Usar o WordPress como nosso provedor de identidade
Usar um provedor de identidade externo (SaaS ou auto-hospedado)
Cada uma dessas opções apresenta implicações diferentes em termos de custo, complexidade e experiência do usuário (UX), que estamos buscando avaliar, daí minhas perguntas aqui.
Não, você tem 100% de razão, é complexo e nem cogitaríamos implantar isso sem testar primeiro em um ambiente de staging. Muito obrigado pela explicação, foi muito apreciado!
