SCIM – Miro Help Center

クロスドメイン ID 管理システム（SCIM）では、Miro とお使いのアイデンティティプロバイダー（IdP）間のユーザーのプロビジョニングと管理を自動化できます。

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

新しい同期モデル

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

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

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

重要事項

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

Miro の SCIM 運用ルール

SCIM 同期による変更は、主に新たに割り当てられたユーザーに適用されます。メンバーシップの変更は直接かつ即時に適用されます。追加、削除、または置換操作が SCIM グループのメンバーに対して行われると、そのメンバーは対応する Miro のユーザーグループに追加または削除され、別途「プッシュ」手順は不要です。例えば次のようなケースです。a) ユーザーが Miro 側のユーザーグループ A のメンバーであり、お使いの IdP がそのユーザーをユーザーグループ B に追加する更新を送信した場合、ユーザーグループ A のメンバーシップは影響を受けません — 単にユーザーはユーザーグループ B のメンバーにもなります。b) お使いの IdP が User1 に変更を含む更新を送信した場合、他のユーザーグループのメンバーは影響を受けません。
SCIM でプロビジョニングされたすべてのユーザーには、サブスクリプションのデフォルトのライセンスが割り当てられます：a）フレキシブルライセンスプログラムを使用しない Enterprise サブスクリプションの場合：Collaborate または Full（レガシー）ライセンス。サブスクリプションのライセンスがなくなると、ユーザーは制限付き無料ライセンスでプロビジョニングされ始めます。b）フレキシブルライセンスプログラムが有効になっている Enterprise サブスクリプションの場合：デフォルトのサブスクリプションライセンスに応じて、Free または制限付き無料ライセンス。
デフォルトとは異なるライセンスで一部のユーザーをプロビジョニングする必要がある場合：上記のとおり、すべてのユーザーはデフォルトのライセンスでプロビジョニングされます。ただし、UserType 属性に Collaborate またはフル（レガシー）の値を指定します。この属性で更新されたユーザーは、ユーザー側でダウンタイムが発生することなく、Collaborate またはフル（レガシー）ライセンスにアップグレードされます。注：SCIM 経由でユーザーグループにメンバーを追加すると、そのメンバーが以前に非アクティブ化または削除されていた場合、再アクティブ化または再作成され、ライセンスが Collaborate またはフル（レガシー）にアップグレードされます。
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 アプリケーションに割り当てられた新しいユーザーは、Miro Enterprise サブスクリプションに Enterprise メンバーとして作成されます。Miro のユーザーグループに同期された IdP グループに追加されたユーザーは、そのユーザーグループに直接メンバーとして追加されます。
ユーザープロフィール更新のプッシュ
サポート対象の属性や変更については、以下をご覧ください。
IdP グループをユーザーグループに同期
IdP グループを Miro Enterprise サブスクリプションのユーザーグループに同期して、メンバーシップを自動管理できます。SCIM Group は Miro のユーザーグループに直接対応するため、IdP 側での追加・削除操作はユーザーグループのメンバーシップに即時反映されます。別途プッシュや上書きの手順は不要です。
IdP グループ／Miro ユーザーグループからユーザーを削除する（Enterprise サブスクリプションからの削除ではありません。下記参照） IdP グループからユーザーを削除すると、対応する Miro のユーザーグループから即時に削除されます。これはユーザーをユーザーグループからのみ削除する操作です。チームや組織からは削除されません。ボードの所有権は移譲されず、ライセンスも変更されません。ユーザーグループには最後の管理者制限はなく、既にメンバーでないユーザーを削除しても処理は行われません。
ユーザーの非アクティブ化
ユーザーを非アクティブ化／削除するか、IdP でユーザーのアプリケーションへのアクセス権を無効にすると、ユーザーは Miro Enterprise プランにおいて非アクティブ化されます。ユーザー（およびユーザーのセクション）の状態がアクティブから非アクティブに切り替わり、ライセンスの消費が停止します。非アクティブ化のみでは、ユーザーのユーザーグループへの所属は変更されず、ボードの所有者の再割り当ても行われません。

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

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

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

対応している属性

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

属性名	SCIM 属性（クレーム）
メールアドレス	ユーザー名。必須で、メール形式である必要があります
以下のリストの属性は必須ではなく、存在する場合は Miro によって受け入れられます（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 型; 数値以外の値は無視されます。

⚠️ パスワードは変更できません。また、当面は対応予定はありませんのでご了承ください。 ⚠️ 非アクティブ化されたユーザーに対しては、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 ーこちらの設定手順をご覧ください。

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

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

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

1. 許可リストのエラーによりユーザーがプロビジョニングされません。
ユーザーのドメインアドレスがセキュリティー設定の許可リストに追加されていることを確認してください。

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

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

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

このセクションの記事