SCIM（レガシードキュメンテーション） – Miro Help Center

クロスドメイン ID 管理（SCIM）を使用すると、 Miro とあなたの ID プロバイダー（IdP）間のユーザーのプロビジョニングや管理を自動化できます。

利用可能なプラン：Enterprise プラン
設定者：会社の管理者

重要事項

自動プロビジョニングの設定開始前に、SAML ベースの SSO が正しく設定され、Enterprise プランで正常に機能していることが必要です。
SAML SSO の設定については、ガイドを参照してください。
IdP グループと Miro のチームの同期は任意です。
IdP グループを Miro のチームにリンクして同期することは任意で行えます。IdP ではチームの作成や削除はできません。チームの作成・管理は Teams API を使用して行えます。IdP グループを SCIM API で管理する方法の詳細は、Miro 開発者ドキュメントを参照してください。
SCIM におけるメールアドレスの変更には、次の検証ルールが適用されます:
- 管理対象ユーザーの確認: ユーザーの現在のドメインが SCIM リクエストを送信した組織によって所有権が確認されていない場合、メールアドレスの更新はブロックされ、400 エラーが返されます。
- 対象のメールドメインの検証: 対象のメールドメインが SCIM リクエストを送信した組織とは異なる組織によって所有権が確認されている場合、メールアドレスの更新はブロックされ、400 エラーが返されます。対象のメールドメインが SCIM リクエストを送信した組織によって所有権が確認されている場合、メール確認を必要とせずに更新が許可されます。監査ログには、ユーザーが所属する各組織で更新が記録されます。
- ドメイン制御と SSO：メールアドレスの更新は、ドメイン制御（IDC）またはシングルサインオン（SSO）によるドメイン確認に基づいて許可されます。SCIM リクエストを開始した組織によって対象メールドメインが CD または SSO で確認されている場合、更新を進めることができます。
  
  SCIM メールアドレス変更検証ワークフローの図

Miro の SCIM 運用ルール

SCIM 同期による変更は、主に新たに割り当てられたユーザーに適用されます。すでにサブスクリプションに参加しているユーザーのステータスは補足されますが、チームレベルで変更が適用されるため、上書きされない場合があります。例えば次のようなケースです。
a）あるユーザーが Miro 側のチーム 1 のメンバーであり、IdP がそのユーザーをチーム 2 に追加する更新情報を送信した場合、チーム 1 でのステータスは影響を受けません。
b）IdP がユーザー 1 に変更を含む更新を送信した場合、他のチームメンバーには変更はありません。前述の 対応機能 > グループの同期とプッシュ で説明しているように、一括してチームのステータスを上書きし、すべてのユーザーを再同期するには、新たなプッシュを試みてください。
SCIMでプロビジョニングされたすべてのユーザーには、サブスクリプションのデフォルトのライセンスが割り当てられます：
a）フレキシブルライセンスプログラムを利用していない Enterprise サブスクリプションの場合：フルライセンス。サブスクリプションのライセンスが不足した場合、ユーザーは制限付き無料ライセンスでプロビジョニングされ始めます。
b）フレキシブルライセンスプログラムが有効になっている Enterprise サブスクリプションの場合：デフォルトのサブスクリプションライセンスに応じて、Free または制限付き無料ライセンス。
ーデフォルトとは異なるライセンスでプロビジョニングする必要があるユーザーがいる場合：
上記のように、すべてのユーザーはデフォルトのライセンスでプロビジョニングされます。ただし、ユーザーの一部または全員を即座に更新するには、UserType属性に Full 値を指定できます。この属性で更新されたユーザーは、ユーザー側でダウンタイムが生じることなくフルライセンスにアップグレードされます。
SCIM でプロビジョニングされたすべてのユーザーは、ドメイン制御機能の影響も受けます。つまり、ユーザーが ID プロバイダーの 1 つのセキュリティーグループのメンバーであっても、ドメイン制御の設定で 3 つのチームが指定されていれば、そのユーザーはその 3 つのチームにも追加されます。

サービス保護のため、Miro は 30 秒ごとに利用可能な API コール数を制限します。

リクエスト種別	制限レベル
GET scim/users GET scim/users/{userId}	第 1 レート制限レベル 1
POST scim/users/{userId} PUT scim/users/{userId} PATCH scim/users/{userId} DELETE scim/users/{userId}	第 3 レート制限レベル 3
GET scim/Groups PATCH scim/Groups/{groupId}	第 4 レート制限レベル 4
GET scim/Groups/{groupId}	第 3 レート制限レベル 4

制限レベルの詳細については、こちらをご覧ください。リクエスト数が制限を超えた場合、Miro は、標準の 429 Too many requests（リクエストの回数が多すぎます） を返します。

対応機能

Miro の SCIM スキーマの詳細については こちらをご覧ください。

Miro は、以下のプロビジョニング機能をサポートしています。

