トークン内のグループ クレームとアプリ ロールを構成する

  • [アーティクル]

この記事は、アプリ ロールの定義を使用してアプリを構成し、セキュリティ グループをアプリ ロールに割り当てることで、最小限の特権でアプリケーションのセキュリティを強化しながら柔軟性と制御を向上させるのに役立ちます。

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

選択したグループの種類 (アプリケーションに割り当てられたグループ) が表示された [Edit group claims]\(グループ クレームの編集\) 画面のスクリーンショット。

グループの超過分

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

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

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

次のトークンの例では、OpenID 接続 (OAuth2)、JSON Web トークン (JWT) の場合、ユーザーが所属しているグループが多すぎる場合は groups クレームは存在しません。 代わりに、配列の groups メンバーを含む _claim_names クレームが存在iします。

トークンの例のスクリーンショットはクエリを示しています。

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

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

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

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

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

選択したグループの種類 (セキュリティ グループ、ディレクトリ ロール、およびすべてのグループ) が表示された [Edit group claims]\(グループ クレームの編集\) 画面のスクリーンショット。

[アプリケーションに割り当てられたグループ] を選択すると、次の条件に該当する場合、グループが 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 に管理者機能を許可する必要があるかを決定するのではなく、管理者ロール要求を探すことができます。

コード内でロールを検証して使用する

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

次のステップ