SCIM – Miro Help Center

クロスドメイン ID 管理（SCIM）により、Miro と IdP 間のユーザーのプロビジョニングおよび管理を自動化できます。

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

新しい同期モデル

Miro では、従来 SCIM グループが Miro チームにマップされていたモデルに替わり、SCIM グループが Miro のユーザーグループに対応する新しい SCIM 同期モデルを導入しています。できるだけ早くユーザーグループベースの SCIM 同期に移行することを推奨します。

チームとは異なり、ユーザーグループは単一のチームに限定されないため、1:1 のチームマッピングに限定されることなく、複数のチームにまたがる組織構造を同期できます。ユーザーグループはまた、Miro 全体で使用されている同じ権限モデルに直接組み込まれます。グループとボードやスペースを共有したり、コメントでグループに@メンションしてメンバー全員に通知したり、User Groups API 経由でグループをプログラム的に管理したりできるため、IdP を通じたプロビジョニングは、Miro における共有やアクセスの仕組みと同期するようになります。

注：これは SCIM グループが Miro のユーザーグループに対応する最新の API バージョンです。SCIM グループのメンバーを追加または削除すると、Miro のユーザーグループのメンバー構成が変更されます。

重要ポイント

自動プロビジョニングの設定を始める前に、SAML ベースの SSO が正しく設定され、Enterprise プランで正常に機能している必要があります。 SAML SSO の設定については、ガイドをご覧ください。
IdP グループと Miro のユーザーグループの同期は任意です。 任意で IdP のグループを Miro のユーザーグループにリンクして同期できます。 SCIM グループは Miro のユーザーグループに直接対応します。SCIM グループを作成・更新・削除すると、対応するユーザーグループがそれぞれ作成・更新・削除され、メンバーの追加・削除はそのユーザーグループのメンバー構成に反映されます。また、User Groups API を使用してユーザーグループを直接作成・管理することもできます。チームとは異なり、ユーザーグループは単一のチームに限定されないため、複数のチームにまたがる組織構造を同期できます。SCIM API を使ってグループを管理する方法の詳細は、Miro Developer documentation を参照してください。
SCIM におけるメールアドレスの変更に関する検証ルールは、次のとおりです：
- 管理対象ユーザーの確認: ユーザーの現在のドメインが SCIM リクエストを発行した組織によりクレームされていない場合、メールアドレスの更新はブロックされ、400 エラーが返されます。
- 対象メールドメインの確認: 対象メールドメインが SCIM リクエストを発行した組織とは別の組織によりクレームされている場合、メールアドレスの更新はブロックされ、400 エラーが返されます。対象メールドメインが SCIM リクエストを発行した組織によりクレームされている場合、メール確認を要求せずにメールアドレスの更新が許可されます。ユーザーがメンバーである各組織の監査ログに更新が記録されます。
- ドメイン制御と SSO: メールアドレスの更新は、ドメイン制御（IDC）またはシングルサインオン（SSO）によるドメイン確認に基づいて許可されます。対象メールドメインが SCIM リクエストを発行した組織により CD または SSO で確認されている場合、更新を実行できます。
SCIM のメールアドレス変更検証ワークフローの図

Miro の SCIM 運用ルール

SCIM 同期による変更は、主に新たに割り当てられたユーザーに適用されます。Membership changes are applied directly and immediately: an add, remove, or replace operation on a SCIM Group's members adds or removes that member from the corresponding Miro user group, with no separate "push" step required. 例えば次のようなケースです。 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 プロバイダーの 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 スキーマの詳細についてはこちらをご覧ください。Groups（ユーザーグループ）エンドポイントの詳細は、Groups API ドキュメントをご覧ください。

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