新規ユーザーの作成
IdP で Miro のアプリケーションに割り当てられた新規ユーザーは、Miro Enterprise サブスクリプションに Enterprise メンバーとして作成されます。IdP グループに追加されたユーザーで、そのグループが同名の Miro チームに同期されている場合は、そのユーザーはチームメンバーとしてそのチームに追加されます。
ユーザープロフィール更新のプッシュ
サポート対象の属性や変更については、以下をご覧ください。
同期とプッシュ IdP グループ
IdP グループとそのメンバーを Miro Enterprise サブスクリプションのチームに同期し、ユーザーのメンバーシップを自動的に管理します。継続的な同期により、同期された Miro のチームには IdP グループのユーザーに関する特定の更新情報が送信され、プッシュにより（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 Enterprise サブスクリプションでユーザーが再アクティブ化されます.
支払いグループの割り当てを自動化する
SCIM を使用して、新規ユーザーを支払いグループに自動的に割り当てます. ID プロバイダー（IdP）が設定されたら、コストセンターを支払いグループにリンクします. これにより、これらのコストセンターの現在および将来のユーザーが、適切な支払いグループに自動的に振り分けられます.

直接 Delete API コールを送信することにより、Enterprise プランからユーザーを削除することもできます。ドキュメントはこちらをご参照ください。なお、ユーザーを削除できるのは直接のコールのみです。Delete イベントがお使いの IdP によって起動された場合は、非アクティブ化のリクエストとして扱われます。

対応している属性

⚠️ 以下にご注意ください：
- メールアドレス / プライマリパラメーター / 一意の識別子 / ユーザー名) は Miro が必要とする唯一の値で、メールアドレス形式である必要があります。
- メールアドレスの更新は、すでに同期済みのユーザーに対してのみ可能です。つまり、最初の同期は IdP と Miro のメールアドレスが同じ状態で行われる必要があります。そうしないと、Miro はユーザーを認識せず、新しいメールアドレスで重複した Miro プロフィールが作成されます。
- メールアドレスの更新は、ユーザーの IdP プロフィールで行われ、割り当てリストでは行われません。
- 他の属性とは異なり、ユーザーの メールアドレス を更新すると通知が送信されます。新旧両方のメールアドレスに、今後は新しいメールアドレスで Miro にログインするよう知らせるメールが届きます。

属性名	SCIM 属性（クレーム）
メールアドレス	ユーザー名. メール形式である必要があります
以下のリストの属性は必須ではなく、存在すれば受け入れます（Miro に送信された他の属性は無視されます）。
フルネーム	displayName; formatted; givenName + " " + familyName; userName
ユーザー種別	userType サポート値： "フル"
アクティブ	active サポート値： "true" または "false"
プロフィール写真	photos.^[type=='photo'].value もしくは photos.^[type==photo].value （Okta） photos[type eq "photo"].value （Entra）画像へのテキスト形式の URL である必要があります。対応ファイル形式: jpg、jpeg、bmp、png、gif ファイルタイプを判別するには、URL にファイル拡張子を含める必要があります（例 https://host.com/avatar_user1.jpg）または URL へのリクエストのレスポンスが、ファイル本体とともに Content- Type ヘッダーを返す必要があります（例 Content-Type = 'image/jpeg'）ダウンロード可能な最大ファイルサイズ：31457280 バイト
ユーザーの役割	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 「value」フィールドは SCIM 標準では文字列型ですが、managerId 内部の Miro フィールドは Long 型です。「value」属性が数値でない場合、この値は無視されます。

⚠️ Miro アカウントにはパスワードがありません — ログインはマジックリンク、SSO、またはソーシャルアカウントで行われるため、SCIM で同期するパスワード属性はありません。
⚠️ Username、UserType、および roles.value は非アクティブ化されたユーザーに対して更新できません。

すべての属性は、エクスポートされた CSV ユーザーリストに表示され、アクティブなユーザーセクションからダウンロードできます。

ユーザーリストをダウンロードするオプション

SCIM の設定

ステップ 1：Miro の SCIM オプションを有効にする

Miro Enterprise プランで SCIM を有効にするには、会社の設定 > Enterprise インテグレーション, に移動し、SCIM プロビジョニング機能を有効にします. そこで、IdP を設定するための Base URL と API トークンを取得できます。

ステップ 2：IdP の設定

この設定は、使用する IdP によって異なります。Miro は事前設定済みの Okta と Entra ID に対応していますが、SCIM の設定が可能であれば任意の IdP を使用できます。

OKTA - 設定手順はこちらをご覧ください。

Entra ID ー設定手順はこちらをご覧ください。

新しいトークンを生成する

次に、会社の設定 > Enterprise インテグレーション. に移動します。
SCIM プロビジョニングのセクションで、 新しいトークンを生成するをクリックします。
新しい SCIM トークンの生成画面で、生成をクリックします。
新しいトークンを生成したら、IdP プロバイダーでそのトークンを設定する必要があります。

起こり得る問題とその解決方法

許可リストエラーが原因でユーザーがプロビジョニングされない。

ユーザーのドメインアドレスがセキュリティー設定の許可リストに追加されていることを確認してください。

ある ID ソリューション（IdP1）でエンドユーザーを認証しながら、別の ID ソリューション（IdP2）を介して SCIM を有効にしたい場合、次の 2 つの条件を満たすことで可能です。

IdP2 が、ベアラートークンを使用して、API コールを行うことができる。
両方の ID プロバイダーが同期している（つまり、SCIM でプロビジョニングされたユーザーは IdP1 にも存在するので、Miro で認証することができる）。

SCIM エラーの詳細については、当社のドキュメントをご覧ください。問題が解決しない場合は、 Miro のサポートチームにお問い合わせください。