アプリケーション開発者向けのロールベースのアクセス制御

  • [アーティクル]

ロールベースのアクセス制御 (RBAC) を使用すると、特定のユーザーまたはグループに、リソースにアクセスして管理するための特定のアクセス許可を付与できます。 アプリケーションの RBAC は、Azure ロールベースのアクセス制御や、Microsoft Entra ロールベースのアクセス制御とは異なります。 Azure カスタム ロールと組み込みロールはどちらも Azure RBAC の一部であり、Azure リソースの管理に役立ちます。 Microsoft Entra RBAC は、Microsoft Entra のリソースを管理するために使用されます。 この記事では、アプリケーション固有の RBAC について説明します。 アプリケーション固有の RBAC を適用する方法については、「アプリケーションにアプリ ロールを追加してトークンで受け取る」を参照してください。

ロールの定義

RBAC は、アプリケーションで承認を実施する一般的なメカニズムです。 組織で RBAC を使用する場合、アプリケーション開発者は、個々のユーザーまたはグループを承認する代わりにロールを定義します。 その後、管理者はさまざまなユーザーやグループにロールを割り当てて、誰がコンテンツと機能にアクセスできるかを制御できます。

RBAC は、アプリケーション開発者がリソースとその使用方法を管理するのに役立ちます。 RBAC を使用すると、アプリケーション開発者は、ユーザーがアクセスできるアプリケーションの領域も制御できます。 管理者は、"ユーザーの割り当てが必要" プロパティを使用して、アプリケーションにアクセスできるユーザーを制御できます。 開発者は、アプリケーション内の特定のユーザーと、アプリケーション内でユーザーが実行できる操作を考慮する必要があります。

アプリケーション開発者は、最初に、Microsoft Entra 管理センターのアプリケーションの登録セクション内でロール定義を作成します。 ロールの定義には、そのロールに割り当てられたユーザーに対して返される値が含まれます。 その後、開発者はこの値を使用してアプリケーション ロジックを実装し、ユーザーがアプリケーション内で実行できる操作や実行できない操作を決定できます。

RBAC のオプション

アプリケーションにロールベースのアクセス制御承認を組み込むことを検討している場合、次のガイダンスを適用する必要があります。

  • アプリケーションの承認ニーズに必要なロールを定義します。
  • 認証されたユーザーに関連ロールを適用し、それらのロールを保存、取得します。
  • 現在のユーザーに割り当てられるロールに基づくアプリケーションの動作を決定します。

ロールが定義された後、Microsoft ID プラットフォームによって、認証されたユーザーのロール情報の適用、保存、取得に使用できるさまざまなソリューションがサポートされます。 これらのソリューションには、アプリ ロール、Microsoft Entra グループ、およびユーザー ロール情報に対するカスタム データストアの使用が含まれます。

開発者は、ロールの割り当てをアプリケーションのアクセス許可としてどう解釈するかについて、独自の実装を柔軟に提供できます。 このアクセス許可の解釈では、アプリケーションまたは関連するライブラリのプラットフォームによって提供されるミドルウェアやその他のオプションを使用できます。 アプリケーションは通常、ユーザー ロール情報を要求として受け取り、それらの要求に基づいてユーザーのアクセス許可を決定します。

アプリ ロール

Microsoft Entra ID では、アプリケーションのアプリ ロールを定義し、ユーザーと他のアプリケーションにこれらのロールを割り当てることができます。 ユーザーまたはアプリケーションに割り当てたロールによって、アプリケーション内のリソースと操作へのアクセスのレベルが定義されます。

認証されたユーザーまたはアプリケーションに対して Microsoft Entra ID からアクセス トークンが発行されると、アクセス トークンの roles 要求に、エンティティ (ユーザーまたはアプリケーション) を割り当てたロールの名前が含まれます。 要求でそのアクセス トークンを受け取る Web API などのアプリケーションは、roles 要求内の値に基づいて認可の決定を行うことができます。

グループ

また開発者は、アプリケーションに RBAC を実装するために Microsoft Entra グループも使用できます。この場合、特定グループ内でのユーザーのメンバーシップが、ロール メンバーシップとして解釈されます。 組織がグループを使用する場合、トークンにはグループ要求が含まれます。 グループ要求では、テナント内でユーザーが割り当てられたすべてのグループの ID が指定されます。

重要

