Microsoft Entra B2B を使用して基幹業務アプリケーションに外部ユーザーをオンボードする

  • [アーティクル]

アプリケーション開発者は、Microsoft Entra B2B を使用して、基幹業務 (LOB) アプリケーション内に外部ユーザーをオンボードして共同作業を行うことができます。 多くの Office 365 アプリケーションの [共有] ボタンと同様に、アプリケーション開発者は、Microsoft Entra ID と統合されている LOB アプリケーション内にワンクリックの招待エクスペリエンスを作成できます。

利点は次のとおりです。

  • シンプルかつ簡単なユーザーのオンボードと LOB アプリケーションへのアクセス。ユーザーは、数ステップでアクセス権を取得できます。

  • 外部ユーザーが独自の ID を使用してシングル サインオン (SSO) を実行できるようにします。

  • Microsoft Entra ID への外部 ID の自動プロビジョニング。

  • Microsoft Entra の条件付きアクセスとテナント間アクセス ポリシーを適用して、多要素認証の要求などの認可ポリシーを適用します。

統合フロー

LOB アプリケーションを Microsoft Entra B2B と統合するには、次のパターンに従います。

Screenshot shows the integration of LOB applications.

Step 説明
1. エンド ユーザーが LOB アプリケーション内で招待をトリガーし、外部ユーザーのメール アドレスを提供します。 アプリケーションがユーザーが既に存在するかどうかをチェックして、存在しない場合は手順 2 に進みます
2. アプリケーションが、ユーザーの代わりに Microsoft Graph API に POST を送信します。 手順 1 で定義されたリダイレクト URL と外部ユーザーのメール アドレスを提供します。
3. Microsoft Graph API が、ゲスト ユーザーを Microsoft Entra ID にプロビジョニングします。
4. Microsoft Graph API が、API 呼び出しの成功/失敗状態を返します。 成功した場合、応答には Microsoft Entra ユーザー オブジェクト ID と、招待されたユーザーのメール アドレスに送信される招待リンクが含まれます。 必要に応じて、Microsoft メールを抑制し、独自のカスタム メールを送信できます。
5. (省略可能) 招待されたユーザーにさらに属性を書き込む場合、または招待されたユーザーをグループに追加する場合、アプリケーションが Microsoft Graph API に対する追加の API 呼び出しを行います。
6. (省略可能) Microsoft Graph API が、Microsoft Entra ID に必要な更新プログラムを作成します。
7. (省略可能) Microsoft Graph API が、成功/失敗の状態をアプリケーションに返します。
8. アプリケーションが、ユーザーのオブジェクト ID 属性を不変 ID として使用して、ユーザーを独自のデータベース/バックエンド ユーザー ディレクトリにプロビジョニングします。
9. アプリケーションが、エンド ユーザーに成功/失敗状態を表示します。

LOB アプリケーションにアクセスするために割り当てが必要な場合は、招待されたゲスト ユーザーも、適切なアプリケーション ロールを持つアプリケーションに割り当てる必要があります。 これは、招待されたゲストをグループに追加する別の API 呼び出し (手順 5 から 7) として、または Microsoft Entra 動的グループを使用してグループ メンバーシップを自動化することで行うことができます。 動的グループを使用する場合、アプリケーションによる別の API 呼び出しは必要ありません。 ただし、ユーザーの招待直後にユーザーをグループに追加する場合と比べて、グループ メンバーシップはすぐには更新されません。

手順 1: 外部ユーザーが既に存在するかどうかをチェックする

外部ユーザーが以前に招待され、オンボードされている可能性があります。 LOB アプリケーションは、ユーザーがディレクトリに既に存在するかどうかをチェックする必要があります。 多くのアプローチがありますが、最も簡単なのは、Microsoft Graph API への API 呼び出しを行い、招待元のユーザーに一致する可能性のあるものを提示し、その中から選択できるようにすることです。

次に例を示します。

Application Permission: User.read.all

GET https://graph.microsoft.com/v1.0/users?$filter=othermails/any(id:id eq 'userEmail@contoso.com')

