모두싸인 SSO 및 Provisioning 연동 가이드

모두싸인은 외부 IdP와의 SSO 로그인(SAML 2.0), SCIM 프로비저닝(SCIM 2.0) 연동을 지원합니다. 두 규격은 표준이므로 Okta · Microsoft Entra ID(구 Azure AD) · Google Workspace · Authentik 등 표준을 지원하는 IdP와 연동할 수 있습니다.

본 가이드의 IdP 측 설정 화면은 Authentik을 예시로 작성했으며, 다른 IdP는 설정하는 화면 위치만 다를 뿐 모두싸인에 등록·입력하는 값은 동일합니다 (IdP별 진입 지점은 2.3·3.4의 대응표 참고).

연동을 시작하기 전에, 먼저 요금제를 확인해주세요

• 요금제 확인 : 모두싸인 SSO·Provisioning은 맞춤형 요금제로 제공되는 기능입니다. 메뉴 진입 전 요금제에 기능 제공 여부를 확인해주세요.

연동은 아래 순서로 진행합니다.

1. 도메인 클레임 — 모두싸인 SSO·Provisioning 사용을 위한 기본 조건

2. SSO 설정 — SAML 2.0 기반 워크스페이스 로그인 구성

3. Provisioning 설정 — SCIM 2.0 기반 사용자·그룹 자동 동기화 구성

모두싸인 SSO와 Provisioning을 사용하려면 먼저 도메인 클레임이 완료되어야 합니다.

• 도메인 클레임은 워크스페이스가 특정 이메일 도메인을 소유하고 있음을 증명하는 절차이며, 클레임된 도메인의 이메일을 가진 사용자만 SSO 로그인과 SCIM 프로비저닝 대상이 됩니다.

• 도메인 등록은 맞춤형 요금제를 통해 SSO 또는 PROVISIONING 권한 중 하나 이상을 보유한 워크스페이스에서 가능합니다.

검증 주기 및 실패 처리

• 모두싸인은 매일 배치로 클레임된 도메인의 TXT 레코드를 재검증합니다.

• 마지막 성공 검증 시각으로부터 72시간 이상 검증이 실패하면 도메인 클레임이 검증 실패 상태로 전환됩니다.

• 검증 실패 상태가 되면 해당 도메인을 요구하는 SSO 및 Provisioning 기능이 자동으로 비활성화됩니다.

• 수동 재검증으로 클레임이 다시 사용 가능 상태가 되더라도 SSO·Provisioning은 자동으로 재활성화되지 않으므로, 관리자가 각 기능을 수동으로 활성화해야 합니다.

• 모두싸인 로그인 > 우측 상단 통합 설정 ⚙︎ > 워크스페이스 관리 > SSO 및 프로비저닝

하나의 워크스페이스에 자사 이메일 도메인을 여러 개 등록·검증할 수 있습니다.

• 검증된 모든 도메인은 워크스페이스에 설정된 하나의 SSO·Provisioning을 함께 사용합니다.

• 단, 도메인을 관리하는 Idp는 1개여야 하며, 하나의 워크스페이스에 여러 개의 Idp 연결은 불가능합니다.(도메인 N개 : IdP 1개 : SSO 설정 1개 : Provisioning 설정 1개 가능)

• 별칭(alias) 기반 로그인 진입 방식은 그대로이며, 도메인을 여러 개 등록해도 사용자는 단일 별칭으로 로그인합니다.

• 도메인은 워크스페이스당 최대 10개까지 등록할 수 있습니다.(3.3의 SCIM Bearer Token 한도 "워크스페이스당 최대 10개"와는 별개의 한도입니다.)

• 도메인마다 고유한 DNS TXT 검증 토큰이 발급되며, 검증 상태 칩(검증됨/유예됨/검증 실패/검증 대기)도 도메인별로 독립 관리됩니다. 등록·TXT 등록·검증 절차는 위 1~3과 동일하게 도메인마다 반복합니다.

• 이미 SSO·Provisioning이 설정된 워크스페이스에 도메인을 추가·검증하면, 별도 SSO 설정 없이 기존 SSO·Provisioning에 자동으로 합류합니다.(해당 도메인 멤버가 같은 SSO로 로그인하고, SCIM으로 자동 등록됨)

• 도메인 삭제 시, 해당 도메인 멤버의 ① SSO 로그인 자격 상실, ② SCIM 자동 동기화 중단(수동 관리 전환)을 안내하는 모달이 먼저 표시됩니다.

• 마지막 남은 1개의 검증 도메인은 SSO 또는 Provisioning 리소스가 존재하면 삭제가 차단됩니다.먼저 SSO/Provisioning을 삭제하거나 다른 검증 도메인을 추가해 주세요.

