トークンでのグループ要求とアプリ ロールの構成

トークンでグループ要求とアプリ ロールを構成すると、アプリロールの定義を使用してアプリを構成し、セキュリティ グループをアプリ ロールに割り当てる方法が示されます。そうすることで、最小限の特権でアプリケーションのセキュリティを強化しながら、柔軟性と制御を向上させることができます。

Microsoft Entra ID では、ユーザーの割り当てられたセキュリティ グループ、Microsoft Entra ディレクトリ ロール、配布グループをトークンの要求として送信できます。 このアプローチを使用して、アプリの承認を促進できます。 ただし、Microsoft Entra ID では、トークン内のセキュリティ グループのサポートがトークンのサイズによって制限されます。 ユーザーがあまりに多くのグループのメンバーである場合、トークンにセキュリティ グループはありません。

この記事では、Microsoft Entra セキュリティ グループのサポートを使用してトークン内のユーザー情報を取得する別の方法について説明します。 代わりに、アプリ ロールの定義を使用してアプリを構成し、アプリ ロールにセキュリティ グループを割り当てます。 このゼロ トラストの開発者のベスト プラクティスは、最小限の特権でアプリケーションのセキュリティを強化しながら、柔軟性と制御を向上させます。

承認のためにアプリケーション内で使用できるトークンでグループ要求を構成できます。 トークン内のグループ情報は、トークンを受信したときにのみ最新であることに注意してください。 グループ要求では、次の 2 つのメイン パターンがサポートされます。

• Microsoft Entra オブジェクト識別子 (OID) 属性によって識別されるグループ。
• Active Directory に同期されたグループとユーザーの sAMAccountName または GroupSID 属性によって識別されるグループ。

グループ メンバーシップは、承認の決定を促進できます。 たとえば、次の例は、トークン内のいくつかの要求を示しています。 グループの要求とロールを ID またはアクセス トークンに追加できます。

"aud": "e18c04b1-4868-4b93-93d1-8d71f17ab99b", 
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-29e2af035ddc/v2.0", 
"iat": 1669657224, "nbf": 1669657224, "exp": 1669661124, 
"groups": [ 
   "0760b6cf-170e-4a14-91b3-4b78e0739963", 
   "3b2b0c93-acd8-4208-8eba-7a48db1cd4c0" 
 ],
"oid": "cb7eda1b-d09a-40ae-b8bb-37836ebc6abd",
"sub": "3OBtLXUC2ZrN_ADLNjW9X4o0lcd61py7lgHw3Skh77s",
"tid": "833ced3d-cb2e-41ce-92f1-29e2af035ddc", 
"ver": "2.0", 
"wids": [ 
   "cf1c38e5-3621-4004-a7cb-879624dced7c", 
   "b79fbf4d-3ef9-4689-8143-76b194e85509" 
 ]

groups クレーム配列は、このユーザーがメンバーになっているグループの ID で構成されます。 wids 配列は、このユーザーに割り当てられている Microsoft Entra ロールの ID で構成されます。 ここで、cf1c38e5-3621-4004-a7cb-879624dced7c は、このユーザーの割り当てられたロールに、3b2b0c93-acd8-4208-8eba-7a48db1cd4c0 が示すように、アプリケーション開発者と 標準のメンバーが含まれていることを示します。

アプリでは、これらの要求とその値の有無に基づいて承認の決定を行うことができます。 wids 要求の値の一覧については、「Microsoft Entra の組み込みロール」を参照してください。

groups と wids の要求をトークンに追加するには、[アプリの登録] | [トークン構成] | [省略可能な要求] | [編集グループ要求] 画面の次の例に示すように、すべてのグループを選択します。

グループの超過分

上記の例に示すようにトークン内のすべてのグループを要求する場合、トークンに groups 要求があるトークンに依存することはできません。 トークンと groups 要求は大きくなりすぎないように、サイズ制限があります。 ユーザーがあまりにも多くのグループのメンバーの場合、アプリは Microsoft Graph からユーザーのグループ メンバーシップを取得する必要があります。 groups 要求内のグループの制限は次のとおりです。

