ロールとロール要求を使用して Java JBoss EAP アプリをセキュリティで保護する
この記事では、OpenID Connect を使用してユーザーのサインインを行い、Microsoft Entra ID アプリケーション ロール (アプリ ロール) で認証を行う Java JBoss EAP アプリについて説明します。
このアプリケーションは、Microsoft Entra ID のアプリケーション ロールとロール要求機能を使用して、ロールベースのアクセス制御 (RBAC) を実装します。 もう 1 つの方法は、Microsoft Entra ID のグループとグループ要求を使うことです。 Microsoft Entra ID グループとアプリケーション ロールは相互に排他的ではありません。 両方を使用して、アクセスをきめ細かく制御することができます。
また、RBAC にアプリケーション ロールとロール要求を使用することで、認証ポリシーをセキュアに適用することもできます。
このシナリオとサンプルを紹介するビデオ、「アプリ ロール、セキュリティ グループ、スコープ、ディレクトリ ロールを使用した承認をアプリケーションに実装する」をご覧ください。
このシナリオやその他のシナリオでのプロトコルの使用について詳しくは、「認証と承認」を参照してください。
このアプリケーションでは、MSAL for Java (MSAL4J) を使用してユーザーのサインインを行い、Microsoft Entra ID から ID トークンを取得します。
このサンプルは、最初に MSAL for Java (MSAL4J) を使用してユーザーのサインインを行います。 ホーム ページには、ユーザーが ID トークン内の要求を確認するためのオプションが表示されます。 このアプリケーションでは、ユーザーが割り当てられているアプリ ロールに応じて、特権管理者ページまたは通常のユーザー ページを表示することもできます。 これを例示する目的は、アプリケーション内で、ユーザーによる特定の機能やページへのアクセスを、所属するロールに基づいて一部のユーザーに制限する方法を示すことです。
このような承認は、RBAC を使用して実装されます。 RBAC を使用する場合、管理者は、個々のユーザーまたはグループではなく、ロールにアクセス許可を付与します。 その後、管理者はロールをさまざまなユーザーやグループに割り当てて、コンテンツや機能に誰がアクセスできるかを制御します。
このサンプル アプリケーションには、次の 2 つのアプリケーション ロールを定義します。
PrivilegedAdmin: 管理者のみページと通常のユーザー ページへのアクセスが許可されます。RegularUser: 通常のユーザー ページへのアクセスが許可されます。
これらのアプリケーション ロールは Azure portal でアプリケーションの登録マニフェストに定義されます。 ユーザーがアプリケーションにサインインすると、Microsoft Entra ID はロール メンバーシップの形式でユーザーに個別に付与された各ロールに対し、ロール要求を出力します。
Azure portal を通じて、ユーザーとグループをロールに割り当てることができます。
Note
https://login.microsoftonline.com/common/ エンドポイントがユーザーのサインイン権限として使用されている場合、テナント内の ゲスト ユーザーにはロール要求が存在しません。 次のような https://login.microsoftonline.com/tenantidテナント ID エンドポイントにユーザーをサインインさせる必要があります。
前提条件
- JDK - バージョン 8 以降
- Maven 3
- Microsoft Entra ID テナント。 詳細については、「Microsoft Entra ID テナントの取得方法」をご覧ください。
- 組織のディレクトリに含まれるアカウントだけを操作する (シングルテナント モード) 場合は、自分の Microsoft Entra ID テナントのユーザー アカウント。 テナントにまだユーザー アカウントを作成していない場合は、作成してから続行する必要があります。 詳細については、「ユーザーを作成、招待、削除する方法」をご覧ください。
推奨事項
- Java / Jakarta Servlets に関するある程度の知識。
- Linux/OSX ターミナルに関するある程度の知識。
- トークンの検査に必要な jwt.ms。
- ネットワークの活動監視とトラブルシューティングに必要な Fiddler。
- 開発に関する最新の情報について、Microsoft Entra ID ブログを確認してください。
サンプルのセットアップ
次のセクションでは、サンプル アプリケーションを設定する方法を示します。
サンプル リポジトリを複製またはダウンロードする
サンプルを複製するには、Bash ウィンドウを開き、次のコマンドを使用します。
git clone https://github.com/Azure-Samples/ms-identity-msal-java-samples.git
cd 3-java-servlet-web-app/3-Authorization-II/roles
または、ms-identity-msal-java-samples リポジトリに移動し、.zip ファイルでダウンロードして、ハード ドライブに展開します。
重要
Windows でファイル パスの長さが制限を超える場合は、ハード ドライブのルート近くのディレクトリにリポジトリを複製または展開してください。
Microsoft Entra ID テナントにサンプル アプリケーションを登録する
このサンプルには、プロジェクトが 1 つ存在します。 以下の各セクションでは、Azure portal を使用してアプリを登録する方法を説明します。
アプリケーションを作成する Microsoft Entra ID テナントを選択する
テナントを選択するには、次の手順に従います。
Azure portal にサインインします。
ご利用のアカウントが複数の Microsoft Entra ID テナントに存在する場合は、Azure portal の隅にあるプロファイルを選択し、ディレクトリの切り替えを選択して、セッションを目的の Microsoft Entra ID テナントに変更します。
アプリを登録する (java-servlet-webapp-roles)
最初に、クイック スタート: Microsoft ID プラットフォームにアプリケーションを登録するに記載された説明に従って Azure portal に新しいアプリを登録します。
次の手順を実行して、登録を完了します。
開発者用の Microsoft ID プラットフォームの [アプリの登録] ページに移動します。
[新規登録] を選択します。
表示される アプリケーションの登録ページで、アプリケーションの登録情報を入力します。
名前セクションに、アプリのユーザーに表示されるわかりやすいアプリケーション名を入力します (例:
java-servlet-webapp-roles)。サポートされているアカウントの種類で、次のオプションのいずれかを選択します。
- 自分のテナントのユーザーのみが使用するアプリケーションをビルドしている場合は (シングルテナント アプリケーション)、この組織のディレクトリ内のアカウントのみを選択します。
リダイレクト URI セクションで、コンボ ボックスの Web を選択し、リダイレクト URI:
http://localhost:8080/msal4j-servlet-roles/auth/redirectを入力します。
[登録] を選択して、アプリケーションを作成します。
アプリの登録ページで、アプリケーション (クライアント) ID の値を見つけてメモします。 この値は、後ほどアプリの構成ファイルで使用します。
[保存] を選択して変更を保存します。
アプリの登録ページで、ナビゲーション ペインにある 証明書とシークレットを選択してページを開き、シークレットの生成と証明書のアップロードを行います。
[クライアント シークレット] セクションで、 [新しいクライアント シークレット] を選択します。
キーの説明 (例: アプリのシークレット) を入力します。
1 年、2 年、無期限のいずれかの期間を選びます。
[追加] を選択します。 生成された値が表示されます。
生成した値をコピーしてから保存します。 この値は後ほど、コードの構成ファイルに使用します。 この値は二度と表示されず、他の方法でも取得はできません。 そのため、必ず Azure portal から保存した後に、他の画面やペインに移動してください。
アプリケーション ロールの定義
次の手順に従って、アプリのロールを定義します。
同じアプリの登録で、ナビゲーション ペインからアプリ ロールを選択します。
アプリ ロールの作成を選択し、次の値を入力または選択します。
- 表示名で、PrivilegedAdmin などのわかりやすい名前を入力します。
- 許可されるメンバーの種類で、ユーザーを選択します。
- 値に PrivilegedAdmin と入力します。
- 説明に管理ページを表示する権限を持つ管理者と入力します。
アプリ ロールの作成を選択し、次の値を入力または選択します。
- 表示名に、RegularUser などのわかりやすい名前を入力します。
- 許可されるメンバーの種類で、ユーザーを選択します。
- 値に RegularUser と入力します。
- 説明にユーザー ページを表示できる通常のユーザーと入力します。
[適用] を選択して変更を保存します。
アプリケーション ロールにユーザーを割り当てる
先ほどに定義したアプリ ロールにユーザーを追加するには、「ロールにユーザーとグループを割り当てる」のガイドラインに従ってください。
アプリの登録を使用するためにアプリ (java-servlet-webapp-roles) を構成する
アプリを構成するには、次の手順に従います。
Note
以降の手順では、ClientID は Application ID または AppId と同じです。
IDE でプロジェクトを開きます。
authentication.properties ファイルを開きます。
{enter-your-tenant-id-here}という文字列を見つけます。 既存の値を Microsoft Entra ID のテナント ID に置き換えます。{enter-your-client-id-here}という文字列を見つけて、既存の値をアプリケーション ID または Azure portal からコピーしたjava-servlet-webapp-call-graphアプリケーションのclientIdに変更します。{enter-your-client-secret-here}という文字列を見つけて、既存の値を、Azure portal でjava-servlet-webapp-rolesアプリを作成するときに保存した値に置き換えます。app.rolesプロパティを見つけて、値がapp.roles=admin PrivilegedAdmin, user RegularUserに設定されていることを確認するか、指定したロールの名前に置き換えます。
サンプルをビルドする
Maven を使用してサンプルをビルドするには、サンプルの pom.xml ファイルが含まれているディレクトリに移動して、次のコマンドを実行します。
mvn clean package
このコマンドを実行すると、.war ファイルが作成されます。これはさまざまなアプリケーション サーバーで実行できます。
サンプルを実行する
以降のセクションでは、サンプルを Azure App Service にデプロイする方法を紹介します。
前提条件
Azure App Service アプリ用の Maven プラグイン
Maven を開発ツールに選択しない場合は、他のツールを使用する次のチュートリアルを参照してください。
Maven プラグインを構成する
Azure App Service へのデプロイ プロセスでは、Azure CLI から Azure 資格情報が自動的に使用されます。 Azure CLI がローカルにインストールされていない場合、Maven プラグインは OAuth またはデバイス ログインを使用して認証します。 詳細については、Maven プラグインによる認証に関するページを参照してください。
プラグインを構成するには、次の手順に従います。
次に示す Maven コマンドを実行して、デプロイを構成します。 このコマンドは、App Service オペレーティング システム、Java バージョン、および Tomcat バージョンを設定するのに役立ちます。
mvn com.microsoft.azure:azure-webapp-maven-plugin:2.12.0:config新しい実行構成を作成するで、Y を押して、Enter を押します。
Linux の場合は OS の値を定義しますで 2を押し、Enter を押します。
Java 11 の場合は javaVersion の値を定義しますで 2 を押し、Enter を押します。
JBosseap7 の場合は、webContainer の値を定義しますで 1 を押し、Enter を押します。
pricingTier の値を定義しますで Enter を押し、既定値である P1v3 層を選択します。
確認で Y を押し、Enter を押します。
デプロイ プロセスの出力例を次に示します。
Please confirm webapp properties
AppName : msal4j-servlet-auth-1707220080695
ResourceGroup : msal4j-servlet-auth-1707220080695-rg
Region : centralus
PricingTier : P1v3
OS : Linux
Java Version: Java 11
Web server stack: JBosseap 7
Deploy to slot : false
Confirm (Y/N) [Y]:
[INFO] Saving configuration to pom.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 26.196 s
[INFO] Finished at: 2024-02-06T11:48:16Z
[INFO] ------------------------------------------------------------------------
選択内容の確認後、プラグインによって、アプリを Azure App Service で実行するよう構成するのに必要なプラグイン構成および設定が、プロジェクトの pom.xml ファイルに追加されます。
pom.xml ファイルの関連部分は、次の例のようになります。
<build>
<plugins>
<plugin>
<groupId>com.microsoft.azure</groupId>
<artifactId>>azure-webapp-maven-plugin</artifactId>
<version>x.xx.x</version>
<configuration>
<schemaVersion>v2</schemaVersion>
<resourceGroup>your-resourcegroup-name</resourceGroup>
<appName>your-app-name</appName>
...
</configuration>
</plugin>
</plugins>
</build>
pom.xml 内で App Service の構成を直接変更できます。 一般的な構成をいくつか次の表に示します。
| プロパティ | Required | 説明 | Version |
|---|---|---|---|
schemaVersion |
false | 構成スキーマのバージョンを指定します。 サポートされている値は、v1 および v2 です。 |
1.5.2 |
subscriptionId |
false | サブスクリプション ID です。 | 0.1.0 以降 |
resourceGroup |
true | アプリの Azure リソース グループ。 | 0.1.0 以降 |
appName |
true | アプリの名前。 | 0.1.0 以降 |
region |
false | アプリをホストするリージョン。 既定値は centralus です。 有効なリージョンについては、「サポートされているリージョン」を参照してください。 |
0.1.0 以降 |
pricingTier |
false | アプリの価格レベル。 運用環境のワークロードでは、既定値は P1v2 です。 Java の開発とテストに推奨される最小値は B2 です。 詳細については、「App Service の価格」を参照してください |
0.1.0 以降 |
runtime |
false | ランタイム環境の構成。 詳細については、「構成の詳細」を参照してください。 | 0.1.0 以降 |
deployment |
false | デプロイの構成。 詳細については、「構成の詳細」を参照してください。 | 0.1.0 以降 |
構成の完全な一覧については、プラグインのリファレンス ドキュメントを参照してください。 すべての Azure Maven プラグインでは、一連の構成が共通しています。 これらの構成については、「共通の構成」を参照してください。 Azure App Service に固有の構成については、「Azure アプリ: 構成の詳細」を参照してください。
後で使用するために appName と resourceGroup の値を保存しておいてください。
アプリのデプロイを準備する
アプリケーションを App Service にデプロイすると、リダイレクト URL が、デプロイされたアプリ インスタンスのリダイレクト URL に変更されます。 これらの設定をプロパティー ファイルで変更しするには、次の手順を使用します。
アプリの authentication.properties ファイルに移動し、
app.homePageの値をデプロイされたアプリのドメイン名に変更します (次の例を参照)。 たとえば、前の手順でアプリ名にexample-domainを選択している場合は、app.homePageの値にhttps://example-domain.azurewebsites.netを使用する必要があります。 プロトコルをhttpからhttpsに変更することも必要です。# app.homePage is by default set to dev server address and app context path on the server # for apps deployed to azure, use https://your-sub-domain.azurewebsites.net app.homePage=https://<your-app-name>.azurewebsites.netこのファイルを保存した後、次のコマンドを使用してアプリをリビルドします。
mvn clean package
重要
この同じ authentication.properties ファイルに、aad.secret の設定があります。 この値を App Service にデプロイすることはお勧めしません。 また、この値をコードに残しておくことや、それを git リポジトリにプッシュすることは望ましくありません。 このシークレット値をコードから削除する方法の詳細な説明については、「App Service へのデプロイ - シークレットの削除」セクションを参照してください。 ここにはシークレット値を Key Vault にプッシュするための手順や、Key Vault 参照を使用するための手順が説明されています。
Microsoft Entra IDアプリの登録を更新する
リダイレクト URI は Azure App Service にデプロイされたアプリに変更されるため、Microsoft Entra ID アプリの登録でも、リダイレクト URI を変更する必要があります。 次の手順に従って、この変更を行います。
開発者用の Microsoft ID プラットフォームの [アプリの登録] ページに移動します。
検索ボックスを使用してアプリの登録を検索します (例:
java-servlet-webapp-authentication)。名前を選択して、アプリの登録を開きます。
コマンドメニューから 認証 を選択します。
Web - リダイレクト URI セクションで、URI の追加を選択します。
アプリの URI を、
/auth/redirectを追加して入力します。たとえばhttps://<your-app-name>.azurewebsites.net/auth/redirectのようになります。[保存] を選択します。
アプリケーションのデプロイ
以上で、アプリを Azure App Service にデプロイする準備ができました。 次のコマンドを使用して、デプロイを実行するために Azure 環境にサインインしていることを確認します。
az login
pom.xml ファイルにすべての構成が準備されています。これで、次のコマンドを使用して Java アプリを Azure にデプロイできます。
mvn package azure-webapp:deploy
デプロイが完了すると、アプリケーションを http://<your-app-name>.azurewebsites.net/ で起動できます。 ローカル Web ブラウザーで URL を開くと、msal4j-servlet-auth アプリケーションのスタート ページが表示されます。
サンプルの確認
次の手順に従ってサンプルを操作します。
- サインインまたはサインアウトの状態が、画面の中央に表示されます。
- 画面の隅にある状況依存ボタンを選択します。 このボタンは、アプリを最初に実行するときにサインインと表示します。
- 次のページに記載された指示に従い、Microsoft Entra ID テナントのアカウントでサインインします。
- 同意画面に、必要となるスコープが表示されます。
- 状況依存ボタンの表示がサインアウトに変わり、ユーザー名が表示されます。
- ID トークンの詳細を選択すると、ID トークンのデコードされた要求の一部が表示されます。
- 管理者のみを選択し、
/admin_onlyページを表示します。 このページを表示できるのは、PrivilegedAdminのアプリ ロールを持つユーザーだけです。 それ以外のユーザーには、承認エラー メッセージが表示されます。 - 通常のユーザーを選択し、
/regular_userページを表示します。 このページを表示できるのは、RegularUserまたはPrivilegedAdminのアプリ ロールを持つユーザーだけです。 それ以外のユーザーには、承認エラー メッセージが表示されます。 - 画面隅のボタンを使用してサインアウトします。
コードについて
このサンプルでは、MSAL for Java (MSAL4J) を使用してユーザーがサインインし、ロール要求を含む ID トークンを取得します。 存在するロール要求に基づいて、サインインしているユーザーは、Admins Only と Regular Users の保護されたページのいずれにもアクセスできないか、1 つ、または両方にアクセスできます。
このサンプルの動作をレプリケートする場合は、src/main/java/com/microsoft/azuresamples/msal4j フォルダーにある pom.xml ファイルと、helpers フォルダーおよび authservlets フォルダーの内容をコピーします。 authentication.properties ファイルも必要です。 これらのクラスとファイルには、さまざまなアプリケーションで使用できる汎用コードが含まれています。 サンプルの残りもコピーできますが、他のクラスとファイルは、このサンプルの目的に合わせて特別にビルドされたものです。
Contents
次の表に、サンプル プロジェクト フォルダーの内容を示します。
| ファイル/フォルダー | 説明 |
|---|---|
| src/main/java/com/microsoft/azuresamples/msal4j/roles/ | このディレクトリには、アプリの基幹業務ロジックを定義するクラスが含まれています。 |
| src/main/java/com/microsoft/azuresamples/msal4j/authservlets/ | このディレクトリには、サインインとサインアウトのエンドポイントに使用されるクラスが含まれています。 |
| ____Servlet.java | 使用可能なすべてのエンドポイントは、末尾が ____Servlet.java である .java クラスに定義されます。 |
| src/main/java/com/microsoft/azuresamples/msal4j/helpers/ | 認証に使用するヘルパー クラス。 |
| AuthenticationFilter.java | 認証されていない要求を、保護されたエンドポイントの 401 ページにリダイレクトします。 |
| src/main/resources/authentication.properties | Microsoft Entra ID とプログラム構成。 |
| src/main/webapp/ | このディレクトリには UI - JSP テンプレートが含まれています |
| CHANGELOG.md | サンプルに対する変更の一覧。 |
| CONTRIBUTING.md | サンプルに貢献するためのガイドライン。 |
| ライセンス | サンプルのライセンス。 |
ID トークンのロール要求を処理する
トークンのロール要求には、サインインしているユーザーが割り当てられているロールの名前が含まれます (次の例を参照)。
{
...
"roles": [
"Role1",
"Role2",]
...
}
ConfidentialClientApplication
ConfidentialClientApplication インスタンスが AuthHelper.java ファイルに作成されます (次の例を参照)。 このオブジェクトにより Microsoft Entra 認証 URL の作成と、アクセス トークンの認証トークンの交換が行われます。
// getConfidentialClientInstance method
IClientSecret secret = ClientCredentialFactory.createFromSecret(SECRET);
confClientInstance = ConfidentialClientApplication
.builder(CLIENT_ID, secret)
.authority(AUTHORITY)
.build();
インスタンス化には次のパラメーターが使用されます。
- アプリのクライアント ID。
- クライアント シークレット。機密クライアント アプリケーションに必要です。
- Microsoft Entra ID 認証機関。Microsoft Entra テナント ID が含まれます。
上記の例では、Config.java ファイルにあるプロパティ リーダ0を使用して、値が authentication.properties ファイルから読み取られます。
ステップバイステップのチュートリアル
次の手順で、アプリの機能をチュートリアルで紹介します。
サインイン プロセスの最初のステップでは、Microsoft Entra ID テナントの
/authorizeエンドポイントに要求を送信します。 承認要求の URL を作成するには、MSAL4J のConfidentialClientApplicationインスタンスを利用します。 アプリでブラウザーをこの URL にリダイレクトし、ユーザーはそこでサインインします。final ConfidentialClientApplication client = getConfidentialClientInstance(); AuthorizationRequestUrlParameters parameters = AuthorizationRequestUrlParameters.builder(Config.REDIRECT_URI, Collections.singleton(Config.SCOPES)) .responseMode(ResponseMode.QUERY).prompt(Prompt.SELECT_ACCOUNT).state(state).nonce(nonce).build(); final String authorizeUrl = client.getAuthorizationRequestUrl(parameters).toString(); contextAdapter.redirectUser(authorizeUrl);このコードの機能を次の一覧で示します。
AuthorizationRequestUrlParameters: AuthorizationRequestUrl を作成するために設定する必要があるパラメーター。REDIRECT_URI: Microsoft Entra ID がユーザー資格情報を収集した後、認証コードと共にブラウザーをリダイレクトする場所。 これは Azure portal にある Microsoft Entra ID アプリ登録のリダイレクト URI と一致する必要があります。SCOPES: スコープはアプリケーションで要求されるアクセス許可です。- 通常、ID トークンの応答を受信するには、
openid profile offline_accessの 3 つのスコープがあれば十分です。 - authentication.properties ファイルに、アプリで要求されるすべてのスコープの一覧が入力されています。
User.Readなど、その他のスコープを追加できます。
- 通常、ID トークンの応答を受信するには、
Microsoft Entra ID により、ユーザーにサインイン プロンプトが表示されます。 サインインが成功すると、ユーザーのブラウザーはアプリのリダイレクト エンドポイントにリダイレクトされます。 このエンドポイントへの有効な要求には、、認証コードが含まれています。
その後、この承認コードは、
ConfidentialClientApplicationのインスタンスによって、Microsoft Entra ID の ID トークンとアクセス トークンに交換されます。// First, validate the state, then parse any error codes in response, then extract the authCode. Then: // build the auth code params: final AuthorizationCodeParameters authParams = AuthorizationCodeParameters .builder(authCode, new URI(Config.REDIRECT_URI)).scopes(Collections.singleton(Config.SCOPES)).build(); // Get a client instance and leverage it to acquire the token: final ConfidentialClientApplication client = AuthHelper.getConfidentialClientInstance(); final IAuthenticationResult result = client.acquireToken(authParams).get();このコードの機能を次の一覧で示します。
AuthorizationCodeParameters: ID トークンやアクセス トークンと承認コードを交換するために設定する必要があるパラメーター。authCode: リダイレクト エンドポイントで受信された承認コード。REDIRECT_URI: 前のステップで使用したリダイレクト URI を、再度渡す必要があります。SCOPES: 前のステップで使用したスコープを、再度渡す必要があります。
acquireTokenが成功すると、トークン クレームが抽出されます。 nonce チェックに合格すると、結果はcontext(IdentityContextDataのインスタンス) に配置されて、セッションに保存されます。 その後、アプリケーションでそれにアクセスする必要があるときは常に、セッションから (IdentityContextAdapterServletのインスタンスを使用して)IdentityContextDataをインスタンス化できます。// parse IdToken claims from the IAuthenticationResult: // (the next step - validateNonce - requires parsed claims) context.setIdTokenClaims(result.idToken()); // if nonce is invalid, stop immediately! this could be a token replay! // if validation fails, throws exception and cancels auth: validateNonce(context); // set user to authenticated: context.setAuthResult(result, client.tokenCache().serialize());
ルートを保護する
サンプル アプリでルートへのアクセスをフィルター処理する方法については、「AuthenticationFilter.java」を参照してください。 authentication.properties ファイルを見ると、認証済みのユーザーだけがアクセスできるルートが app.protect.authenticated プロパティにコンマで区切って入力されていることがわかります (次の例を参照)。
# for example, /token_details requires any user to be signed in and does not require special roles claim(s)
app.protect.authenticated=/token_details
app.protect.roles でコンマ区切りのルール セットに入力されたすべてのルートでは、認証されていないユーザーに対する制限がないこともわかります (次の例を参照)。 ただし、これらのルートには、アプリ ロール メンバーシップのリストもスペース区切りで入力されています。認証後に、対応するロールの少なくとも 1 つを持つユーザーのみがこれらのルートにアクセスできます。
# local short names for app roles - for example, sets admin to mean PrivilegedAdmin (useful for long rule sets defined in the next key, app.protect.roles)
app.roles=admin PrivilegedAdmin, user RegularUser
# A route and its corresponding <space-separated> role(s) that can access it; the start of the next route & its role(s) is delimited by a <comma-and-space-separator>
# this says: /admins_only can be accessed by PrivilegedAdmin, /regular_user can be accessed by PrivilegedAdmin role and the RegularUser role
app.protect.roles=/admin_only admin, /regular_user admin user
スコープ
スコープはアプリケーションが要求するアクセス レベルを Microsoft Entra ID に通知します。
Microsoft Entra ID は、要求されたスコープに基づいて、サインイン時にユーザーに同意ダイアログを表示します。 ユーザーが 1 つ以上のスコープに同意してトークンを取得すると、同意先のスコープが結果の access_token にエンコードされます。
アプリケーションで要求されるスコープについては、authentication.properties を参照してください。 これらの 3 つのスコープは MSAL で要求され、既定で Microsoft Entra ID によって指定されます。