グループを扱う場合、開発者は超過要求の概念を認識する必要があります。 既定では、ユーザーが超過制限 (SAML トークンの場合は 150、JWT トークンの場合は 200、暗黙的フローを使用する場合は 6) を超える数のメンバーになっている場合、Microsoft Entra ID はトークンにグループ要求を出力しません。 代わりに、トークンに "超過要求" を組み込みます。これは、トークンのコンシューマーが、Microsoft Graph API を照会してユーザーのグループ メンバーシップを取得する必要があることを示します。 超過要求の取り扱いの詳細については、「アクセス トークン内の要求」を参照してください。 アプリケーションに割り当てられているグループのみを出力することもできますが、グループ ベースの割り当てには、Microsoft Entra ID P1 または P2 エディションが必要です。

カスタム データ ストア

Microsoft Entra ディレクトリでのユーザーの割り当てに関する情報は、アプリ ロールとグループの両方で保管されます。 ユーザー ロールの情報を管理するために開発者が使用できるもう 1 つのオプションは、ディレクトリ外部のカスタム データ ストア内に情報を保持することです。 たとえば、SQL Database や Azure Table Storage、または Azure Cosmos DB for Table などです。

カスタム ストレージを使用すると、開発者はユーザーにロールを割り当てる方法と、ロールを表す方法をさらにカスタマイズして制御することが可能になります。 ただし、柔軟性が高まると、より大きな責任も伴います。 たとえば、Microsoft Entra ID から返されるトークンにこの情報を含めるメカニズムとして、現在利用可能なものはありません。 ロール情報がカスタム データ ストアに保持されている場合、アプリケーションではロールを取得する必要があります。 通常、ロールの取得は、機能拡張ポイントを使用して行います。この機能拡張ポイントは、アプリケーションの開発に使用されるプラットフォームで使用できるミドルウェアで定義されます。 開発者は、カスタム データ ストアをセキュリティで適切に保護する責任があります。

Azure AD B2C カスタム ポリシーを使用すると、カスタム データ ストアを操作することや、トークン内にカスタム要求を組み込むことができます。

アプローチの選択

一般に、推奨されるソリューションはアプリ ロールです。 アプリ ロールは RBAC の実装を目的として作られており、最も単純なプログラミング モデルを提供します。 ただし、特定のアプリケーション要件では、別のアプローチの方が適切なソリューションとなる場合があります。

開発者はアプリ ロールを使用して、ユーザーがアプリケーションにサインインできるかどうか、またはアプリケーションが Web API のアクセス トークンを取得できるかどうかを制御できます。 アプリケーションで承認のパラメーターを記述して制御する場合、開発者には、Microsoft Entra グループよりもアプリ ロールを使用することをお勧めします。 たとえば、承認にグループを使用するアプリケーションは、グループ ID と名前の両方が異なる可能性があるため、次のテナントで中断されます。 アプリ ロールを使用するアプリケーションは安全なままです。

アプリ ロールとグループのどちらも認可に使用できますが、両社の間の主要な違いは、どちらが特定のシナリオに最適なソリューションとなるかに影響を与える可能性があります。

アプリ ロール Microsoft Entra グループ カスタム データ ストア
プログラミング モデル 最も簡単です。 これらは、アプリケーション固有であり、アプリケーション登録で定義されます。 これらはアプリケーションと共に移動します。 より複雑です。 グループ ID はテナントによって異なり、超過要求を考慮する必要がある場合があります。 グループは、アプリケーション固有ではなく、Microsoft Entra テナント固有です。 最も複雑です。 開発者は、ロール情報を格納および取得する手段を実装する必要があります。
ロールの値は、Microsoft Entra テナント間で一定である はい いいえ 実装によって異なります。
ロールの値は、複数のアプリケーションで使用できる いいえ (各アプリケーション登録でロール構成を複製した場合を除きます)。 はい はい
情報がディレクトリ内に格納されている はい はい いいえ
情報はトークンを介して配信される はい (ロール要求) はい (超過が発生した場合、実行時に "グループ要求" の取得が必要となる場合があります) いいえ (カスタム コードを介して実行時に取得されます)。
有効期間 ディレクトリのアプリケーション登録内に存在します。 アプリケーション登録が削除されると、削除されます。 ディレクトリ内に存在します。 アプリケーション登録が削除されても、そのまま残ります。 カスタム データ ストアに存在します。 アプリケーション登録とは関連付けられていません。

次のステップ