정말 좋습니다. 작동하지 않던 oauth2 플러그인보다 훨씬 낫습니다. 이 방식은 (Keycloak와 함께) 잘 작동합니다.
다만, 여러 oidc 소스를 지원하는 기능은 정말 환영할 만한 일이 될 것입니다.
흥미로운 아이디어네요. 장점을 설명하고, 가능하다면 어떤 로그인 소스를 사용하시길 원하시는지 사용 사례에 대해 좀 더 자세히 알려주실 수 있을까요?
위 2번 게시물의 질문에 대한 답변: 우리의 사용 사례와 필요한 로그인 소스에 대해 말씀드리겠습니다.
우리는 EU 연구 이니셔티브를 위한 공개 커뮤니티 포럼을 운영 중이며, EU 내부의 매니지드 Discourse 호스팅 환경에서 서비스를 제공합니다.
동시에 두 개의 OIDC 제공자를 활성화해야 합니다:
- EU Login: 유럽연합 집행위원회의 신원 제공자입니다. 집행위원회 직원, 정책 이해관계자, EU 자금 지원 프로젝트 참여자들이 사용합니다. 표준 OIDC를 사용하며, discovery 문서 위치는
https://ecas.ec.europa.eu/cas/oauth2/.well-known/openid-configuration입니다. - EGI Check-in: 기관 계정과 ORCID를 프론트하는 연방 학술 신원 프록시입니다. 유럽 연구 인프라 전반에서 사용됩니다. 이 역시 표준 OIDC를 사용합니다.
두 제공자 중 어느 하나도 상대방의 사용자를 커버하지 못합니다. 정책 담당자는 EU Login으로 로그인하지만 기관 연구 신원이 없으며, 연구자는 프록시를 통해 대학 계정이나 ORCID로 로그인하지만 EU Login이 없습니다. 우리의 커뮤니티는 이 두 그룹 모두로 구성되어 있으므로, 단일 제공자만 선택하면 포럼의 대상인 사람들의 절반을 배제하게 됩니다.
두 제공자 모두 일반 OIDC 프로토콜을 따르며, 각각 단독으로 작동합니다. 우리를 막아서는 것은 discourse-openid-connect 플러그인이 단일의, 번호가 매겨지지 않은 설정 네임스페이스(openid_connect_client_id)를 노출한다는 점입니다. 즉, openid_connect_1_client_id와 openid_connect_2_client_id와 같이 구분되지 않습니다. 따라서 사이트당 OIDC 제공자를 하나만 구성할 수 있습니다.
우리는 둘 이상의 제공자에 대한 지원을 원합니다. 가장 자연스러운 형태는 제공자별 설정 네임스페이스일 것입니다. 이는 번호가 매겨진 설정 또는 관리자 관리 목록으로, 각 제공자마다 고유한 discovery 문서, 클라이언트 자격 증명, 스코프, 버튼 제목을 가질 수 있어야 합니다.
2021년에 게시된 Multiple openid-connect authentication providers라는 이전 사례가 있습니다. 당시에는 여러 Keycloak 리얼姆에 대한 필요성이 있었습니다. 이는 다른 형태로 나타난 동일한 한계입니다.
필요한 경우 추가 정보를 제공하거나, 도움이 된다면 구현 테스트를 수행할 수 있습니다.
1개의 좋아요
시도해 볼 수 있는 한 가지 방법은 이 두 제공자를 사용하여 Authentik 서비스를 설정하고 "연동"하는 것입니다. 이렇게 하면 팀을 위한 내부 SSO와 외부 사용자를 위한 프록시 SSO를 모두 사용할 수 있습니다. 자체 SSO를 호스팅해야 하는 필요성 때문에 다소 복잡할 수 있지만, 용량에 따라 OIDC 플러그인을 패치하는 것보다 빠를 수 있습니다.
그럼에도 불구하고, Discourse 설정 어디에나 (기업 로그인 제공자) 설정을 볼 수 있으므로, 우리만의 제공자를 추가할 수 있다면 좋겠습니다. OIDC 플러그인을 포크하고 이름을 변경하는 방식이 어떨까요?
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
3개의 좋아요