応答でユーザーの詳細を受け取った場合、そのユーザーは既に存在しています。 招待元のユーザーに返されたユーザーを提示し、アクセス権を付与する外部ユーザーを選択できるようにする必要があります。 招待の手順に進むのではなく、適切な API 呼び出しを行うか、他のプロセスをトリガーして、このユーザーにアプリケーションへのアクセス権を付与する必要があります。

手順 2: 招待を作成して送信する

外部ユーザーがまだディレクトリに存在しない場合は、Microsoft Entra B2B を使用してユーザーを招待し、Microsoft Entra テナントにオンボードできます。 アプリケーション開発者は、Microsoft Graph API への招待要求に含める内容を決定する必要があります。

少なくとも、次のことを実行する必要があります。

  • エンド ユーザーに対して、外部ユーザーのメール アドレスの入力を求める。

  • 招待 URL を決定する。 この URL は、招待されたユーザーが認証して B2B 招待を利用した後にリダイレクトされる場所です。 URL には、アプリケーションの汎用ランディング ページを指定することも、エンド ユーザーが招待をトリガーした場所に基づいて LOB アプリケーションによって動的に決定することもできます。

招待要求に含めることを検討すべき追加のフラグおよび属性:

  • 招待されたユーザーの名前を表示する。
  • 既定の Microsoft 招待メールを使用するか、既定のメールを使用せずに独自のメールを作成するかを決定する。

アプリケーションは、必要な情報を収集し、含めるその他のフラグや情報を決定したら、Microsoft Graph API 招待マネージャーに要求を POST する必要があります。 アプリケーションの登録に Microsoft Entra ID の適切なアクセス許可があることを確認します。

次に例を示します。

Delegated Permission: User.Invite.All

POST https://graph.microsoft.com/v1.0/invitations  
Content-type: application/json

{ 
"invitedUserDisplayName": "John Doe",  
"invitedUserEmailAddress": "john.doe@contoso.com",  
"sendInvitationMessage": true,  
"inviteRedirectUrl": "https://customapp.contoso.com"  
}

Note

招待の JSON 本文で使用可能なすべてのオプションの一覧を確認するには、招待リソースの種類 - Microsoft Graph v1.0 に関する記事を参照してください。

アプリケーション開発者は、Microsoft Entra のセルフサービス サインアップまたはエンタイトルメント管理アクセス パッケージを使用して、外部ユーザーをオンボードすることもできます。 事前に定義されたセルフサービス サインアップ URL またはアクセス パッケージ URL を含むカスタム メールをトリガーする [invitation](招待) ボタンを LOB アプリケーションに作成できます。 その後、招待されたユーザーはセルフサービスでオンボードし、アプリケーションにアクセスします。

手順 3: Microsoft Entra ID に他の属性を書き込む (省略可能)

重要

ディレクトリ内のユーザーを更新するためのアクセス許可をアプリケーションに付与することは、高い特権が必要なアクションです。 これらの高い特権のアクセス許可をアプリケーションに付与する場合は、LOB アプリをセキュリティで保護して監視する手順を実行する必要があります。

組織または LOB アプリケーションは、トークンの要求出力や詳細な認可ポリシーなどで将来使用するためにより詳しい情報を保存する必要がある場合があります。 アプリケーションは、別の API 呼び出しを行って、外部ユーザーが Microsoft Entra ID 内に招待/作成された後に外部ユーザーを更新することができます。 これを行うには、アプリケーションに追加の API アクセス許可が必要であり、Microsoft Graph API への追加の呼び出しが必要になります。

ユーザーを更新するには、招待の API 呼び出しの応答で受け取った、新しく作成されたゲスト ユーザーのオブジェクト ID を使用する必要があります。 これは、存在チェックまたは招待からの API 応答内の ID 値です。 任意の標準属性または作成したカスタム拡張属性に書き込むことができます。

次に例を示します。

Application Permission: User.ReadWrite.All

PATCH https://graph.microsoft.com/v1.0/users/<user's object ID> 
Content-type: application/json

{ 
"businessPhones": [ 
        "+1 234 567 8900" 
    ], 
"givenName": "John" 
"surname": "Doe", 
"extension_cf4ff515cbf947218d468c96f9dc9021_appRole": "external" 
}

詳細については、ユーザーを更新する - Microsoft Graph v1.0 に関する記事を参照してください。

