クロスドメイン ID 管理システム(SCIM)を使用すると、Miro と IdP の間のユーザーのプロビジョニングと管理を自動化できます。
利用可能: Enterprise プラン
設定者:会社の管理者
重要な注意点
-
自動プロビジョニングの設定を開始する前に、SAML ベースの SSO が正しく設定され、Enterprise プランで正常に機能していることが必要です。
SAML SSO の設定ガイドをご覧ください。 -
IdP グループと Miro チームの同期は任意です.
IdP のグループを Miro のチームにリンクして同期することは任意で行えます。IdP を使ってチームを作成したり削除したりすることはできません。チームの作成や管理は、Teams API を使用して行えます。SCIM API を使って IdP グループを管理する方法の詳細は、Miro 開発者向けドキュメント を参照してください。 -
SCIM におけるメールアドレスの変更には、次の検証ルールが適用されます:
- 管理対象ユーザーの確認: ユーザーの現在のドメインが SCIM リクエストを発行している組織によって管理対象ドメインとして登録されていない場合、メールアドレスの更新はブロックされ、400 エラーが返されます。
- 対象メールドメインの検証:対象メールドメインが、SCIM リクエストを開始した組織とは別の組織により所有されている場合、メールアドレスの更新はブロックされ、400 エラーが返されます。対象メールドメインが SCIM リクエストを開始した組織によって所有されている場合、メールアドレスの更新はメール確認なしで許可されます。監査ログには、ユーザーが所属する各組織で更新が記録されます。
-
ドメイン制御と SSO:メールアドレスの更新は、ドメイン制御(IDC)またはシングルサインオン(SSO)によるドメイン検証に基づいて許可されます。もし対象のメールアドレスのドメインがリクエストを開始した組織によって CD または SSO を通じて検証されている場合、更新を実行できます。
SCIM のメール変更検証ワークフローの図
Miro SCIM が適用されるルール
- SCIM 同期による変更は、主に新たに割り当てられたユーザーに適用されます。すでにサブスクリプションに参加しているユーザーのステータスは補足されますが、チームレベルで変更が適用されるため、上書きされない場合があります。例えば次のようなケースです。
a) あるユーザーが Miro 側でチーム 1 のメンバーであり、貴社の IdP がそのユーザーをチーム 2 に追加する更新を送信した場合、チーム 1 のステータスは影響を受けません。
b) 貴社の IdP が送信する更新に User1 への変更が含まれている場合、他のチームメンバーには影響しません。前述の対応機能 > グループの同期とプッシュ で説明しているように、一括してチームのステータスを上書きし、すべてのユーザーを再同期するには、新たなプッシュを試みてください。
- 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 メンバーとして作成されます。同じ名称の Miro チームに同期された IdP グループに追加されたユーザーは、そのチームにチームメンバーとして追加されます。 -
ユーザープロフィール更新のプッシュ
サポート対象の属性と変更については、以下をご覧ください。
-
同期とプッシュ IdP グループ
同期してIdP のグループとそのメンバーを Miro Enterprise サブスクリプションのチームに追加して、ユーザーのメンバーシップを自動管理します。継続的な同期では、同期された Miro のチームにグループのユーザーに関する特定の更新情報が送信され、プッシュ時には、会社の管理者が Miro 側で手動で行った変更がある場合でも、グループを信頼できる情報源としてチームの状態が上書きされます。
-
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)が設定されたら、コストセンターを支払いグループにリンクします。これにより、これらのコストセンターの現在および将来のユーザーが、適切な支払いカテゴリーに自動的に分類されます。
Enterprise プランからユーザーを削除するには、直接の 削除 API コールを送信することでも可能です。ドキュメントはこちらをご覧ください。なお、ユーザーを削除できるのは直接コールのみです。削除イベントは、ID ソリューションによって起動された場合、非アクティブ化のリクエストとして扱われます。
サポートされている属性
⚠️ ご注意:
- メールアドレス / プライマリー パラメーター / 一意の識別子 / ユーザー名) は、Miro が必要とする唯一の値で、メールアドレスの形式である必要があります。
- メールアドレスの更新は、すでに同期済みのユーザーに対してのみ可能です。つまり、最初の同期は IdP と Miro のメールアドレスが同じときに行う必要があり、そうしないと Miro はユーザーを認識せず、新しいメールアドレスで重複した Miro プロフィールが作成されます。
- メールアドレスの更新は、割り当てリストではなく、ユーザーの IdP プロフィールで行う必要があります。
- 他の属性とは異なり、ユーザーの メールアドレス を更新すると通知が送信されます。古いメールアドレスと新しいメールアドレスの両方に、今後は新しいメールアドレスで Miro にログインするようにユーザーに知らせるメールが届きます。
属性名 |
SCIM 属性(クレーム) |
|---|---|
メールアドレス |
ユーザー名. 必須で、メール形式である必要があります |
| 以下のリストの属性は必須ではなく、存在すれば受け入れます(Miro に送信された他の属性は無視されます)。 | |
フルネーム |
displayName; formatted; givenName + " " + familyName; userName |
ユーザー種別 |
userType サポート値: "Full" |
アクティブ |
active サポート値: "true" または "false" |
プロフィール写真 |
photos.^[type=='photo'].value または 画像に対しテキスト URL である必要があります。 サポートされているファイル形式: jpg、jpeg、bmp、png、gif
|
ユーザーの役割 |
roles.^[primary==true].value (Okta) roles[primary eq "True"].value (Entra) サポートされている値: |
従業員番号 |
employeeNumber |
コストセンター |
costCenter |
| 組織 | organization |
| 部門 | division |
| 部署 | department |
マネージャー名 |
manager.displayName |
マネージャー ID |
manager.value 「value」フィールドは SCIM 標準では String 型ですが、 |
⚠️ パスワードは変更できません。また、当面は対応予定はありませんのでご了承ください。
⚠️ ユーザー名、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 - セットアップ手順は こちら。
新しいトークンを生成する
1. 次の順に移動します: Company 設定 > Enterprise integrations.
2. SCIM プロビジョニング セクションで、次をクリックします 新しいトークンを生成する。
2. 「新しい SCIM トークンを生成する」ウィンドウで、生成をクリックします。
3. 新しいトークンを生成したら、IdP プロバイダーに新しいトークンを設定する必要があります。
起こり得る問題とその解決方法
1. 許可リストのエラーにより、ユーザーがプロビジョニングされないことがあります。
ユーザーのドメインアドレスが許可リストに追加されていることを、セキュリティ設定で確認してください。
2. ある ID ソリューション(IdP1)でエンドユーザーを認証しながら、別の ID ソリューション(IdP2)を介して SCIM を有効にしたい場合、次の 2 つの条件を満たすことで可能です:
- IdP2 が、ベアラートークンを使用して、API コールを行うことができる。
- 両方の ID プロバイダーが同期している(つまり、SCIM でプロビジョニングされたユーザーは IdP1 にも存在するので、Miro で認証することができる)。