교차 도메인 아이덴티티 관리 시스템(SCIM)은 Miro와 ID 공급자(IdP) 간의 사용자 프로비저닝 및 관리를 자동화합니다.
사용 가능 대상: Enterprise 플랜
설정자: 회사 관리자
새 동기화 모델
Miro는 새로운 SCIM 동기화 모델을 도입해 SCIM 그룹이 이전에 Miro 팀에 매핑되던 방식 대신 Miro 사용자 그룹에 대응하도록 변경합니다. 가능한 한 빨리 사용자 그룹 기반 SCIM 동기화로 마이그레이션할 것을 권장합니다.
팀과 달리 사용자 그룹은 하나의 팀에만 속하지 않으므로 1:1 팀 매핑에 제한되지 않고 여러 팀에 걸친 조직 구조를 동기화할 수 있습니다. 사용자 그룹은 Miro 전반에서 사용하는 동일한 권한 모델에 직접 통합됩니다. 그룹과 보드 및 스페이스를 공유할 수 있고, 댓글에서 그룹을 @멘션해 모든 구성원에게 알릴 수 있으며, 사용자 그룹 API로 그룹을 프로그램 방식으로 관리할 수 있어 IdP를 통한 프로비저닝이 Miro의 공유 및 접근 방식과 동기화됩니다.
참고: SCIM 그룹이 Miro 사용자 그룹에 해당하는 최신 API 버전입니다. SCIM 그룹의 구성원을 추가하거나 제거하면 Miro 사용자 그룹의 구성원이 변경됩니다.
다음을 꼭 확인해주세요
- 자동 프로비저닝을 구성하기 전에 Miro Enterprise 플랜에서 SAML 기반 SSO(통합로그인)가 올바르게 설정되어 정상적으로 작동해야 합니다. 자세한 내용은 가이드를 참조하세요.
- IdP 그룹을 Miro 사용자 그룹과 동기화하는 것은 선택 사항입니다. IdP 그룹을 Miro의 사용자 그룹과 연결해 동기화할 수 있습니다. SCIM 그룹은 Miro 사용자 그룹에 직접 대응합니다 — SCIM 그룹을 생성·업데이트·삭제하면 해당 사용자 그룹이 생성·업데이트·삭제되며, 구성원을 추가하거나 제거하면 그 사용자 그룹의 구성원이 변경됩니다. 또한 User Groups API를 사용해 사용자 그룹을 직접 생성하고 관리할 수 있습니다. 팀과 달리 사용자 그룹은 단일 팀에 국한되지 않으므로 여러 팀에 걸친 조직 구조를 동기화할 수 있습니다. SCIM API가 그룹 관리를 어떻게 지원하는지에 대한 자세한 내용은 Miro 개발자 문서를 참조하세요.
-
SCIM에서 이메일 주소 변경에는 다음과 같은 검증 규칙이 적용됩니다:
- 관리되는 사용자 확인: 사용자의 현재 도메인이 SCIM 요청을 시작한 조직에 의해 소유되어 있지 않으면 이메일 주소 업데이트가 차단되며 400 오류가 발생합니다.
- 대상 이메일 도메인 확인: 대상 이메일 도메인이 SCIM 요청을 시작한 조직이 아닌 다른 조직에 의해 소유된 경우 이메일 주소 업데이트가 차단되며 400 오류가 발생합니다. 대상 이메일 도메인이 SCIM 요청을 시작한 조직에 의해 소유된 경우 이메일 확인 없이 이메일 주소 업데이트가 허용됩니다. 사용자가 속한 각 조직의 감사 로그에 업데이트 내용이 기록됩니다.
- 도메인 제어 및 SSO(통합로그인): 이메일 업데이트는 도메인 제어(IDC) 또는 SSO(통합로그인)를 통한 도메인 확인을 기반으로 허용됩니다. 대상 이메일 도메인이 요청을 시작한 조직에 의해 CD 또는 SSO를 통해 검증되면 업데이트를 진행할 수 있습니다.
SCIM 이메일 변경 검증 워크플로 다이어그램
Miro SCIM 운영 규칙
- SCIM으로 동기화된 변경 사항은 주로 새로 할당된 사용자에게 적용됩니다. 멤버십 변경은 직접적이고 즉시 적용됩니다: SCIM 그룹의 멤버에 대한 추가, 제거 또는 교체 작업은 해당 Miro 사용자 그룹에서 그 멤버를 추가하거나 제거하며, 별도의 "push" 단계가 필요하지 않습니다. 예: a) 사용자가 Miro 측의 사용자 그룹 A에 속해 있고 IdP가 해당 사용자를 사용자 그룹 B에 추가하도록 업데이트를 전송하면, 사용자 그룹 A의 소속은 영향을 받지 않습니다 — 해당 사용자는 단순히 사용자 그룹 B의 구성원도 됩니다. b) IdP가 User1에 대한 변경을 포함한 업데이트를 전송하면, 다른 사용자 그룹 구성원들은 영향을 받지 않습니다.
- SCIM으로 프로비저닝된 모든 사용자에게는 구독의 기본 라이선스가 할당됩니다: a) 플렉시블 라이선싱 프로그램이 없는 Enterprise 구독의 경우, Collaborate 또는 Full(레거시) 라이선스가 할당됩니다. 구독의 유료 라이선스가 소진되면 사용자는 제한된 무료 라이선스로 프로비저닝되기 시작합니다. b) 플렉시블 라이선싱 프로그램이 활성화된 Enterprise 구독의 경우, 기본 구독 라이선스에 따라 Free 또는 제한된 무료 라이선스가 할당됩니다.
기본 라이선스와 다른 라이선스로 일부 사용자를 프로비저닝해야 하는 경우: 앞서 설명한 대로 모든 사용자는 기본 라이선스로 프로비저닝됩니다. 그러나 UserType을 사용해 해당 사용자 전체 또는 일부를 즉시 업데이트할 수 있습니다. 속성으로 Collaborate 또는 Full (legacy) 값을 지정하면. 해당 속성으로 업데이트된 사용자는 사용자 측에서 서비스 중단 없이 Collaborate 또는 Full (legacy) 라이선스로 업그레이드됩니다. 참고: SCIM으로 사용자 그룹에 멤버를 추가하면 해당 멤버가 이전에 비활성화되었거나 삭제된 경우 재활성화하거나 재생성하며 라이선스를 Collaborate 또는 Full (legacy)로 업그레이드합니다. - SCIM으로 프로비저닝된 모든 사용자는 도메인 제어 기능의 영향을 받습니다. 즉, 사용자가 ID 공급자에서 하나의 보안 그룹에만 속해 있더라도 도메인 제어 설정에서 지정한 팀이 3개라면 해당 사용자도 그 3개 팀에 추가됩니다.
-
서비스를 보호하기 위해 Miro는 30초마다 사용 가능한 API 호출 수를 제한합니다:
요청 유형 제한 수준 GET scim/users
GET scim/users/{userId}첫 번째 요청 제한 레벨 1 POST scim/users/{userId}
PUT scim/users/{userId}
PATCH scim/users/{userId}
DELETE scim/users/{userId}세 번째 요청 제한 레벨 3 GET scim/Groups
PATCH scim/Groups/{groupId}네 번째 요청 제한 레벨 4 GET scim/Groups/{groupId} 세 번째 요청 제한 레벨 4 한도 레벨에 대한 자세한 내용은 여기를 참조하세요. 요청 수가 한도를 초과하면 Miro는 표준 429 Too many requests를 반환합니다.
지원되는 기능
자세한 Miro SCIM 스키마는 여기에서 확인할 수 있습니다. 그룹(사용자 그룹) 엔드포인트에 대한 자세한 정보는 Groups API 문서에서 확인할 수 있습니다.
Miro는 다음 프로비저닝 기능을 지원합니다:
-
새 사용자 생성
IdP에서 Miro 애플리케이션에 할당된 새 사용자는 Miro Enterprise 구독에 Enterprise 멤버로 생성됩니다. Miro 사용자 그룹과 동기화된 IdP 그룹에 추가된 사용자는 해당 사용자 그룹에 바로 멤버로 추가됩니다.
-
사용자 프로필 업데이트 푸시
지원되는 속성과 변경 사항은 아래를 참조하세요.
-
IdP 그룹을 사용자 그룹으로 동기화
Miro Enterprise 구독 내에서 IdP 그룹을 사용자 그룹으로 동기화해 구성원 관리를 자동화하세요. SCIM Group이 Miro 사용자 그룹에 직접 대응하므로, IdP에서의 추가·제거 작업이 사용자 그룹의 구성원에 즉시 반영됩니다 — 별도의 푸시/덮어쓰기 단계가 필요하지 않습니다.
-
IdP 그룹/Miro 사용자 그룹에서 사용자 제거(Enterprise 구독에서는 아님, 아래 참조) IdP 그룹에서 사용자를 제거하면 해당 사용자는 해당 Miro 사용자 그룹에서 즉시 제거됩니다. 이는 사용자를 사용자 그룹에서만 제거합니다. 이는 어떤 팀이나 조직에서도 사용자를 제거하지 않으며, 보드 소유권을 이전하지 않고 라이선스도 변경하지 않습니다. 사용자 그룹에는 마지막 관리자 제한이 없으며, 이미 멤버가 아닌 사용자를 제거해도 아무런 동작도 수행되지 않습니다.
-
사용자 비활성화
IdP에서 사용자를 비활성화하거나 삭제하거나 애플리케이션 접근을 차단하면 해당 사용자는 Miro Enterprise 플랜에서 비활성화됩니다. 사용자는 활성 상태에서 비활성화됨 상태(및 사용자 섹션)로 전환되며 라이선스 사용을 중단합니다. 비활성화만으로는 사용자의 사용자 그룹 멤버십이나 보드 소유권 재할당이 변경되지 않습니다.
사용자 제거는 Enterprise 구독에서 기본적으로 지원되지 않습니다. 그럼에도 불구하고, API를 사용해 기능을 수동으로 추가하면 사용자를 비활성화 상태로 설정하는 대신 구독에서 완전히 제거할 수 있습니다. 상태. 이 경우 콘텐츠는 해당 팀 구성원에게 재할당됩니다. 자동으로 재할당된 콘텐츠의 소유자가 어떤 관리자에게 돌아갈지는 설정할 수 없지만, Miro 설정에서 사용자를 수동으로 비활성화할 때 이 설정을 할 수 있습니다. 사용자를 사용자 그룹에서 제거(위 참조)해도 콘텐츠가 자동으로 재할당되지는 않습니다.
-
사용자 다운그레이드
사용자는 유료 라이선스 간에만 다운그레이드할 수 있습니다. 예를 들어, 사용자를 Accelerate userType에서 Collaborate userType으로 다운그레이드할 수 있습니다.
-
사용자 재활성화
사용자를 애플리케이션에 다시 할당하거나 IdP에서 사용자 프로필을 재활성화하면 해당 사용자가 이전에 프로비저닝되어 비활성화된 경우 Miro Enterprise 구독에서 다시 활성화됩니다.
-
결제 그룹 자동 할당
SCIM을 사용해 신규 사용자를 결제 그룹에 자동 할당합니다. ID 공급자(IdP) 설정이 완료되면 비용 센터를 결제 그룹에 연결하세요. 이렇게 하면 해당 비용 센터에 속한 현재 및 향후 모든 사용자가 올바른 결제 그룹으로 자동 분류됩니다.
-
그룹과 보드 및 스페이스 공유 Miro 사용자 그룹은 Miro 전체에 적용되는 동일한 권한 모델에 연결되므로, IdP에서 동기화된 사용자 그룹과 보드 및 스페이스를 직접 공유할 수 있어 구성원을 개별로 추가할 필요가 없습니다.
-
댓글에서 그룹 @멘션 보드 댓글에서 사용자 그룹을 @멘션해 구성원 전체에 한 번에 알림을 보냅니다.
- 프로그래밍 방식으로 그룹 관리 IdP 동기화와 관계없이 사용자 그룹 API를 사용해 사용자 그룹을 직접 생성, 업데이트 및 삭제합니다.
직접 삭제 API 호출을 보내 Enterprise 플랜에서 사용자를 삭제할 수도 있습니다 - 문서는 여기를 참조하세요. 단, 직접 호출만 사용자를 삭제합니다. 삭제 이벤트는 아이덴티티 솔루션에서 시작된 경우 비활성화 요청으로 처리됩니다.
지원되는 속성
참고: 이메일(기본 파라미터·고유 식별자·사용자 이름)은 Miro에서 유일하게 필요한 값이며 이메일 형식이어야 합니다. 이메일 업데이트는 이미 동기화된 사용자에게만 가능하며, 최초 동기화는 IdP와 Miro의 이메일이 동일할 때 이루어져야 합니다. 그렇지 않으면 Miro가 사용자를 인식하지 못해 새 이메일로 복제된 Miro 프로필이 생성됩니다. 이메일 변경은 할당 목록이 아니라 사용자의 IdP 프로필에서 이루어져야 합니다. 다른 속성과 달리 사용자의 이메일을 변경하면 알림이 전송되며, 이전 이메일 주소와 새 이메일 주소 모두 새 이메일로 Miro에 로그인해야 한다는 내용의 이메일을 받게 됩니다.
| 속성 이름 | SCIM 속성(클레임) |
|---|---|
| 이메일 | userName. 필수이며 이메일 형식이어야 합니다 |
| 아래에 나열된 속성은 필수가 아니며 제공되는 경우 Miro에서 수락합니다(그 외 Miro로 전송된 속성은 무시됩니다). | |
| 전체 이름 | displayName; formatted; givenName + " " + familyName; userName |
| 사용자 유형 | userType — 지원 값: "Full", "Standard", "Collaborate", "Accelerate", "Advanced" 참고: Standard와 Advanced는 모두 레거시 사용자 유형입니다. |
| 활성 | active — 지원 값: "true" 또는 "false" |
| 프로필 사진 | photos.^[type=='photo'].value or photos.^[type==photo].value (Okta); photos[type eq "photo"].value (Entra). 이미지의 텍스트 URL이어야 합니다. 지원되는 파일 형식: jpg, jpeg, bmp, png, gif. 다운로드 가능한 최대 파일 크기는 31,457,280바이트입니다. |
| 사용자 역할 | roles.^[primary==true].value (Okta); roles[primary eq "True"].value (Entra) — 지원 값: ORGANIZATION_INTERNAL_ADMIN, ORGANIZATION_INTERNAL_USER |
| 사원 번호 | employeeNumber |
| 비용 센터 | costCenter |
| 조직 | organization |
| 부문 | division |
| 부서 | department |
| 관리자 이름 | manager.displayName |
| 관리자 ID | manager.value — SCIM 표준에서 "value"는 문자열(String) 타입이지만 내부의 managerId 필드는 Long 타입입니다; 숫자가 아닌 값은 무시됩니다. |
⚠️ 비밀번호 변경은 지원되지 않으며, 단기적으로 지원할 계획이 없습니다. ⚠️ 사용자 이름, userType 및 roles.value는 비활성화된 사용자의 경우 업데이트할 수 없습니다.
모든 속성은 활성 사용자 섹션에서 다운로드할 수 있는 내보낸 CSV 사용자 목록에 표시됩니다.
SCIM 구성
단계 1: Miro에서 SCIM 옵션 활성화
SCIM을 Miro Enterprise 플랜에서 사용 설정하려면 회사 설정 > Enterprise 통합,으로 이동해 SCIM 프로비저닝 기능을 활성화하세요. 거기에서 IdP 구성에 필요한 베이스 URL과 API 토큰을 확인할 수 있습니다.
단계 2: ID 공급자 구성
설정은 사용 중인 ID 공급자에 따라 달라집니다. Miro는 사전 구성된 Okta와 Entra ID를 지원하지만 SCIM 설정을 허용하는 ID 공급자라면 원하는 것을 사용할 수 있습니다.
OKTA - 설정 안내는 여기에서 확인하세요.
Entra ID - 설정 안내는 여기에서 확인하세요.
새 토큰 생성
- Company 설정 > Enterprise 통합.로 이동합니다.
- SCIM Provisioning 섹션에서 새 토큰 생성을 클릭합니다.
- 새 SCIM 토큰 생성 창에서 생성을 클릭합니다.
- 새 토큰을 생성한 후 IdP에 새 토큰을 구성해야 합니다.
발생할 수 있는 문제와 해결 방법
1. 허용 목록 오류로 인해 사용자가 프로비저닝되지 않습니다.
사용자의 도메인 주소가 허용 목록에 추가되어 있는지 보안 설정에서 확인하세요.
2. 엔드 사용자를 하나의 ID 공급자(IDP1)로 인증하면서 다른 ID 공급자(IDP2)로 SCIM을 활성화하려는 경우, 다음 두 가지 조건을 충족해야 합니다:
- IDP2가 베어러 토큰으로 API 호출을 할 수 있어야 합니다.
- 두 ID 공급자가 동기화되어 있어야 합니다. 즉 SCIM으로 프로비저닝된 사용자가 IDP1에도 존재해 Miro에 인증할 수 있어야 합니다.
SCIM 오류에 대한 자세한 내용은 문서를 참조하세요. 문제가 계속되면 Miro 지원팀에 문의하세요.