クロスドメイン 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 Group は Miro のユーザーグループに対応します。SCIM Group を作成・更新・削除すると、対応するユーザーグループが作成・更新・削除され、メンバーの追加・削除によりそのユーザーグループのメンバー構成が変わります。ユーザーグループは User Groups API を使って直接作成・管理することもできます。チームとは異なり、ユーザーグループは単一のチームに限定されないため、複数のチームにまたがる組織構成を同期できます。詳細は Miro 開発者向けドキュメント を参照してください。
-
SCIM におけるメールアドレスの変更には、以下の検証ルールが適用されます:
- 管理対象ユーザーの確認: ユーザーの現在のドメインが SCIM リクエストを発行している組織によって所有（確認）されていない場合、メールアドレスの更新はブロックされ、400 エラーが返されます。
- 対象メールドメインの確認: 対象のメールドメインが SCIM リクエストを発行している組織以外の組織によって所有（確認）されている場合、メールアドレスの更新はブロックされ、400 エラーが返されます。対象のメールドメインが SCIM リクエストを発行している組織によって所有（確認）されている場合は、メール確認を要求せずにメールアドレスの更新が許可されます。ユーザーが所属する各組織の監査ログに更新が記録されます。
- ドメイン制御と SSO：ドメイン制御（IDC）またはシングルサインオン（SSO）によるドメイン確認に基づき、メールアドレスの更新が許可されます。対象のメールドメインがリクエストを送信した組織によって CD または SSO を通じて検証されている場合、更新を進めることができます。
SCIM のメール変更検証ワークフローの図
Miro の SCIM 運用ルール
- SCIM 同期による変更は、主に新たに割り当てられたユーザーに適用されます。メンバーシップの変更は直接かつ即時に適用されます：SCIM Group のメンバーに対する追加、削除、置換の操作は、対応する Miro ユーザーグループへの追加・削除として即時に反映され、別途「push」ステップは不要です。例えば次のようなケースです。a) ユーザーが Miro 側でユーザーグループ A のメンバーであり、IdP がそのユーザーをユーザーグループ B に追加する更新を送信した場合、ユーザーグループ A の所属は影響を受けません — 単にユーザーグループ B のメンバーにもなります。b) IdP が User1 に変更を含む更新を送信した場合、他のユーザーグループのメンバーは影響を受けません。
- SCIM でプロビジョニングされたすべてのユーザーには、サブスクリプションのデフォルトのライセンスが割り当てられます：a）フレキシブル ライセンス プログラムが有効でない Enterprise サブスクリプションの場合：フルライセンス。サブスクリプションのライセンスが不足すると、ユーザーは制限付き無料ライセンスでプロビジョニングされ始めます。b）フレキシブル ライセンス プログラムが有効になっている Enterprise サブスクリプションの場合：デフォルトのサブスクリプション ライセンスに応じて、Free または 制限付き無料ライセンス。
デフォルトとは異なるライセンスで一部のユーザーをプロビジョニングする必要がある場合：上記のとおり、すべてのユーザーはデフォルトのライセンスでプロビジョニングされます。ただし、UserType 属性にフルの値を設定します。 この属性で更新されたユーザーは、ユーザー側でダウンタイムが生じることなく、フルライセンスにアップグレードされます。注：SCIM 経由でユーザーグループにメンバーを追加すると、そのメンバーが以前に非アクティブ化または削除されていた場合は再アクティブ化または再作成され、ライセンスはフルライセンスにアップグレードされます。 - 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 API ドキュメント をご覧ください。
Miro は、以下のプロビジョニング機能をサポートしています。
-
新規ユーザーの作成
IdP で Miro のアプリケーションに割り当てられた新規ユーザーは、Enterprise メンバーとして、Miro の Enterprise サブスクリプションに作成されます。IdP グループが Miro のユーザーグループに同期されている場合、そのグループに追加されたユーザーは直接そのユーザーグループのメンバーとして追加されます。
-
ユーザープロフィール更新のプッシュ
サポート対象の属性や変更については、以下をご覧ください。
-
IdP グループをユーザーグループに同期
IdP グループを Miro Enterprise サブスクリプションのユーザーグループに同期して、メンバーシップを自動管理します。SCIM Group は Miro のユーザーグループに直接対応するため、IdP 側での追加・削除操作は即座にユーザーグループのメンバーシップに反映されます。個別のプッシュや上書き処理は不要です。
-
IdP グループ/Miro ユーザーグループからユーザーを削除する（Enterprise サブスクリプションからの削除ではありません。下記参照） IdP グループからユーザーを削除すると、対応する Miro ユーザーグループからただちに削除されます。これはユーザーをユーザーグループから削除するだけです。チームや組織からは削除されません。ボードの所有権は移転されず、ライセンスも変更されません。ユーザーグループには最終管理者の制限はなく、すでにメンバーでないユーザーを削除しても何も起こりません。
-
ユーザーの非アクティブ化
ユーザーを非アクティブ化/削除するか、IdP でユーザーのアプリケーションへのアクセス権を無効にすると、ユーザーは Miro Enterprise プラン内で非アクティブ化されます。ユーザーの状態（およびユーザーのセクション）はアクティブから非アクティブに移行し、ライセンスの消費が停止します。非アクティブ化のみでは、ユーザーのユーザーグループ所属やボードの所有権の割り当ては変更されません。
ユーザーの削除は Enterprise サブスクリプションからはデフォルトではサポートされていません。ただし、API を使用して手動で機能を追加することで、ユーザーを非アクティブ ステータス。 このシナリオでは、コンテンツはチームメンバーに再割り当てされます。 自動的に再割り当てされたコンテンツの所有権をどの管理者が取得するかは指定できませんが、これはMiro の設定でユーザーを手動で非アクティブ化するときに設定できます。 ユーザーをユーザーグループから削除しても（上記参照）、それだけでコンテンツの再割り当ては発生しません。
-
ユーザーの再アクティブ化
ユーザーが以前にプロビジョニングされ、非アクティブ化されていた場合、アプリケーションにユーザーを再度割り当てるか、IdP でユーザープロフィールを再アクティブ化すると、Miro Enterprise サブスクリプションでそのユーザーが再アクティブ化されます。
-
支払いグループの割り当てを自動化する
SCIM を使用して、新規ユーザーを 支払いグループ に自動的に割り当てます。ID プロバイダー（IdP）が設定されたら、コストセンターを支払いグループにリンクしてください。これにより、これらのコストセンターの現在および将来のユーザーが、適切な支払いカテゴリーに自動的に分類されます。
-
ボードとスペースをグループと共有する Miro のユーザーグループは Miro 全体で使用される同じ権限モデルに組み込まれているため、IdP と同期されたユーザーグループと直接ボードやスペースを共有でき、メンバーを個別に追加する必要はありません。
-
コメントでグループを@メンションする ボードのコメントでユーザーグループを@メンションすると、そのメンバー全員に一度に通知されます。
- プログラムでグループを管理する IdP の同期とは独立して、User Groups API を使用してユーザーグループを直接作成、更新、削除できます。
直接 Delete API コールを送信することにより、Enterprise プランからユーザーを削除することもできます。詳しくは こちら の資料をご覧ください。 ただし、ユーザーを削除できるのは直接コールのみです。 DeleteイベントがID ソリューションによって起動された場合は、非アクティブ化のリクエストとして扱われます。
対応している属性
注：メールアドレス（プライマリパラメータ/一意の識別子/ユーザー名）は、Miro が必要とする唯一の値であり、メール形式である必要があります。メールアドレスの更新は、すでに同期済みのユーザーに対してのみ可能です — 最初の同期は IdP と Miro のメールアドレスが一致しているときに行う必要があります。そうでない場合、Miro はユーザーを認識せず、新しいメールアドレスの下に重複した Miro プロフィールが作成されます。メールアドレスの更新は割り当てリストではなく、ユーザーの IdP のプロフィールで行ってください。他の属性とは異なり、ユーザーのメールアドレスを更新すると通知が送信されます：旧メールアドレスと新メールアドレスの両方に、新しいメールアドレスで Miro にログインするよう知らせるメールが届きます。
| 属性名 | SCIM 属性（クレーム） |
|---|---|
| メールアドレス | ユーザー名。必須で、メール形式である必要があります |
| 以下のリストの属性は必須ではなく、存在すれば受け入れます（Miro に送信された他の属性は無視されます）。 | |
| フルネーム | displayName; formatted; givenName + " " + familyName; userName |
| ユーザー種別 | userType — サポート値："Full" |
| アクティブ | 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。ダウンロード可能な最大ファイルサイズは 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 型です。非数値の値は無視されます。 |
⚠️ パスワードは変更できません。また、当面は対応予定はありませんのでご了承ください。 ⚠️ 非アクティブ化されたユーザー に対しては、Username、UserType、roles.value の更新はできません。
属性は全て、エクスポートされた CSV ユーザーリストに表示され、アクティブなユーザー セクションからダウンロードできます。
SCIM の設定
ステップ 1：Miro の SCIM オプションを有効にする
Miro Enterprise プランで SCIM を有効にするには、会社の設定 > Enterprise インテグレーション、で SCIM プロビジョニング機能を有効にします。そこで、IdP を構成するためのベース URL と API トークンを入手できます。
ステップ 2：IdP の設定
この設定は、ご利用の IdP によって異なります。Miro はあらかじめ設定された Okta と Entra ID に対応していますが、SCIM の設定が可能であれば任意の IdP を使用できます。
OKTA - 設定手順は こちら をご覧ください。
Entra ID - 設定手順は こちら をご覧ください。
新しいトークンを生成する
- Company の設定 > Enterprise インテグレーション. に移動します。
- SCIM プロビジョニング のセクションで、新しいトークンを生成するをクリックします。
- 新しい SCIM トークンの生成 画面で、生成をクリックします。
- 新しいトークンを生成したら、IdP プロバイダーで新しいトークンを構成する必要があります。
起こり得る問題と解決方法
1. 許可リストのエラーにより、ユーザーがプロビジョニングされません。
ユーザーのドメインアドレスがセキュリティー設定の許可リストに追加されていることを確認してください。
2. ある ID ソリューション（IdP1）でエンドユーザーを認証しながら、別の ID ソリューション（IdP2）を介して SCIM を有効にしたい場合、次の 2 つの条件を満たすことで可能です。
- IdP2 がベアラートークンを使用して API コールを実行できること。
- 両方の ID プロバイダーが同期していること（つまり、SCIM でプロビジョニングされたユーザーが IdP1 にも存在し、Miro で認証できること）。
SCIM エラーの詳細はドキュメントをご覧ください。問題が解決しない場合は、Miro のサポートチームにお問い合わせください。