• JWT トークンの場合は 200 グループ。
• SAML トークンの場合は 150 グループ。
• 暗黙的フローを使用する場合は 6 つのグループ (ハイブリッド フローの暗黙的フロー部分を介して ID トークンを取得する ASP.NET コアの使用など)。
  • シングル ページ Web アプリでは、暗黙的フローは推奨されなくなりました。
  • 暗黙的なフローは、OAuth2 ハイブリッド フローではアクセス トークンではなく、ID トークンに対してのみ Web アプリで使用できます。

OpenID Connect または OAuth2 を使用している場合は、トークンに最大 200 のグループを含めることができます。 SAML を使用している場合は、SAML トークンが OAuth2 および OpenID Connect トークンよりも大きいため、グループを150 しか持てません。 暗黙的フローを使用している場合、URL に応答が表示されるため、制限は 6 です。 いずれの場合も、groups 要求を持つ代わりに、ユーザーがトークンに収まらない多くのグループのメンバーであることを示す兆候 (グループ超過と呼ばれます) が表示されます。

次のトークンの例では、OpenID Connect (OAuth2)、JSON Web Token (JWT) の場合、ユーザーがあまりに多くのグループのメンバーである場合は groups 要求はありません。 代わりに、配列の _claim_names メンバーを含む groups 要求があります。

上記のトークンの例では、groups 要求が src1 にマッピングされるはずであることがわかります。 理論上、_claim_sources 要求を探し、src1 メンバーを見つけます。 そこから、グループ メンバーシップを取得するために使用する Graph クエリが表示されます。 ただし、Graph クエリの例に表示される内容に問題があります。 Azure AD Graph (Microsoft は非推奨) に移動するため、使用しないでください。

暗黙的なフロー超過の表示は、hasgroups 要求ではなく groups 要求で行われます。

グループ メンバーシップを使用して適切な承認を確保するには、アプリに groups 要求のチェックをさせます。 存在する場合は、その要求を使用してユーザーのグループ メンバーシップを決定します。 groups 要求がない場合は、配列の _claim_names メンバーを持つ hasgroups 要求、またはgroups 要求の存在をチェックします。 これらの要求のいずれかが存在する場合、ユーザーはトークンに対してあまりにも多くのグループのメンバーになります。 この場合、アプリは Microsoft Graph を使用してユーザーのグループ メンバーシップを決定する必要があります。 「ユーザーのメンバーシップを一覧表示する (直接的と推移的)」を参照して、ユーザーがメンバーであるすべてのグループ (直接的と推移的の両方) を検索します。

アプリケーションでリアルタイムのグループ メンバーシップ情報が必要な場合は、Microsoft Graph を使用してグループ メンバーシップを決定します。 受信するトークンの情報は、Microsoft Graph を呼び出した時点でのみ最新であることに注意してください。

[アプリの登録] | [Tトークン構成] | [省略可能な要求] | [編集グループ要求] 画面の次の例を参照してください。 グループ超過要求に達しないようにする 1 つの方法は、[すべてのグループ] ではなく [グループ要求の編集] 画面で [アプリケーションに割り当てられているグループ] を選択することです。

[アプリケーションに割り当てられたグループ] を選択すると、次の条件に該当する場合、グループが groups 要求に含まれます。

• グループが エンタープライズ アプリに割り当てられている
• ユーザーは、グループの直接メンバーである

この記事の発行時点では、[アプリケーションに割り当てられたグループ] オプションは間接メンバーシップをサポートしていません。 グループの割り当てには、少なくとも P1 レベルのライセンスが必要です。 無料のテナントは、アプリケーションにグループを割り当てることはできません。

グループとアプリ ロール

グループ超過の問題を回避するもう 1 つの方法は、ユーザーとグループをメンバーの種類として許可するアプリ ロールをアプリで定義することです。 次の画面 ([アプリの登録] | [アプリ ロール] | [アプリ ロールの作成] 画面) に示すように、[許可されたメンバーの種類] で [ユーザー/グループ] を選択します。

