クロスドメインID管理(SCIM)のシステムにより、MiroとIDプロバイダー(IdP)間のユーザー管理とプロビジョニングと管理を自動化することができます。
利用可能なプラン： Enterprise
設定者：会社の管理者
重要事項
-
自動プロビジョニングの設定開始前に、SAML ベースの SSO が正しく設定され、Enterprise プランで正常に機能していることが必要です。
SAML SSO の設定ガイドをご覧ください。 -
Miroチームとのグループの同期はオプションです。
オプションで、IdPグループをMiroのチームと同期させることができます。ただし、IdPグループが意図せず、または一時的に削除され、そのグループのすべてのユーザーがMiroで非アクティブになり、ボードとスペースの再割り当てが発生する問題を回避するため、IdPグループをMiroチームと同期しないでください。Teams は Teams API を使用して作成および管理できます。SCIM APIを使用してグループを管理する方法の詳細については、Miro Developersを参照してください。 -
SCIM における電子メールアドレスの変更には、以下の検証ルールが含まれます：
- 管理ユーザーチェック：ユーザーの現在のドメインが、SCIMリクエストを開始した組織によってクレームされていない場合、電子メールの更新はブロックされ、400エラーがスローされます。
- ターゲット電子メールドメインの検証：ターゲットの電子メールドメインがSCIMリクエストを開始した組織以外の組織によって主張されている場合、電子メールの更新はブロックされ、400エラーがスローされます。ターゲットの電子メールドメインがSCIM要求を開始した組織によって主張されている場合、電子メールの確認は必要なく、電子メールの更新が許可されます。監査ログは、ユーザーがメンバーである各組織の更新を記録します。
-
ドメイン制御とSSO：電子メールの更新は、ドメイン制御（IDC）またはシングルサインオン（SSO）によるドメイン認証に基づいて許可されます。ターゲットメールドメインが、CDまたはSSOによって開始組織によって検証された場合、更新を続行できます。
SCIM電子メール変更検証ワークフローの図
Miro の SCIM 運用ルール
- SCIM 同期による変更は、主に新たに割り当てられたユーザーに適用されます。すでにサブスクリプションに参加しているユーザーのステータスは補足されますが、グループ/チームレベルで変更が適用されるため、上書きされない場合があります。例えば
a) ユーザーがMiro側でTeam1のメンバーであり、IDPがそのユーザーをTeam2に追加する更新を送信した場合、Team1のステータスは影響を受けません。
b) IDPがUser1に変更を含む更新を送信した場合、他のチームメンバーは影響を受けません。対応機能 > グループの同期とプッシュで説明しているように、一括してチームのステータスを上書きし、すべてのユーザーを再同期するには、新たなプッシュを試みてください。
- SCIM の下でプロビジョニングされたすべてのユーザーには、サブスクリプションのデフォルトのライセンスが割り当てられます：
a) フレキシブル ライセンス プログラムを使用しない Enterprise サブスクリプションの場合：フル ライセンス。サブスクリプションのライセンスがなくなると、制限付き無料ライセンスでユーザーのプロビジョニングが開始されます。
b）フレキシブル ライセンス プログラムが有効になっている Enterprise サブスクリプションの場合：デフォルトのサブスクリプション ライセンスに応じて、無料または制限付き無料ライセンス。
- 一部のユーザーをデフォルトとは異なるライセンスでプロビジョニングする必要がある場合：
上記のように、すべてのユーザはデフォルトのライセンスでプロビジョニングされます。ただし、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 レート制限レベル 4 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 メンバーとして作成されます。同じ名称の Miro のチームに同期されたユーザーグループに追加されたユーザーは、チームメンバーとしてチームに追加されます。 -
ユーザープロファイル更新のプッシュ
対応する属性と変更については、以下を参照してください。
-
グループの同期とプッシュ
IdP グループとそのメンバーを Miro Enterprise サブスクリプションのチームに同期し、ユーザーのメンバーシップを自動管理します。継続的な同期により、同期された Miro のチームにはグループのユーザーに関する特定の更新情報が送信され、また、プッシュ通知により、グループを信頼できる情報源とするようチームの状態が上書きされます（会社の管理者による手動の変更が Miro 側であった場合）
-
グループ/チーム名の分離
Miro は名前によってグループとチームを同期させるので、名前は完全に一致している必要があります。ただし、最初の同期実行後は、いずれか 1 つ、または両方に任意の名称を付けることができるようになります。切り離しの例については、こちらをご覧ください。 -
グループ / チームからユーザーを削除（Enterprise サブスクリプションからの削除とは別。以下参照。）
グループからユーザーを削除すると、同期された Miro チームから（次のグループプッシュ時に）ユーザーを削除することになります。 -
ユーザーを非アクティブにする
ユーザーを非アクティブ化 / 削除、または IdP でユーザーのアプリケーションへのアクセス権を無効にすると、ユーザーは Miro Enterprise プランにおいて非アクティブ化されます。ユーザーを非アクティブ化すると、状況に応じて、非アクティブ化されたユーザーのコンテンツは最も古いチームの管理者に再割り当てされる場合があります。
ー IdP 側でユーザーを非アクティブ化する一方、Miro アプリへの割り当ては維持する場合、そのユーザーの Miro 側でのチームのメンバーシップは変更されず、コンテンツは再割り当てされません。ユーザーは、アクティブから非アクティブの状態に切り替わるだけで（ユーザーのセクションも変更）、ライセンスの消費は停止します。
ー 同期されたチームのメンバーである IDP 内のユーザーを削除、あるいは Miro アプリから割り当てを解除して非アクティブ化する場合、ユーザーは同期された Miro チームからも削除され、該当チーム内のコンテンツは最も古いチームの管理者に再割り当てされます。
ー ユーザーが同期されたチームのメンバーではない場合に IDP 内のユーザーを削除するか、Miro アプリから割り当てを解除して非アクティブ化した場合、ユーザーのチームメンバーシップは変更されず、コンテンツは再割り当てされません。
Enterprise サブスクリプションからのユーザーの削除は、デフォルトでは対応していませんが、API を使用して手動で機能を追加し、ユーザーを非アクティブ状態に設定するのではなく、サブスクリプションから完全に削除することができます。このシナリオでは、コンテンツは、チームメンバーに再割り当てされます。自動的に再割り当てされたコンテンツに対して所有権を取得する管理者を設定することはできません。ただし、Miro の設定でユーザーを手動で非アクティブ化する場合には、設定することができます。
-
ユーザーを再度アクティブ化する
アプリケーションにユーザーを再度割り当てるか、IdP におけるユーザープロフィールを再アクティブ化すると、以前にプロビジョニングされ、非アクティブ化されていた場合、Miro Enterprise サブスクリプションでユーザーが再アクティブ化されます。 -
支払いグループ割り当ての自動化
SCIM を使用して新規ユーザーを支払いグループに自動で割り当てます。ID プロバイダー（IdP）が設定されたら、コストセンターを支払いグループにリンクします。 これにより、これらのコストセンターの現在および将来のユーザーが、適切な支払いカテゴリーに自動的に分類されます。
直接 Delete API コールを送信することにより、Enterprise プランからユーザーを削除することもできます。こちらの資料をご覧ください。ただし、ユーザーを削除できるのは直接コールのみです。ID ソリューションが起動した削除イベントは、非アクティブ化のリクエストとして扱われます。
対応している属性
⚠️ 以下にご注意ください
ー Miro が必要とする値は、電子メール/ プライマリパラメータ / 固有識別子 /ユーザー名のみであり、メールアドレスの形式でなければなりません。
ー メールの更新は、すでに同期されたユーザーに対してのみ可能です。つまり、IdP と Miro のメールアドレスが同じ場合、最初の同期を実行しなければなりません。そうしないと、Miro はユーザーを認識せず、新しいメールアドレスの下に重複した Miro プロフィールが作成されることになります。
ー メールの更新は、ユーザーの IdP プロフィールで行われ、割り当てリストには表示されません。
ー 他の属性とは異なり、ユーザーのメールアドレスを更新すると、ユーザーに通知が届きます。古いメールアドレスと新しいメールアドレスには、Miro にログインするために新しいメールアドレスを使用することをユーザーに知らせるメッセージが届きます。
⚠️ パスワードは変更できません。また、当面は対応予定はありませんのでご了承ください。
⚠️ 非アクティブ化されたユーザーに対しては、Username、UserType、roles.value の更新はできません。
属性は全て、エクスポートされた CSV ユーザーリストに表示され、アクティブなユーザーのセクションからダウンロードできます。
altdownload_as_CSV_in_company_settings.jpg
ユーザーリストをダウンロードするオプション
SCIM の設定
ステップ 1：MiroでSCIMオプションを有効にします。
Miro Enterprise プランの SCIM を有効にするには、[会社の設定] > [Enterprise のインテグレーション] で、SCIM プロビジョニング機能を有効にします。そこで、IdP を構成するベース URL と API トークンを入手することができます。
Miro での SCIM 設定
ステップ 2：アイデンティティ・プロバイダの設定
この設定は、使用する ID プロバイダーによって異なります。Miroは設定済みのOktaとEntra IDをサポートしていますが、SCIMを設定できる限り、お好きなIDプロバイダを使用できます。
OKTA ー こちらの設定手順をご覧ください。
Entra ID - セットアップ手順をご覧ください。 こちら.
新しいトークンを生成する
1. 会社の設定 > Enterprise インテグレーションに移動します。
2. SCIM Provisioningセクションで、 Generate new tokenをクリックします。
Miro での SCIM 設定
2. 新しい SCIM トークンの生成ウィンドウで、生成をクリックします。
3.新しいトークンを生成したら、IDP プロバイダで新しいトークンを構成する必要があります。
起こり得る問題と解決方法
1. allowlist エラーが原因でユーザがプロビジョニングされません。
Okta の IDプロバイダのエラー例
セキュリティー設定の許可リストに、ユーザーのドメインアドレスが追加されていることを確認してください。
2. 2. ある ID ソリューション（IdP1）でエンドユーザーを認証しながら、別の ID ソリューション（IdP2）を介して SCIM を有効にしたい場合、次の 2 つの条件を満たすことでそれが可能になります。
- IdP2 が、ベアラートークンを使用して、API コールを行うことができる。
- 両方の ID プロバイダーが同期している（つまり、SCIM でプロビジョニングされたユーザーは IdP1 にも存在するので、Miro で認証することができる）。
詳細については、Miro のサポートチームにご連絡ください。