아이덴티티 모델을 논할 때, B2B 제품은 고유한 범주에 속합니다. 이들은 멀티 테넌시의 복잡성을 탐색하면서, 다양한 서비스와 애플리케이션에서 직원 아이덴티티와 접근 관리의 통합을 요구하는 기업 클라이언트의 요구를 충족해야 합니다. Logto도 이러한 고객 요구에 직면한 경험이 있습니다. 이 글에서는 제품 중심의 접근 방식으로 SP-초기화 SSO를 이해하고, 이 시스템이 고객의 요구를 어떻게 충족시키는지 알아보겠습니다.
먼저 이해해야 할 몇 가지 주요 요소를 소개하겠습니다:
- 서비스 제공자 (SP): 하나의 아이덴티티 시스템을 공유하는 하나 이상의 앱이 될 수 있는 애플리케이션 또는 서비스.
- 엔터프라이즈 아이덴티티 제공자 (IdP): 직원 아이덴티티 및 애플리케이션 권한을 관리하기 위해 기업 클라이언트가 의존하는 아이덴티티 제공자. Okta, Azure AD, Google Workspace 또는 맞춤형 IdP를 사용할 수 있습니다.
- 서비스 제공자의 조직 (SP Org): B2B 앱은 종종 서로 다른 클라이언트 조직을 위한 멀티 테넌시를 지원합니다.
- 아이덴티티 제공자의 조직 (IdP Org): IdP도 서로 다른 클라이언트 조직을 위한 멀티 테넌시를 지원합니다. 이상적으로, 하나의 기업은 IdP Org를 SP Org에 연결하여 직원 아이덴티티를 복제할 수 있어야 하지만, 현실은 더 복잡할 수 있습니다.
- 엔터프라이즈 사용자 계정: 로그인에 회사 이메일 도메인을 사용하는 것으로 식별되는 사용자. 이 엔터프라이즈 이메일 계정은 결국 회사에 속합니다.
이어서 SSO와 두 가지 주요 프로토콜에 대해 다루겠습니다:
- 싱글 사인온 (SSO): SSO는 사용자가 하나의 자격 증명 세트를 사용하여 여러 서비스나 애플리케이션에 접근할 수 있게 합니다. 이는 접근 관리의 간소화와 보안 향상을 제공합니다.
- SAML 및 OIDC 프로토콜: SSO는 인증과 권한 부여를 위해 이 프로토콜에 의존하며, 각각 장단점이 있습니다.
고려해야 할 주요 SSO 트리거 메커니즘은 두 가지입니다:
- IdP-초기화 SSO: IdP-초기화 SSO에서 아이덴티티 제공자(IdP)가 싱글 사인온 프로세스를 주로 제어합니다. 사용자는 IdP의 인터페이스에서 인증을 시작합니다.
- SP-초기화 SSO: SP-초기화 SSO에서 서비스 제공자(SP)가 싱글 사인온 프로세스를 주도하고 관리하며, 이는 B2B 시나리오에서 자주 선호됩니다.
이제 SP-초기화 SSO를 자세히 살펴보겠습니다.
표면적 수준: 사용자 경험#
B2C 제품이 고정된 몇 개의 소셜 IdP 로그인 버튼을 제공할 수 있는 반면, B2B 제품은 각 고객이 사용하는 특정 엔터프라이즈 IdP를 지정할 수 없습니다. 따라서 사용자는 먼저 자신의 정체성을 선언해야 합니다. SSO가 활성화된 기업의 구성원이라는 것이 확인되면, 해당 기업 IdP로 리다이렉트되어 로그인하게 됩니다.
이를 달성하기 위해, 로그인 페이지에서 사용자가 SSO를 통해 로그인해야 하는지와 어느 IdP로 리다이렉션해야 하는지 확인해야 합니다. 일반적인 방법들은 다음과 같습니다:
- 이메일 도메인 매핑: 특정 IdP 커넥터와 이메일 도메인을 연결합니다. 이는 해당 도메인 아래의 이메일 주소를 가진 사용자에게 영향을 미칩니다. 악성 설정을 방지하기 위해 도메인 소유권 검증을 보장하세요.
- 조직 이름 매핑: 조직의 이름을 IdP 커넥터와 연결하고, 사용자가 자신의 조직 이름을 기억해야 하는 방식입니다.
- 사용자 개인 이메일 매핑: 이메일 도메인이나 조직 이름에 의존하지 않고도 특정 계정이 SSO를 사용할 수 있는지 직접 확인할 수 있습니다. 사용자 초대, 필수 SSO 규칙 사용자화, 또는 디렉토리 동기화를 통해 계정을 자동으로 동기화하여 이를 달성할 수 있습니다.
로그인 홈 페이지 디자인에는 일반적으로 두 가지 형태가 있으며, 귀사의 제품 비즈니스에 따라 선택할 수 있습니다:
- B2B 제품: SSO 버튼을 직접 표시하여 SSO를 사용해야 하는 기업 클라이언트 구성원들이 직관적으로 이해할 수 있게 추천합니다.
- B2C와 B2B를 모두 지원하는 제품: 대부분 사용자가 SSO를 사용하지 않기 때문에 이메일 도메인을 평가하여 SSO가 필요한지 판단합니다. 자격 증명 확인을 지연시키고, 사용자의 정체성이 확인된 후 이를 드러내는 방식으로 감출 수 있습니다.
근본적인 복잡성: 사용자 아이덴티티 모델#
그러나 SSO를 아이덴티티 시스템에 통합하는 것은 단순히 로그인 페이지에 SSO 버튼을 추가하는 것보다 훨씬 더 복잡합니다. 여러 요소들을 고려해야 합니다.
주요 요소 관계는 거의 일대일이 아니며, 일대다 또는 다대다 시나리오를 고려해야 합니다. 이러한 변형을 단계적으로 탐구하려면:
- 다수의 이메일 도메인을 가진 하나의 IdP Org: 이메일 도메인에 의존하여 사용자 아이덴티티를 결정하려면 다중 도메인 바인딩을 지원해야 합니다.
- 하나의 이메일 도메인이 다수의 IdP Org에 해당: 도메인이 여러 IdP Org에 속할 수 있다면, 사용자는 싱글 사인온을 위해 원하는 IdP를 선택해야 합니다.
- 여러 SP Org에 연결된 하나의 IdP Org: 하나의 IdP를 여러 SP Org에 연결하는 빠른 기능을 제공하는 것을 고려하십시오.
- 여러 IdP Org 및 SP Org에 있는 하나의 사용자 계정: 서로 다른 SP Org가 서로 다른 IdP를 통해 검증을 요구할 수 있습니다.
엔터프라이즈 내에서 SSO를 활성화하거나 비활성화하는 것은 사용자의 인증 방식을 변경할 수 있으며, 이는 안전하고 원활한 전환이 요구됩니다.
- SSO 활성화 의사결정: SSO가 특정 테넌트 SP Org에만 영향을 미치는지 또는 모든 테넌트 SP Org에 영향을 미치는지 결정해야 합니다. 전자는 유연성을 제공하고, 후자는 기업 전반적인 아이덴티티 및 접근 관리 트렌드와 일치합니다.
- 전환기 고려사항: SP로서 타사 IdP 서비스의 불확실성을 수용해야 합니다. 기업 관리자는 항상 SSO로 또는 자격 증명으로 귀사의 앱에 접근할 수 있는 옵션을 제공해야 하며, 엔터프라이즈 구성원들은 전환 기간 동안 이를 필요로 할 수 있습니다.
이것들은 다양한 시나리오를 다루기 위한 일부 논점에 지나지 않으며, 보다 많은 기능과 세부 사항들이 탐구될 수 있습니다.
이 SP-초기화 SSO 분석을 통해 기업 아이덴티티 솔루션에 대한 새로운 관점을 제시했기를 희망합니다. 기쁜 소식은 Logto가 간단한 설정과 즉시 사용 가능한 SSO 인증 경험을 제공하는 솔루션을 열심히 개발 중이라는 것입니다. 다가오는 출시를 통해 특정 SP-초기화 SSO 솔루션에 대해 더 깊이 탐구할 예정이니 기대해 주세요.