도메인 간 아이덴티티 관리 시스템(SCIM)을 사용하면 Miro와 ID 공급자(IdP) 간의 사용자 프로비저닝 및 관리를 자동화할 수 있습니다.
사용 가능 대상:Enterprise 플랜
설정자: 회사 관리자
다음을 꼭 확인해주세요
-
자동 프로비저닝을 구성하기 전에 SAML 기반 SSO가 Miro Enterprise 플랜에서 올바르게 설정되어 정상적으로 작동해야 합니다.
SAML SSO 구성에 대한 가이드를 참조하세요. -
IdP 그룹을 Miro 팀과 동기화하는 것은 선택 사항입니다.
IdP 그룹을 Miro 팀과 선택적으로 연결해 동기화할 수 있습니다. IdP로 팀을 생성하거나 삭제할 수 없습니다. Teams API를 사용해 팀을 생성하고 관리할 수 있습니다. SCIM API가 IdP 그룹 관리를 어떻게 지원하는지에 대한 자세한 내용은 Miro 개발자 문서를 참조하세요. -
SCIM에서의 이메일 주소 변경에는 다음 검증 규칙이 적용됩니다:
- 관리 대상 사용자 확인: 사용자의 현재 도메인이 SCIM 요청을 시작한 조직에 의해 클레임되지 않은 경우, 이메일 업데이트가 차단되며 400 오류가 발생합니다.
- 대상 이메일 도메인 확인: 대상 이메일 도메인이 SCIM 요청을 시작한 조직이 아닌 다른 조직에 의해 클레임된 경우, 이메일 업데이트가 차단되며 400 오류가 발생합니다. 대상 이메일 도메인이 요청을 시작한 조직에 의해 클레임된 경우에는 이메일 확인 없이 업데이트가 허용됩니다. 사용자가 속한 각 조직의 감사 로그에 업데이트가 기록됩니다.
-
도메인 제어 및 SSO(통합로그인): 이메일 주소 업데이트는 도메인 제어(IDC) 또는 SSO(통합로그인)를 통한 도메인 확인에 따라 허용됩니다. 발신 조직이 대상 이메일 도메인을 CD 또는 SSO로 검증한 경우 업데이트를 진행할 수 있습니다.
SCIM 이메일 변경 검증 워크플로 다이어그램
Miro SCIM 운영 규칙
-
SCIM으로 동기화된 변경사항은 주로 새로 할당된 사용자에게 적용됩니다. 이미 구독에 포함된 사용자의 상태는 보완되지만, 변경사항이 팀 수준에서 적용되기 때문에 덮어쓰지 않을 수 있습니다. 예를 들어:
a) 사용자가 Miro 쪽에서 Team1의 멤버이고 IdP가 해당 사용자를 Team2에 추가하도록 업데이트를 보내면 Team1의 상태는 영향을 받지 않습니다.
b) IdP가 User1에 대한 변경사항을 포함한 업데이트를 보내면 다른 팀 멤버들은 영향을 받지 않습니다. 앞서 지원되는 기능 > 그룹 동기화 및 푸시에서 설명한 것처럼 팀 상태를 덮어쓰고 모든 사용자를 한 번에 다시 동기화하려면 새 푸시를 시작해보세요.
- SCIM으로 프로비저닝되는 모든 사용자는 구독의 기본 라이선스가 할당됩니다:
a) 플렉시블 라이선싱 프로그램이 없는 Enterprise 구독의 경우: 풀 라이선스가 할당됩니다. 구독의 라이선스가 소진되면 사용자는 제한된 무료 라이선스로 프로비저닝되기 시작합니다.
b) 플렉시블 라이선싱 프로그램이 활성화된 Enterprise 구독의 경우: 기본 구독 라이선스에 따라 Free 또는 제한된 무료 라이선스가 할당됩니다.
- 일부 사용자를 기본과 다른 라이선스로 프로비저닝해야 하는 경우:
위에 설명한 바와 같이, 모든 사용자는 기본 라이선스로 프로비저닝됩니다. 그러나 모든 사용자 또는 일부 사용자를 즉시 업데이트하려면 UserType 속성에 Full 값을 설정하세요. 해당 속성으로 업데이트된 사용자는 사용자 측 다운타임 없이 풀 라이선스로 업그레이드됩니다. - 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 스키마는 여기에서 확인할 수 있습니다.
Miro는 다음 프로비저닝 기능을 지원합니다:
-
새 사용자 생성
IdP에서 Miro 애플리케이션에 할당된 새 사용자는 귀사의 Miro Enterprise 구독에 Enterprise 멤버로 생성됩니다. 동일한 이름으로 Miro 팀과 동기화된 IdP 그룹에 추가된 사용자는 해당 팀에 팀 멤버로 추가됩니다. -
사용자 프로필 업데이트 푸시
지원되는 속성과 변경 사항은 아래를 참조하세요.
-
동기 및 푸시 IdP 그룹
IdP 그룹과 해당 구성원을 Miro Enterprise 구독의 팀으로 동기화하여 사용자 멤버십을 자동으로 관리하세요. 지속적인 동기화는 IdP 그룹의 사용자에 대한 특정 업데이트를 동기된 Miro 팀으로 전송하고, 푸시는 회사 관리자가 Miro 쪽에서 수동으로 변경한 내용이 있는 경우에도 IdP 그룹을 기준으로 팀 상태를 덮어씁니다.
-
IdP 그룹/Miro 팀 이름 분리
Miro는 IdP 그룹과 Miro 팀을 이름으로 동기화하므로 정확히 같은 이름이어야 합니다. 하지만 초기 동기화가 생성된 이후에는 둘 중 하나 또는 둘 모두에 대해 편리한 이름을 지정할 수 있습니다. 이름 분리 예시는 여기에서 확인할 수 있습니다. -
IdP 그룹/Miro 팀에서 사용자 제거(Enterprise 구독은 아님, 아래 참조)
IdP 그룹에서 사용자를 제거하면 다음 그룹 푸시 시 동기화된 Miro 팀에서도 사용자가 제거됩니다. -
사용자 비활성화
IdP에서 사용자를 비활성화/삭제하거나 애플리케이션에 대한 사용자의 접근을 차단하면 Miro Enterprise 플랜에서 해당 사용자가 비활성화됩니다. 상황에 따라 사용자를 비활성화하면 해당 사용자의 콘텐츠가 가장 오래된 팀 관리자에게 재할당될 수 있습니다:- IdP에서 사용자를 비활성화하되 Miro 앱에 할당된 상태로 유지하면 Miro 쪽 팀 소속과 콘텐츠는 변경되지 않습니다. 단순히 활성 상태에서 비활성화 상태로 이동하며 사용자 섹션에서도 동일하게 표시되고 라이선스 사용이 중지됩니다.
- IdP에서 사용자를 삭제하거나 Miro 앱에서 할당 해제하여 비활성화를 유발하는 경우, 사용자가 일부 동기된 팀의 멤버라면 해당 Miro 팀에서도 사용자가 추가로 제거되고 그 팀 내의 콘텐츠는 가장 오래된 팀 관리자에게 재할당됩니다.
- IdP에서 사용자를 삭제하거나 Miro 앱에서 해당 사용자의 할당 해제로 비활성화를 유발하는 경우, 사용자가 어떤 동기화된 팀의 구성원이 아닐 때는 사용자의 팀 멤버십이 변경되지 않으며 해당 콘텐츠도 재할당되지 않습니다.
사용자 제거는 Enterprise 구독에서 기본적으로. 지원되지 않습니다. 다만, 사용자를 비활성화 상태로 설정하는 대신 구독에서 완전히 제거하려면 API를 사용해 해당 기능을 수동으로 추가할 수 있습니다. 이 경우 콘텐츠는 해당 팀 구성원에게 재할당됩니다. 자동으로 재할당된 콘텐츠의 소유권이 어떤 관리자에게 넘어갈지는 지정할 수 없습니다. 하지만 수동으로 Miro 설정에서 사용자를 비활성화하세요.
- IdP에서 사용자를 비활성화하되 Miro 앱에 할당된 상태로 유지하면 Miro 쪽 팀 소속과 콘텐츠는 변경되지 않습니다. 단순히 활성 상태에서 비활성화 상태로 이동하며 사용자 섹션에서도 동일하게 표시되고 라이선스 사용이 중지됩니다.
-
사용자 재활성화
애플리케이션에 사용자를 다시 할당하거나 IdP에서 사용자 프로필을 재활성화하면, 해당 사용자가 이전에 프로비저닝되어 비활성화된 상태였다면 Miro Enterprise 구독에서 다시 활성화됩니다. -
결제 그룹 할당 자동화
SCIM을 사용해 새 사용자를 결제 그룹에 자동 할당합니다. ID 공급자(IdP)가 설정되면 비용 센터를 결제 그룹에 연결하세요. 이렇게 하면 해당 비용 센터에 속한 현재 및 향후 모든 사용자가 자동으로 올바른 결제 카테고리로 분류됩니다.
직접 삭제 API 호출을 보내 Enterprise 플랜에서 사용자를 제거할 수도 있습니다 - 문서는 여기를 참조하세요. 단, 직접 호출만 사용자를 삭제합니다. 삭제 이벤트가 IdP에서 시작된 경우에는 비활성화 요청으로 처리됩니다.
지원되는 속성
⚠️ 주의:
- Email / 기본 파라미터 / 고유 식별자 / Username)는 Miro에서 요구하는 유일한 값이며 이메일 주소 형식이어야 합니다.
- 이메일 업데이트는 이미 동기화된 사용자에게만 가능합니다. 즉, 첫 동기화는 IdP와 Miro의 이메일이 동일할 때 이루어져야 합니다. 그렇지 않으면 Miro가 사용자를 인식하지 못해 새 이메일로 중복된 Miro 프로필이 생성됩니다.
- 이메일 업데이트는 사용자의 IdP 프로필에서 이루어져야 하며, 할당 목록에서는 하면 안 됩니다.
- 다른 속성과 달리 사용자의 Email을 업데이트하면 알림이 전송됩니다. 기존 이메일 주소와 새 이메일 주소 모두에게 Miro에 로그인할 때 새 이메일 주소를 사용해야 한다는 내용을 알리는 메일이 발송됩니다.
속성 이름 |
SCIM 속성(클레임) |
|---|---|
이메일 |
Username. 반드시 존재해야 하며 이메일 형식이어야 합니다 |
| 아래에 나열된 속성은 필수가 아니며, 존재하면 Miro에서 허용됩니다. 그 외의 속성은 Miro에서 무시됩니다. | |
전체 이름 |
displayName; formatted; givenName + " " + familyName; userName |
사용자 유형 |
userType 지원되는 값: "Full" |
활성 |
active 지원되는 값: "true" 또는 "false" |
프로필 사진 |
photos.^[type=='photo'].value 또는 이미지를 가리키는 텍스트 URL이어야 합니다. 지원되는 파일 형식: jpg, jpeg, bmp, png, gif
|
사용자 역할 |
roles.^[primary==true].value (Okta) roles[primary eq "True"].value (Entra) 지원 값: |
직원 번호 |
employeeNumber |
비용 센터 |
costCenter |
| 조직 | organization |
| 사업부 | division |
| 부서 | department |
매니저 이름 |
manager.displayName |
매니저 ID |
manager.value SCIM 표준에서 "value" 필드는 String 타입이지만 managerId |
⚠️ Miro 계정은 비밀번호가 없으며 로그인은 매직 링크, SSO(통합로그인) 또는 소셜 계정으로 이루어지므로 SCIM으로 동기화할 비밀번호 속성이 없습니다.
⚠️ Username, UserType 및 roles.value는 비활성화된 사용자에 대해 업데이트할 수 없습니다.
모든 속성은 내보낸 CSV 사용자 목록에 표시되며, 해당 목록은 활성 사용자 섹션에서 다운로드할 수 있습니다.
사용자 목록 다운로드 옵션
SCIM 구성
1단계: Miro에서 SCIM 옵션 활성화
Miro Enterprise 플랜에서 SCIM을 활성화하려면, Company 설정 > Enterprise 통합, SCIM Provisioning 기능을 활성화하세요. 해당 위치에서 IdP 구성에 사용할 Base URL과 API 토큰을 확인할 수 있습니다.
2단계: ID 공급자 구성
설정은 사용하는 ID 공급자에 따라 달라집니다. Miro는 사전 구성된 Okta와 Entra ID를 지원하지만, SCIM 설정을 허용하는 모든 ID 공급자를 사용할 수 있습니다.
OKTA - 설정 안내는 여기를 참조하세요.
Entra ID - 설정 안내는 여기를 확인하세요.
새 토큰 생성
- Company 설정 > Enterprise integrations로 이동하세요.
- SCIM Provisioning 섹션에서 새 토큰 생성을 클릭하세요.
- 새 SCIM 토큰 생성 창에서 생성을 클릭하세요.
- 새 토큰을 생성한 후 IdP 공급자에 새 토큰을 구성해야 합니다.
발생할 수 있는 문제와 해결 방법
사용자의 도메인 주소가 허용 목록에 추가되어 있는지 보안 설정에서 확인하세요.
- IDP2가 베어러 토큰을 사용해 API 호출을 할 수 있어야 합니다.
- 두 ID 공급자가 동기화되어 있어야 합니다. 즉, SCIM으로 프로비저닝된 사용자가 IDP1에도 존재하여 Miro에 인증할 수 있어야 합니다.