次の方法で共有

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

  • [アーティクル]

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

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

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

アプリケーション内で認可に使用できるトークンでグループ要求 を設定 できます。 トークン内のグループ情報は、トークンを受け取ったときにのみ最新であることに注意してください。 グループ要求は、次の 2 つの主要なパターンをサポートします。

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

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

"aud": "00001111-aaaa-2222-bbbb-3333cccc4444", 
"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": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"sub": "3OBtLXUC2ZrN_ADLNjW9X4o0lcd61py7lgHw3Skh77s",
"tid": "bbbbcccc-1111-dddd-2222-eeee3333ffff", 
"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 要求があるトークンに依存することはできません。 トークンと groups 要求にはサイズ制限があるため、サイズが大きくなりすぎないようにします。 ユーザーがグループのメンバーが多すぎる場合、アプリは Microsoft Graph からユーザーのグループ メンバーシップを取得する必要があります。 groups 要求のグループの制限は次のとおりです。

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

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

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

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

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

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

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

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

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

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

グループとアプリロール

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

[アプリ ロールの作成] 画面のスクリーンショットには、[許可されているメンバーの種類: ユーザー/グループ] が表示されます。

アプリの登録でアプリ ロールを作成 した後、IT担当者はそのロールにユーザーやグループを割り当てることができます 。 アプリがサインイン中のユーザーに割り当てられたすべての役割を含む roles クレームをトークン内で取得します (アプリの ID トークン、API のアクセス トークン)。次のトークンの例をご覧ください。

"aud": "11112222-bbbb-3333-cccc-4444dddd5555",
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-29e2af035ddc/v2.0",
"iat": 1670826509, "nbf": 1670826509, "exp": 1670830409,
"name": "Kyle Marsh",
"oid": "bbbbbbbb-1111-2222-3333-cccccccccccc",
"preferred_username": "kylemar@idfordevs.dev",
"roles": [
 "Approver",
 "Reviewer" 
],
"sub": "dx-4lf-0loB3c3uVrULnZ2VTLuRRWYff0q7-QlIfYU4",
"tid": "ccccdddd-2222-eeee-3333-ffff4444aaaa",

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

  • roles 要求がない
  • ユーザーにロールの割り当てがない
  • ユーザーが複数のロールを割り当てられている場合、roles 要求には複数の値が含まれます。

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

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

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

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

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

次の手順

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