SCIM（レガシー ドキュメンテーション）

System for cross-domain identity management（SCIM）を使うと、Miro と IdP 間のユーザーのプロビジョニングおよび管理を自動化できます。

Available for: Enterprise プラン
Set up by: 会社の管理者

重要な注意点

• 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 側で Team1 のメンバーであり、あなたの IdP がそのユーザーを Team2 に追加する更新を送信した場合、Team1 のステータスは影響を受けません。 
  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 メンバーとして作成されます。IdP のグループが同名の Miro チームに同期され、そのグループに追加されたユーザーは、チームメンバーとしてそのチームに追加されます。
• ユーザープロフィール更新のプッシュ
  対応する属性と変更については、以下を参照してください。
   
• 同期とプッシュIdP グループ
  同期してIdP グループとそのメンバーを Miro Enterprise サブスクリプションのチームに同期し、ユーザーのメンバーシップを自動管理します。継続的な同期では、同期された Miro チームに対して IdP グループのユーザーに関する特定の更新が送信されます。一方、プッシュは IdP グループを信頼できる情報源としてチームの状態を上書きします（Miro 側で会社の管理者が手動で変更していた場合）。
   
• IdP グループと Miro チームの名前を切り離す
  Miro は名前によって IdP グループと Miro チームを同期するので、名前は完全に一致している必要があります。ただし、最初の同期実行後は、いずれか 1 つ、または両方に任意の名称を付けることができるようになります。切り離しの例はこちらをご覧ください。
• IdP グループ/チームからのユーザー削除（Enterprise サブスクリプションからの削除ではありません。下記参照）
  IdP グループからユーザーを削除すると、同期された Miro チームからも削除されます（次回のグループプッシュ時）。
• ユーザーを非アクティブ化
  ユーザーを非アクティブ化／削除、またはアプリケーションへのアクセスをIdPで無効にすると、非アクティブ化されます。Miro Enterprise プランでは、状況に応じて、非アクティブ化されたユーザーのコンテンツは最も古いチームの管理者に再割り当てされる場合があります:
  - ユーザーをIdP側で非アクティブ化する一方、Miro アプリへの割り当ては維持する場合、Miro 側でのチームメンバーシップは変更されず、コンテンツは再割り当てされません。ユーザーは アクティブ から 非アクティブ の状態に移るだけで（ユーザーのセクションも同様）、ライセンスの消費は停止します。
  - 非アクティブ化をトリガーするには、IdP でユーザーを削除するか、Miro アプリから割り当てを解除することで、ユーザーがいくつかの同期された チームに所属している場合、さらにそのユーザーはそれらの Miro チームからも削除され、当該チーム内のコンテンツは最も古いチームの管理者に再割り当てされます. 
  - 無効化を削除する ユーザーを IdP または 割り当てを解除する Miro アプリから行い、ユーザーがいずれの同期済みの チームに所属していない場合、ユーザーのチーム所属は変更されず、コンテンツも再割り当てされません. 
  ユーザーの削除は Enterprise サブスクリプションからは対応していませんデフォルトでは。ただし、手動で API を使用して手動で機能を追加し、ユーザーを 非アクティブ ステータスに設定するのではなく、サブスクリプションから完全に削除できます。この場合、コンテンツは該当するチームメンバーに再割り当てされます。自動的に再割り当てされたコンテンツの所有権をどの管理者が取得するかを設定することはできません。ただし、Miro の設定でユーザーを手動で非アクティブ化した場合は、これを設定できます。
• ユーザーを再アクティブ化
  アプリケーションにユーザーを再度割り当てるか、IdPでユーザープロフィールを再アクティブ化すると、以前にプロビジョニングされ、非アクティブ化されていた場合、Miro Enterprise サブスクリプションでユーザーが再アクティブ化されます。
• 支払いグループの割り当てを自動化 
  SCIM を使用して、新規ユーザーを 支払いグループに自動的に割り当てます。ID プロバイダー（IdP）が設定されたら、コストセンターを支払いグループにリンクします。これにより、これらのコストセンターの現在および将来のユーザーが、適切な支払いカテゴリーに自動的に分類されます。

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

サポートされている属性

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

⚠️ パスワードは変更できません。また、当面は対応予定はありませんのでご了承ください。
⚠️ 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 ー 設定手順は こちらをご覧ください。 

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

1. 次の場所へ移動します：会社 の設定 > Enterprise インテグレーション。

2. SCIM プロビジョニング のセクションで、 新しいトークンを生成するをクリックします。 

2. 新しい SCIM トークンの生成画面で、生成をクリックします。 

3. 新しいトークンを生成したら、IdP プロバイダーにそのトークンを設定する必要があります。 

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

1. 許可リストエラーが原因でユーザーがプロビジョニングされない。

ユーザーのドメインアドレスがセキュリティー設定の許可リストに追加されていることを確認してください。 

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

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