This is great, much better than the oauth2 plugin, which didn’t work. But this one does (with Keycloak).
However multiple oidc sources would be a very welcome feature.
That’s an interesting idea. Can you tell us some more about your use case to explain the benefits, and if possible which login sources you would want to use?
Answering the question in post #2 above: our use case, and which login sources we need.
We run a public community forum for an EU research initiative, on managed Discourse hosting inside the EU.
We need two OIDC providers enabled at the same time:
- EU Login, the European Commission’s identity provider. It is used by Commission staff, policy stakeholders, and participants in EU-funded projects. Standard OIDC, with its discovery document at
https://ecas.ec.europa.eu/cas/oauth2/.well-known/openid-configuration. - EGI Check-in, a federated academic identity proxy that fronts institutional accounts and ORCID. It is used across the European research infrastructures. Also standard OIDC.
Neither one covers the other’s users. A policy officer signs in with EU Login and has no institutional research identity. A researcher signs in with a university account or with ORCID via our proxy and has no EU Login. Our community is made up of both groups, so picking a single provider means turning away half the people the forum is for.
Both providers speak ordinary OIDC, and either one works on its own. What stops us is that discourse-openid-connect exposes a single, un-numbered settings namespace: openid_connect_client_id, rather than openid_connect_1_client_id and openid_connect_2_client_id. Only one OIDC provider can be configured per site.
We would like support for more than one. The most natural form would be a per-provider settings namespace, either numbered settings or an admin-managed list, where each provider has its own discovery document, client credentials, scope, and button title.
There is earlier prior art in Multiple openid-connect authentication providers from 2021, where the need was several Keycloak realms. That is the same limitation in a different form.
We can provide more information if needed, or test implementations if that can help.
1개의 좋아요
One thing you could try is to setup an Authentik service and “federate” with these two providers. This way you could have internal SSO for your team, and proxied SSO for external users. Would be a bit harder, considering the need to host your own SSO, but maybe faster than having the OIDC plugin patched, depending on your capacity.
That said, I see (Corporate Login Provider) settings everywhere in Discourse settings, so it would indeed be nice to be able to add our own. Maybe forking the OIDC plugin and changing the names?
4개의 좋아요
팁을 알려 주셔서 감사합니다. EGI Check-in 서비스는 이미 여러 IdP를 사용할 수 있도록 허용하는 IdP 프록시입니다.
현재의 제약 사항은 EU Login 정책에서 프록시 사용을 허용하지 않는다는 것입니다. 그들은 해당 서비스와의 직접 연결을 원합니다.
1개의 좋아요
그 경우, 다른 쪽이 OAuth2를 지원할 수 있다면 https://meta.discourse.org/t/discourse-oauth2-basic/33879을 사용하여 설정할 수 있으므로 EU EIDAS용 OIDC를 유지할 수 있습니다. 이전에 SAML 플러그인도 있었는데, 비활성화되었을 수도 있습니다.
2개의 좋아요
제안 감사합니다. 실제로 현재 EGI Check-in과 함께 Discourse OAuth2 Basic을 사용하는 방안을 검토 중입니다.
OIDC 제공자 여러 개를 지원할 수 있게 되면 향후 더 많은 조직에 도움이 되고 업무가 훨씬 수월해질 것이라 생각되어 이 사례를 커뮤니티에 공유하고자 했습니다.
SAML 옵션은 아직 고려 대상이 아니었으며, 세 번째 옵션으로 검토해 볼 수 있을 것 같습니다. 해당 플러그인을 찾았습니다: GitHub - discourse/discourse-saml: Support for SAML in Discourse · GitHub
2개의 좋아요