• 도메인을 삭제해도 그 도메인에 기등록된 워크스페이스 멤버(관리형 멤버) 계정은 유지됩니다 — 자동 동기화만 끊기게 되며, 수동 관리 멤버로 전환됩니다.(계정 상태 자동 변경 없음)

모두싸인은 SAML 2.0 프로토콜을 지원하며, 이를 통해 외부 IdP(Authentik, Okta 등)로 워크스페이스 로그인을 위임할 수 있습니다.

사전 조건

• 맞춤형 요금제를 구독하여 SSO 권한을 보유해야 합니다.

• 도메인 클레임이 검증됨 또는 유예됨 상태여야 합니다(검증 실패 시 신규 SSO 설정 차단).

• SSO 활성화 이후 도메인 클레임이 실패되면 SSO 는 비활성화되며 관리자가 수동으로 활성화해야 합니다.

모두싸인 SSO 로그인 진입 방식

모두싸인 SSO 로그인은 별칭(alias) 입력을 단일 진입점으로 사용합니다. 사용자는 SSO 로그인 화면에서 워크스페이스 별칭을 입력해 SSO 인증을 시작합니다.

• 별칭 기반 진입은 "특정 이메일이 어떤 워크스페이스에 속하는지"를 외부에서 탐색하는 위험을 줄입니다.

• 같은 도메인을 여러 워크스페이스가 사용하는 환경에서도 별칭으로 각 워크스페이스를 정확히 식별합니다.

SSO 전용 모드

SSO 전용 모드를 활성화하면 워크스페이스의 SSO 대상 멤버는 SSO로만 로그인할 수 있습니다.

• 단, 최고 관리자는 예외로 비밀번호 로그인이 항상 허용되어 IdP 장애 시에도 워크스페이스에 접근할 수 있습니다.

로그인 시점에 SSO 기준이 되는 워크스페이스를 특정하기 위해 별칭(alias)을 설정합니다. 별칭은 워크스페이스당 1개이며 사용자는 로그인 화면에서 이 별칭을 입력해 진입합니다.

SSO 설정 화면에서 IdP에 등록할 SP(모두싸인) 측 속성값을 확인합니다.

SAML 2.0 표준이므로 어떤 IdP를 쓰든 IdP에 등록할 값은 동일합니다 (2.2에서 확인한 Entity ID·ACS URL과 email ,name 속성 매핑.) IdP마다 이 값을 넣는 화면 위치만 다릅니다.

IdP별 SAML 설정 위치 (참고)

아래 상세 절차는 Authentik 예시입니다(IdP 기본 사용법은 생략). 다른 IdP는 위 표의 위치에서 동일한 값을 입력하세요.

Applications → Providers → Create → SAML Provider 선택 후 아래 값을 입력합니다.

• ACS URL: 2.2에서 확인한 ACS URL

• Issuer / Audience (Entity ID): 2.2에서 확인한 Entity ID

• Authorization flow: default-provider-authorization-implicit-consent (동의 화면 생략)

모두싸인 SSO 로그인은 IdP가 보내는 email 속성으로 사용자를 식별합니다.

Authentik Customization → Property Mappings → Create → SAML Property Mapping에서 email 속성 매핑을 구성해 Provider에 연결합니다.

• SSO용 Application의 기본 공급자(Provider)로 SAML Provider를 연결합니다.

• SCIM Provider와 동일 Application을 공유하는 경우 최고 관리자 Policy 구성에 주의해 주세요 (3.4.5 참고)

• 모두싸인에서 SSO 전용 모드를 활성화해도 최고 관리자는 비밀번호 로그인 가능 합니다. 이는 IdP 장애 시 복구 경로로 유지하기 위함입니다.

SAML Metadata는 IdP와 SP가 서로 통신하기 위해 필요한 설정 정보(엔드포인트 URL, 인증서, 바인딩 방식 등)를 XML 형식으로 담은 문서입니다. SAML 설정을 마치고 나면 SAML Metadata를 확인할 수 있습니다.

모두싸인은 SCIM 2.0 프로토콜을 지원하며, IdP가 Push 방식으로 호출하는 SCIM API를 통해 사용자·그룹 생성/수정/삭제를 자동 동기화할 수 있습니다.

• SCIM API 레퍼런스는 프로비저닝 사용 고객 대상으로 담당자가 별도 전달 드립니다.

사전 조건

• 맞춤형 요금제를 구독하여 PROVISIONING 권한을 보유해야 합니다.

• 유효한 SCIM 토큰 발급 — 워크스페이스 관리자가 앱에서 직접 발급한 활성 Bearer Token이 필요합니다(워크스페이스당 최대 10개).

• 프로비저닝 설정 활성화 — 워크스페이스의 프로비저닝 설정이 SCIM 프로토콜로 활성화 상태여야 합니다.