手順 4: 招待されたユーザーをグループに割り当てる

Note

アプリケーションへのアクセスにユーザー割り当てが不要な場合は、この手順をスキップできます。

アプリケーションへのアクセスやロールの割り当てのために Microsoft Entra ID でのユーザー割り当てが必要な場合は、ユーザーをアプリケーションに割り当てる必要があります。そうしないと、認証が成功してもユーザーはアクセス権を取得できません。 これを実施するには、別の API 呼び出しを行って、招待された外部ユーザーを特定のグループに追加する必要があります。 グループをアプリケーションに割り当て、特定のアプリケーション ロールにマップできます。

次に例を示します。

アクセス許可: エンタープライズ アプリケーションにグループ アップデーター ロールまたはカスタム ロールを割り当て、ロールの割り当てのスコープをこのアプリケーションが更新する必要があるグループのみに限定します。 または、Microsoft Graph API で group.readwrite.all アクセス許可を割り当てます。

POST https://graph.microsoft.com/v1.0/groups/<insert group id>/members/$ref 
Content-type: application/json

{ 
"@odata.id": "https://graph.microsoft.com/v1.0/directoryObjects/<insert user id>" 
}

詳細については、メンバーを追加する - Microsoft Graph v1.0 に関する記事を参照してください。

または、Microsoft Entra 動的グループを使用することもできます。これを使用すると、ユーザーの属性に基づいてユーザーをグループに自動的に割り当てることができます。 ただし、エンド ユーザーのアクセスが時間的な制約を受ける場合は、動的グループの設定に最大 24 時間かかる可能性があるため、このアプローチは推奨されません。

動的グループを使用する場合は、別の API 呼び出しで明示的にユーザーをグループに追加する必要はありません。 userType、メール アドレス、カスタム属性などの使用可能な属性に基づいて、ユーザーをグループのメンバーとして自動的に追加する動的グループを作成します。 詳細については、動的グループの作成または編集、および状態の取得に関する記事を参照してください。

手順 5: 招待されたユーザーをアプリケーションにプロビジョニングする

招待された外部ユーザーが Microsoft Entra ID にプロビジョニングされると、Microsoft Graph API は、オブジェクト ID やメール アドレスなどの必要なユーザー情報を含む応答を返します。 その後、LOB アプリケーションは、ユーザーを独自のディレクトリまたはデータベースにプロビジョニングできます。 アプリケーションの種類と、アプリケーションが使用する内部ディレクトリの種類によって、このプロビジョニングの実際の実装は異なります。

Microsoft Entra ID とアプリケーションの両方で外部ユーザーがプロビジョニングされると、LOB アプリケーションは、招待を開始したエンド ユーザーにプロセスが成功したことを通知できるようになります。 招待されたユーザーは、招待元の組織がオンボードして追加の資格情報を発行しなくても、自分の ID で SSO を取得できます。 Microsoft Entra ID は、条件付きアクセス、Microsoft Entra 多要素認証、リスクベースの Identity Protection などの承認ポリシーを適用できます。

その他の考慮事項

  • LOB アプリケーション内で適切なエラー処理が実行されていることを確認します。 アプリケーションは、各 API 呼び出しが成功したことを検証する必要があります。 失敗した場合は、追加の試行を行うか、エンド ユーザーにエラー メッセージを表示することが適切です。

  • 外部ユーザーの招待後に LOB アプリケーションに外部ユーザーを更新させる必要がある場合、アプリケーションがユーザーを更新してスコープを動的管理単位に割り当てることを許可するカスタム ロールを付与することを検討してください。 たとえば、usertype = guest のすべてのユーザーを含む動的管理単位を作成できます。 外部ユーザーが Microsoft Entra ID にオンボードされた後、管理単位に追加されるまでに時間がかかります。 そのため、LOB アプリケーションはしばらくしてからユーザーの更新を試みる必要があり、遅延がある場合は複数回の試行が必要になる可能性があります。 このような遅延はありますが、これは、LOB アプリケーションにディレクトリ内のユーザーを更新するためのアクセス許可を付与せずに外部ユーザーを更新できるようにするための最善のアプローチです。