Isto é ótimo, muito melhor que o plugin oauth2, que não funcionava. Mas este funciona (com Keycloak).
No entanto, múltiplas fontes oidc seriam um recurso muito bem-vindo.
Essa é uma ideia interessante. Você pode nos contar mais sobre seu caso de uso para explicar os benefícios e, se possível, quais fontes de login você gostaria de usar?
Respondendo à pergunta na publicação nº 2 acima: nosso caso de uso e quais fontes de login precisamos.
Operamos um fórum de comunidade público para uma iniciativa de pesquisa da UE, em hospedagem gerenciada do Discourse dentro da UE.
Precisamos que dois provedores OIDC estejam habilitados simultaneamente:
- EU Login, o provedor de identidade da Comissão Europeia. É utilizado por funcionários da Comissão, partes interessadas em políticas públicas e participantes de projetos financiados pela UE. É OIDC padrão, com seu documento de descoberta em
https://ecas.ec.europa.eu/cas/oauth2/.well-known/openid-configuration. - EGI Check-in, um proxy de identidade acadêmica federada que atua como front para contas institucionais e ORCID. É utilizado em toda a infraestrutura de pesquisa europeia. Também é OIDC padrão.
Nenhum dos dois cobre os usuários do outro. Um oficial de políticas faz login com o EU Login e não possui uma identidade de pesquisa institucional. Um pesquisador faz login com uma conta universitária ou com ORCID através do nosso proxy e não possui EU Login. Nossa comunidade é composta por ambos os grupos, portanto, escolher um único provedor significa afastar metade das pessoas para quem o fórum foi criado.
Ambos os provedores utilizam OIDC comum, e qualquer um deles funciona isoladamente. O que nos impede é que o discourse-openid-connect expõe um único namespace de configurações sem numeração: openid_connect_client_id, em vez de openid_connect_1_client_id e openid_connect_2_client_id. Apenas um provedor OIDC pode ser configurado por site.
Gostaríamos de suporte para mais de um provedor. A forma mais natural seria um namespace de configurações por provedor, seja por configurações numeradas ou por uma lista gerenciada pelo administrador, onde cada provedor tenha seu próprio documento de descoberta, credenciais de cliente, escopo e título do botão.
Há trabalho anterior em Multiple openid-connect authentication providers, de 2021, onde a necessidade era de vários reinos Keycloak. Essa é a mesma limitação em uma forma diferente.
Podemos fornecer mais informações, se necessário, ou testar implementações, se isso puder ajudar.
1 curtida
Uma coisa que você poderia tentar é configurar um serviço Authentik e “federar” com esses dois provedores. Dessa forma, você poderia ter SSO interno para sua equipe e SSO proxied para usuários externos. Seria um pouco mais difícil, considerando a necessidade de hospedar seu próprio SSO, mas talvez mais rápido do que ter o plugin OIDC corrigido, dependendo da sua capacidade.
Dito isso, vejo configurações de (Corporate Login Provider) em todos os lugares nas configurações do Discourse, então seria realmente bom poder adicionar o nosso. Talvez forking o plugin OIDC e mudando os nomes?
4 curtidas
Obrigado pela dica. O serviço EGI Check-in já é um proxy de IdP, permitindo o uso de muitos IdPs.
A restrição atual é que a política do EU Login não permite o uso de proxy. Eles desejam uma conexão direta com o serviço.
1 curtida
Nesse caso, se o outro puder usar OAuth2, você pode configurá-lo com Discourse OAuth2 Basic, assim você pode manter o OIDC para a EU EIDAS. Havia também um plugin SAML, mas talvez ele tenha sido descontinuado.
2 curtidas
Obrigado pela sugestão. De fato, estamos atualmente explorando o uso do Discourse OAuth2 Basic com o EGI Check-in.
Quis trazer este caso à atenção da comunidade, pois a possibilidade de suportar múltiplos provedores OIDC provavelmente beneficiará mais organizações no futuro e facilitará as coisas.
A opção SAML não estava no nosso radar; talvez seja uma terceira opção a ser considerada. Encontrei o plugin: GitHub - discourse/discourse-saml: Support for SAML in Discourse · GitHub
2 curtidas