新規ユーザーの作成
IdP で Miro のアプリケーションに割り当てられた新規ユーザーは、Enterprise メンバーとして、Miro の Enterprise サブスクリプションに作成されます。IdP のグループが Miro ユーザーグループに同期され、そのグループに追加されたユーザーは該当のユーザーグループに直接メンバーとして追加されます。
ユーザープロフィール更新のプッシュ
サポート対象の属性や変更については、以下をご覧ください。
IdP グループをユーザーグループに同期する
IdP グループを Miro Enterprise サブスクリプション内のユーザーグループに同期して、メンバーシップを自動で管理します。SCIM グループは Miro のユーザーグループに直接対応するため、IdP での追加・削除はユーザーグループのメンバーに即時反映され、別途プッシュや上書きを行う必要はありません。
IdP グループ／Miro ユーザーグループからユーザーを削除する（Enterprise サブスクリプションからの削除ではありません。下記参照） IdP グループからユーザーを削除すると、対応する Miro ユーザーグループからそのユーザーが即時に削除されます。これはユーザーグループからの削除のみです。チームや組織からは削除されませんし、ボードの所有権は移行されず、ライセンスも変更されません。ユーザーグループには最後の管理者に関する制限はなく、既にメンバーでないユーザーを削除しても処理は行われません。
ユーザーの非アクティブ化
ユーザーを非アクティブ化/削除するか、IdP でユーザーのアプリケーションへのアクセス権を無効にすると、ユーザーは Miro Enterprise プランにおいて非アクティブ化されます。ユーザー（およびユーザーのセクション）の状態は アクティブ から 非アクティブ に切り替わり、ライセンスの消費は停止します。非アクティブ化のみでは、ユーザーのユーザーグループのメンバーシップは変更されず、ボードの所有権も再割り当てされません。

サブスクリプションからのユーザー削除は、デフォルトではサポートされていません。とはいえ、API を使用して手動で機能を追加することで、サブスクリプションから完全に削除することができます。代わりにユーザーを 非アクティブ ステータス。このシナリオでは、コンテンツはチームメンバーに再割り当てされます。自動で再割り当てされるコンテンツの所有権をどの管理者に付与するかを指定することはできませんが、手動でMiro の設定でユーザーを非アクティブ化するときに設定できます。ユーザーグループからユーザーを削除しても（上記参照）、それだけでコンテンツの再割り当ては発生しません。
ユーザーをダウングレード

ユーザーのダウングレードは、有料ライセンス間でのみ可能です。例えば、あるユーザーを Accelerate の userType から Collaborate の userType にダウングレードできます。
ユーザーの再アクティブ化
ユーザーが以前にプロビジョニングされ、非アクティブ化されていた場合、アプリケーションにユーザーを再度割り当てるか、IdP におけるユーザープロフィールを再アクティブ化すると、Miro Enterprise サブスクリプションでユーザーが再アクティブ化されます。
支払いグループの割り当てを自動化する
SCIM を使用して、新規ユーザーを支払いグループに自動的に割り当てます。 ID プロバイダー（IdP）が設定されたら、コストセンターを支払いグループにリンクします。これにより、これらのコストセンターの現在および将来のユーザーが、適切な支払いカテゴリーに自動的に分類されます。
グループとボードやスペースを共有する Miro のユーザーグループは Miro 全体で使われている同じ権限モデルに組み込まれるため、個別にメンバーを追加する代わりに、IdP と同期されたユーザーグループに対して直接ボードやスペースを共有できます。
コメントでグループに @メンションする ボードのコメントでユーザーグループに @メンションすると、そのメンバー全員に一度に通知できます。
プログラムでグループを管理 IdP の同期に依存せず、User Groups API を使用して、ユーザーグループを直接作成、更新、削除できます。

直接削除 API コールを送信することにより、Enterprise プランからユーザーを削除することもできます。こちらの資料をご覧ください。なお、ユーザーを削除できるのは直接コールのみです。削除イベントがID ソリューションによって発生した場合は、非アクティブ化のリクエストとして扱われます。

対応している属性

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

属性名	SCIM 属性（クレーム）
メールアドレス	ユーザー名。必須で、メール形式である必要があります
以下のリストの属性は必須ではなく、存在すれば受け入れます（Miro に送信された他の属性は無視されます）。
フルネーム	displayName; formatted; givenName + " " + familyName; userName
ユーザー種別	userType — サポート値："Full"、"Standard"、"Collaborate"、"Accelerate"、"Advanced" 注：Standard と Advanced はどちらもレガシーのユーザー種別です.
アクティブ	active — サポート値："true" または "false"
プロフィール画像	photos.^[type=='photo'].value または photos.^[type==photo].value（Okta）； photos[type eq "photo"].value（Entra）。画像へのテキスト URL である必要があります。対応ファイル形式：jpg、jpeg、bmp、png、gif。ダウンロード可能な最大ファイルサイズ：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 標準で String 型ですが、内部の managerId フィールドは Long 型です。数値以外の値は無視されます。

⚠️ 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 のサポートチームまでご連絡ください。