위 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 리얼姆에 대한 필요성이 있었습니다. 이는 다른 형태로 나타난 동일한 한계입니다.
필요한 경우 추가 정보를 제공하거나, 도움이 된다면 구현 테스트를 수행할 수 있습니다.