• 도메인 Claim 등록 및 검증 완료 — 워크스페이스 이메일 도메인이 Claim으로 등록되어 사용 가능 상태여야 하며, 프로비저닝되는 사용자의 이메일 도메인은 Claim된 도메인과 일치해야 합니다.

주요 제약

• 최고 관리자(ADMIN) 제외: 최고 관리자는 프로비저닝 대상이 아니며, 해당 계정을 대상으로 한 요청은 422 Unprocessable Entity(Blocked for admin member)로 거부됩니다. IdP 측 동기화 범위에서 반드시 제외해 주세요.

• 이메일 변경 불가: 모두싸인에서 email은 계약 참여자의 식별자로 사용되기 때문에 변경할 수 없습니다. IdP에서 연동된 계정의 이메일을 바꾸려면 새 계정을 생성해야 합니다.

• SCIM 동기화 대상은 IdP가 기준: SCIM으로 동기화되는 사용자·그룹 속성은 IdP 값이 기준이며, 모두싸인 에서 변경해도 다음 동기화 때 IdP 값으로 덮어써집니다. 따라서 SCIM 대상 멤버·그룹은 IdP에서 관리하는 것을 권장합니다. (프로비저닝이 활성화돼도 앱에서의 멤버·그룹 관리가 일괄 차단되지는 않으며 최고 관리자의 관리형 멤버 관리 4종은 3.5를 참고하세요.)

• 삭제 유예 기간: IdP에서 계정을 삭제하면 30일의 유예 기간이 지난 뒤 모두싸인 워크스페이스 멤버십 및 계정이 완전히 삭제됩니다.

• 멤버 수 점유: 워크스페이스 멤버 수 제한에서는 활성(ACTIVE) 멤버 뿐 아니라 비활성화(INACTIVE)·삭제 유예(EXPIRED) 계정도 포함되어 카운팅 됩니다. 삭제 유예 계정은 30일 유예가 끝나 계정이 완전히 삭제될 때 카운팅에서 빠지며 비활성화 계정은 비활성 상태에서도 계속 카운팅 됩니다.

• 관리형 멤버 전환·동기화 거부 케이스: SCIM 생성·전환 요청 시 다음은 거부됩니다

  • 워크스페이스 관리자

  • 이메일 도메인이 클레임 도메인과 불일치

  • 다른 워크스페이스의 멤버·관리형 멤버

  • 삭제 유예 상태 (유예 중에는 SCIM으로 복구 불가. 최고관리자가 직접 모두싸인에 접속하여 멤버 복구 가능).

SCIM 2.0 표준이므로 어떤 IdP를 쓰든 IdP에 등록할 값은 동일합니다( 3.2의 SCIM Endpoint URL과 3.3에서 생성한 Bearer Token, 그리고 3.4.2·3.4.3의 표준 속성 매핑). IdP마다 이 값을 넣는 화면 위치만 다릅니다.

IdP별 SCIM 프로비저닝 설정 위치 (참고)

아래 상세 절차는 Authentik 예시입니다(IdP 기본 사용법은 생략). 다른 IdP는 위 표의 위치에서 동일한 값을 입력하세요.

Applications → Providers → Create → SCIM Provider 선택 후 아래 값을 입력합니다.

• URL: 3.2에서 확인한 SCIM Endpoint

• Token: 3.3에서 생성한 Bearer Token

• Filter group: 동기화 대상 그룹을 선택 (미선택 시 전체 그룹 동기화)

모두싸인이 요구하는 User 스키마에 맞게 Authentik의 SCIM User Property Mapping을 구성합니다. 아래 표현식은 예시이며, 사이트에서 관리하는 User 속성에 맞게 조정하면 됩니다.

• Application에 SCIM Provider를 백채널 공급자(Backchannel Provider)로 추가합니다.

최고 관리자는 모두싸인에서 프로비저닝 대상이 아니며, 미제외 시 422 Blocked for admin member로 차단됩니다. 아래 두 방식 중 하나를 선택해 주세요.

• 방식 A (권장): 최고 관리자를 SSO 대상에서 제외하고 단일 Application을 유지

• 방식 B: Application을 2개로 분리 — SSO용은 전체 그룹, Provisioning용은 최고 관리자 제외 그룹을 Policy로 바인딩

프로비저닝이 활성화된 워크스페이스에서도 최고 관리자는 워크스페이스 멤버(관리형 멤버) 계정에 대해 아래 4개 행위를 모두싸인 앱에서 직접 수행할 수 있습니다.

• 프로비저닝으로 등록된 관리형 멤버에도 동일하게 적용됩니다.

• 모두싸인에서 프로비저닝으로 등록된 관리형 멤버를 직접 수정하더라도 이후 동기화 시 상태·프로필은 IdP 값이 우선 반영됩니다 (비밀번호는 프로비저닝 대상이 아니므로 영향받지 않습니다).