アプリの登録でアプリ ロールが作成されていれば、IT 担当者は、ユーザーとグループをロールに割り当てることができます。 次のトークン の例に示すように、アプリは、サインインしているユーザーに割り当てられたすべてのロールを含むトークン (アプリの ID トークン、API のアクセス トークン) で roles 要求を取得します。

"aud": "acaf6ce9-81f0-462a-a93d-a314070738d3",
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-29e2af035ddc/v2.0",
"iat": 1670826509, "nbf": 1670826509, "exp": 1670830409,
"name": "Kyle Marsh",
"oid": "cb7eda1b-d09a-419e-b8bb-37836ebc6abd",
"preferred_username": "kylemar@idfordevs.dev",
"roles": [
 "Approver",
 "Reviewer" 
],
"sub": "dx-4lf-0loB3c3uVrULnZ2VTLuRRWYff0q7-QlIfYU4",
"tid": "833ced3d-cb3e-41de-92f1-29e2af035ddc",

アプリケーションで次の条件を処理することを忘れないでください。

• roles 要求がない
• ユーザーがロールに割り当てられていない
• ユーザーが複数のロールを割り当てられている場合の roles 要求内の複数の値

ユーザーとグループをメンバーとして許可するアプリ ロールを作成する場合は、常に、昇格された認可ロールを持たないベースライン ユーザー ロールを定義します。 エンタープライズ アプリ構成で割り当てが必要な場合、アプリケーションに直接割り当てられているか、アプリに割り当てられたグループのメンバーシップに含まれるユーザーのみがアプリを使用できます。

ユーザーとグループをメンバーとして許可するアプリ ロールがアプリに定義されている場合、ユーザーまたはグループがアプリに割り当てられるとき、定義済みのアプリ ロールの 1 つがアプリへのユーザーまたはグループの割り当ての一部である必要があります。 昇格されたロール (admin など) のみがアプリで定義されている場合、すべてのユーザーとグループに管理者ロールが割り当てられます。 基本ロール (user など) を定義すると、アプリに割り当てられたユーザーとグループに基本ユーザー ロールを割り当てることができます。

グループの超過要求を回避することに加えて、ロールを使用するもう 1 つの利点は、グループ ID または名前と、それがアプリケーションで何を意味するかをマップする必要がないことです。 たとえば、コードで groups 要求のグループを反復処理してどのグループ ID に管理者機能を許可する必要があるかを決定するのではなく、管理者ロール要求を探すことができます。

コードでのロールの確認と使用

アプリのアプリ ロールを定義するときは、それらのロールの承認ロジックを実装する必要があります。 アプリに認可ロジックを実装する方法については、「アプリケーションにロールベースのアクセス制御を実装する」を参照してください。

次のステップ

• トークンのカスタマイズでは、Microsoft Entra トークンで受信することができる情報と、最小限の特権でアプリケーションのゼロ トラスト セキュリティを強化しながら、柔軟性と制御を向上させるためにトークンをカスタマイズする方法について説明します。
• Microsoft Entra ID を使用してアプリケーションのグループ要求を構成すると、Microsoft Entra ID がアプリケーション内で使用するトークンでユーザーのグループ メンバーシップ情報を提供する方法が示されます。
• アプリケーション プロパティ のセキュリティのベスト プラクティスでは、リダイレクト URI、アクセス トークン (暗黙的なフローに使用)、証明書とシークレット、アプリケーション ID URI、アプリケーションの所有権について説明します。
• 「Microsoft ID プラットフォームのスコープ、アクセス許可、および同意」では、より安全で信頼できるアプリケーションの構築に役立つ、アクセスと承認の基本的な概念について説明します。
• 「ゼロ トラスト ID およびアクセス管理の開発のベスト プラクティス」をアプリケーション開発ライフサイクルで使用して、セキュリティで保護されたアプリケーションを作成します。