Secure Java JBoss EAP apps using groups and group claims
This article shows you how to create a Java JBoss EAP app that signs in users with Microsoft Authentication Library (MSAL) for Java. The app also restricts access to pages based on Microsoft Entra ID security group membership.
The following diagram shows the topology of the app:
The client app uses MSAL for Java (MSAL4J) to sign in users to a Microsoft Entra ID tenant and obtain an ID token from Microsoft Entra ID. The ID token proves that a user is authenticated with this tenant. The app protects its routes according to user's authentication status and group membership.
For a video that covers this scenario, see Implement authorization in your applications using app roles, security groups, scopes, and directory roles.
Prerequisites
- JDK version 8 or higher
- Maven 3
- A Microsoft Entra ID tenant. For more information, see How to get a Microsoft Entra ID tenant.
- A user account in your own Microsoft Entra ID tenant.
- Two security groups,
GroupAdmin
andGroupMember
, containing users you want to test with.
Recommendations
- Some familiarity with the Java / Jakarta Servlets.
- Some familiarity with Linux/OSX terminal.
- jwt.ms for inspecting your tokens.
- Fiddler for monitoring your network activity and troubleshooting.
- Follow the Microsoft Entra ID Blog to stay up-to-date with the latest developments.
Set up the sample
The following sections show you how to set up the sample application.
Clone or download the sample repository
To clone the sample, open a Bash window and use the following command:
git clone https://github.com/Azure-Samples/ms-identity-msal-java-samples.git
cd 3-java-servlet-web-app/3-Authorization-II/groups
Alternatively, navigate to the ms-identity-msal-java-samples repository, then download it as a .zip file and extract it to your hard drive.
Important
To avoid file path length limitations on Windows, clone or extract the repository into a directory near the root of your hard drive.
Register the sample application with your Microsoft Entra ID tenant
There's one project in this sample. The following sections show you how to register the app using the Azure portal.
Choose the Microsoft Entra ID tenant where you want to create your applications
To choose your tenant, use the following steps:
Sign in to the Azure portal.
If your account is present in more than one Microsoft Entra ID tenant, select your profile in the corner of the Azure portal, and then select Switch directory to change your session to the desired Microsoft Entra ID tenant.
Register the app (java-servlet-webapp-groups)
First, register a new app in the Azure portal by following the instructions in Quickstart: Register an application with the Microsoft identity platform.
Then, use the following steps to complete the registration:
Navigate to the Microsoft identity platform for developers App registrations page.
Select New registration.
In the Register an application page that appears, enter the following app registration information:
- In the Name section, enter a meaningful application name for display to users of the app - for example,
java-servlet-webapp-groups
. - Under Supported account types, select Accounts in this organizational directory only.
- In the Redirect URI section, select Web in the combo-box and enter the following redirect URI:
http://localhost:8080/msal4j-servlet-groups/auth/redirect
.
- In the Name section, enter a meaningful application name for display to users of the app - for example,
Select Register to create the application.
On the app's registration page, find and copy the Application (client) ID value to use later. You use this value in your app's configuration file or files.
Select Save to save your changes.
On the app's registration page, select Certificates & secrets on the navigation pane to open the page where you can generate secrets and upload certificates.
In the Client secrets section, select New client secret.
Type a description - for example, app secret.
Select one of the available durations: In 1 year, In 2 years, or Never Expires.
Select Add. The generated value is displayed.
Copy and save the generated value for use in later steps. You need this value for your code's configuration files. This value isn't displayed again, and you can't retrieve it by any other means. So, be sure to save it from the Azure portal before you navigate to any other screen or pane.
On the app's registration page, select API permissions from the navigation pane to open the page to add access to the APIs that your application needs.
Select Add a permission.
Ensure that the Microsoft APIs tab is selected.
In the Commonly used Microsoft APIs section, select Microsoft Graph.
In the Delegated permissions section, select User.Read and GroupMember.Read.All from the list. Use the search box if necessary.
Select Add permissions.
GroupMember.Read.All
requires admin consent, so select Grant/revoke admin consent for {tenant}, and then select Yes when you're asked if you want to grant consent for the requested permissions for all accounts in the tenant. You need to be a Microsoft Entra ID tenant admin to do this action.
Configure the app (java-servlet-webapp-groups) to use your app registration
Use the following steps to configure the app:
Note
In the following steps, ClientID
is the same as Application ID
or AppId
.
Open the project in your IDE.
Open the ./src/main/resources/authentication.properties file.
Find the string
{enter-your-tenant-id-here}
. Replace the existing value with your Microsoft Entra tenant ID if you registered your app with the Accounts in this organizational directory only option.Find the string
{enter-your-client-id-here}
and replace the existing value with the application ID orclientId
of thejava-servlet-webapp-groups
application copied from the Azure portal.Find the string
{enter-your-client-secret-here}
and replace the existing value with the value you saved during the creation of thejava-servlet-webapp-groups
app, in the Azure portal.
Configure security groups
You have the following options available on how you can further configure your applications to receive the groups claim:
Receive all the groups that the signed-in user is assigned to in a Microsoft Entra ID tenant, included nested groups. For more information, see the section Configure your application to receive all the groups the signed-in user is assigned to, including nested groups.
Receive the groups claim values from a filtered set of groups that your application is programmed to work with. For more information, see the section Configure your application to receive the groups claim values from a filtered set of groups a user might be assigned to. This option isn't available in the Microsoft Entra ID Free edition.
Note
To get the on-premise group's samAccountName
or On Premises Group Security Identifier
instead of the group ID, see the section Prerequisites for using group attributes synchronized from Active Directory in Configure group claims for applications by using Microsoft Entra ID.
Configure your application to receive all the groups the signed-in user is assigned to, including nested groups
To configure your application, use the following steps:
On the app's registration page, select Token Configuration on the navigation pane to open the page where you can configure the claims provided tokens issued to your application.
Select Add groups claim to open the Edit Groups Claim screen.
Select Security groups OR the All groups (includes distribution lists but not groups assigned to the application) option. Choosing both options negates the effect of the Security Groups option.
Under the ID section, select Group ID. This selection causes Microsoft Entra ID to send the object ID of the groups the user is assigned to in the groups claim of the ID token that your app receives after signing-in a user.
Configure your application to receive the groups claim values from a filtered set of groups a user might be assigned to
This option is useful when the following cases are true:
- Your application is interested in a selected set of groups that a signing-in user might be assigned to.
- Your application isn't interested in every security group this user is assigned to in the tenant.
This option helps your application avoid the overage issue.
Note
This feature isn't available in the Microsoft Entra ID Free edition.
Nested group assignments aren't available when you use this option.
To enable this option in your app, use the following steps:
On the app's registration page, select Token Configuration on the navigation pane to open the page where you can configure the claims provided tokens issued to your application.
Select Add groups claim to open the Edit Groups Claim screen.
Select Groups assigned to the application.
Choosing other options - such as Security Groups or All groups (includes distribution lists but not groups assigned to the application) - negates the benefits your app derives from choosing to use this option.
Under the ID section, select Group ID. This selection results in Microsoft Entra ID sending the object ID of the groups the user is assigned to in the groups claim of the ID token.
If you're exposing a web API using the Expose an API option, then you can also choose the Group ID option under the Access section. This option results in Microsoft Entra ID sending the object ID of the groups the user is assigned to in the groups claim of the access token.
On the app's registration page, select Overview on the navigation pane to open the application overview screen.
Select the hyperlink with the name of your application in Managed application in local directory. This field title might be truncated - for instance
Managed application in ...
. When you select this link, you navigate to the Enterprise Application Overview page associated with the service principal for your application in the tenant where you created it. You can navigate back to the app registration page by using the back button of your browser.Select Users and groups on the navigation pane to open the page where you can assign users and groups to your application.
Select Add user.
Select User and Groups from the resultant screen.
Choose the groups that you want to assign to this application.
Select Select to finish selecting the groups.
Select Assign to finish the group assignment process.
Your application now receives these selected groups in the groups claim when a user signing in to your app is a member of one or more these assigned groups.
Select Properties on the navigation pane to open the page that lists the basic properties of your application.Set the User assignment required? flag to Yes.
Important
When you set User assignment required? to Yes, Microsoft Entra ID checks that only users assigned to your application in the Users and groups pane are able to sign-in to your app. You can assign users directly or by assigning security groups they belong to.
Configure the app (java-servlet-webapp-groups) to recognize group IDs
Use the following steps to configure the app:
Important
On the Token Configuration page, if you chose any option other than groupID - such as DNSDomain\sAMAccountName - you should enter the group name in the following steps - for example, contoso.com\Test Group
- instead of the object ID:
Open the ./src/main/resources/authentication.properties file.
Find the string
{enter-your-admins-group-id-here}
and replace the existing value with the object ID of theGroupAdmin
group, which you copied from the Azure portal. Remove the curly braces from the placeholder value as well.Find the string
{enter-your-users-group-id-here}
and replace the existing value with the object ID of theGroupMember
group, which you copied from the Azure portal. Remove the curly braces from the placeholder value as well.
Build the sample
To build the sample using Maven, navigate to the directory containing the pom.xml file for the sample, and then run the following command:
mvn clean package
This command generates a .war file that you can run on various application servers.
Run the sample
The following sections show you how to deploy the sample to Azure App Service.
Prerequisites
Maven Plugin for Azure App Service apps
If Maven isn't your preferred development tool, see the following similar tutorials that use other tools:
Configure the Maven plugin
The deployment process to Azure App Service uses your Azure credentials from the Azure CLI automatically. If the Azure CLI isn't installed locally, then the Maven plugin authenticates with OAuth or device sign-in. For more information, see authentication with Maven plugins.
Use the following steps to configure the plugin:
Run the Maven command shown next to configure the deployment. This command helps you to set up the App Service operating system, Java version, and Tomcat version.
mvn com.microsoft.azure:azure-webapp-maven-plugin:2.12.0:config
For Create new run configuration, press Y, then press Enter.
For Define value for OS, press 2 for Linux, then press Enter.
For Define value for javaVersion, press 2 for Java 11, then press Enter.
For Define value for webContainer, press 1 for JBosseap7, then press Enter.
For Define value for pricingTier, press Enter to select the default P1v3 tier.
For Confirm, press Y, then press Enter.
The following example shows the output of the deployment process:
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] ------------------------------------------------------------------------
After you've confirmed your choices, the plugin adds the plugin configuration and required settings to your project's pom.xml file to configure your app to run in Azure App Service.
The relevant portion of the pom.xml file should look similar to the following example:
<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>
You can modify the configurations for App Service directly in your pom.xml. Some common configurations are listed in the following table:
Property | Required | Description | Version |
---|---|---|---|
schemaVersion |
false | The version of the configuration schema. Supported values are v1 and v2 . |
1.5.2 |
subscriptionId |
false | The subscription ID. | 0.1.0+ |
resourceGroup |
true | The Azure resource group for your app. | 0.1.0+ |
appName |
true | The name of your app. | 0.1.0+ |
region |
false | The region in which to host your app. The default value is centralus . For valid regions, see Supported Regions. |
0.1.0+ |
pricingTier |
false | The pricing tier for your app. The default value is P1v2 for a production workload. The recommended minimum value for Java development and testing is B2 . For more information, see App Service Pricing |
0.1.0+ |
runtime |
false | The runtime environment configuration. For more information, see Configuration Details. | 0.1.0+ |
deployment |
false | The deployment configuration. For more information, see Configuration Details. | 0.1.0+ |
For the complete list of configurations, see the plugin reference documentation. All the Azure Maven plugins share a common set of configurations. For these configurations, see Common Configurations. For configurations specific to Azure App Service, see Azure app: Configuration Details.
Be sure to save aside the appName
and resourceGroup
values for later use.
Prepare the app for deployment
When you deploy your application to App Service, your redirect URL changes to the redirect URL of your deployed app instance. Use the following steps to change these settings in your properties file:
Navigate to your app's authentication.properties file and change the value of
app.homePage
to your deployed app's domain name, as shown in the following example. For example, if you choseexample-domain
for your app name in the previous step, you must now usehttps://example-domain.azurewebsites.net
for theapp.homePage
value. Be sure that you've also changed the protocol fromhttp
tohttps
.# 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
After saving this file, use the following command to rebuild your app:
mvn clean package
Important
In this same authentication.properties file you have a setting for your aad.secret
. It isn't a good practice to deploy this value to App Service. Neither is it a good practice to leave this value in your code and potentially push it up to your git repository. For removing this secret value from your code, you can find more detailed guidance in the Deploy to App Service - Remove secret section. This guidance adds extra steps for pushing the secret value to Key Vault and to use Key Vault References.
Update your Microsoft Entra ID app registration
Because the redirect URI changes to your deployed app to Azure App Service, you also need to change the redirect URI in your Microsoft Entra ID app registration. Use the following steps to make this change:
Navigate to the Microsoft identity platform for developers App registrations page.
Use the search box to search for your app registration - for example,
java-servlet-webapp-authentication
.Open your app registration by selecting its name.
Select Authentication from the menu.
In the Web - Redirect URIs section, select Add URI.
Fill out the URI of your app, appending
/auth/redirect
- for example,https://<your-app-name>.azurewebsites.net/auth/redirect
.Select Save.
Deploy the app
You're now ready to deploy your app to Azure App Service. Use the following command to make sure you're signed in to your Azure environment to execute the deployment:
az login
With all the configuration ready in your pom.xml file, you can now use the following command to deploy your Java app to Azure:
mvn package azure-webapp:deploy
After deployment is completed, your application is ready at http://<your-app-name>.azurewebsites.net/
. Open the URL with your local web browser, where you should see the start page of the msal4j-servlet-auth
application.
Explore the sample
Use the following steps to explore the sample:
- Notice the signed-in or signed-out status displayed at the center of the screen.
- Select the context-sensitive button in the corner. This button reads Sign In when you first run the app.
- On the next page, follow the instructions and sign in with an account in the Microsoft Entra ID tenant.
- On the consent screen, notice the scopes that are being requested.
- Notice that the context-sensitive button now says Sign out and displays your username.
- Select ID Token Details to see some of the ID token's decoded claims.
- Select Groups to see any information about security group membership for the signed-in user.
- Select Admin Only or Regular User to access the groups claim protected endpoints.
- If your signed-in user is in the
GroupAdmin
group, the user can enter both pages. - If your signed-in user is in the
GroupMember
group, the user can enter the Regular User page only. - If your signed-in user is in neither group, the user can't access either of the two pages.
- If your signed-in user is in the
- Use the button in the corner to sign out.
- After signing out, select ID Token Details to observe that the app displays a
401: unauthorized
error instead of the ID token claims when the user isn't authorized.
About the code
This sample uses MSAL for Java (MSAL4J) to sign a user in and obtain an ID token that might contain the groups claim. If there are too many groups for emission in the ID token, the sample uses Microsoft Graph SDK for Java to obtain the group membership data from Microsoft Graph. Based on the groups the user belongs to, the signed-in user can access either none, one, or both of the protected pages, Admins Only
and Regular Users
.
If you want to replicate this sample's behavior, you must add MSAL4J and Microsoft Graph SDK to your projects using Maven. You can copy the pom.xml file and the contents of the helpers and authservlets folders in the src/main/java/com/microsoft/azuresamples/msal4j folder. You also need the authentication.properties file. These classes and files contain generic code that you can use in a wide array of applications. You can copy the rest of the sample as well, but the other classes and files are built specifically to address this sample's objective.
Contents
The following table shows the contents of the sample project folder:
File/folder | Description |
---|---|
src/main/java/com/microsoft/azuresamples/msal4j/groupswebapp/ | This directory contains the classes that define the app's backend business logic. |
src/main/java/com/microsoft/azuresamples/msal4j/authservlets/ | This directory contains the classes that are used for sign in and sign out endpoints. |
____Servlet.java | All of the endpoints available are defined in .java classes ending in ____Servlet.java. |
src/main/java/com/microsoft/azuresamples/msal4j/helpers/ | Helper classes for authentication. |
AuthenticationFilter.java | Redirects unauthenticated requests to protected endpoints to a 401 page. |
src/main/resources/authentication.properties | Microsoft Entra ID and program configuration. |
src/main/webapp/ | This directory contains the UI - JSP templates |
CHANGELOG.md | List of changes to the sample. |
CONTRIBUTING.md | Guidelines for contributing to the sample. |
LICENSE | The license for the sample. |
Process a groups claim in tokens, including handling overage
The following sections describe how the app processes a groups claim.
The groups claim
The object ID of the security groups the signed-in user is member of is returned in the groups claim of the token, shown in the following example:
{
...
"groups": [
"0bbe91cc-b69e-414d-85a6-a043d6752215",
"48931dac-3736-45e7-83e8-015e6dfd6f7c",]
...
}
The groups overage claim
To ensure that the token size doesn't exceed HTTP header size limits, the Microsoft identity platform limits the number of object IDs that it includes in the groups claim.
The overage limit is 150 for SAML tokens, 200 for JWT tokens, and 6 for Single Page applications. If a user is member of more groups than the overage limit, then the Microsoft identity platform doesn't emit the group IDs in the groups claim in the token. Instead, it includes an overage claim in the token that indicates to the application to query the Microsoft Graph API to retrieve the user's group membership, as shown in the following example:
{
...
"_claim_names": {
"groups": "src1"
},
{
"_claim_sources": {
"src1": {
"endpoint":"[Graph Url to get this user's group membership from]"
}
}
...
}
Create the overage scenario in this sample for testing
To create the overage scenario, you can use the following steps:
You can use the BulkCreateGroups.ps1 file provided in the AppCreationScripts folder to create a large number of groups and assign users to them. This file helps test overage scenarios during development. Remember to change the user's
objectId
provided in the BulkCreateGroups.ps1 script.When you run this sample and an overage occurs, you see the
_claim_names
in the home page after the user signs in.We strongly advise that you use the group filtering feature, if possible, to avoid running into group overages. For more information, see the section Configure your application to receive the groups claim values from a filtered set of groups a user might be assigned to.
In case you can't avoid running into group overage, we suggest you use the following steps to process the groups claim in your token:
- Check for the claim
_claim_names
with one of the values being groups. This claim indicates overage. - If found, make a call to the endpoint specified in
_claim_sources
to fetch user's groups. - If none found, look into the groups claim for user's groups.
- Check for the claim
Note
Handling overage requires a call to Microsoft Graph to read the signed-in user's group memberships, so your app needs to have the GroupMember.Read.All permission for the getMemberObjects function to execute successfully.
For more information about programming for Microsoft Graph, see the video An introduction to Microsoft Graph for developers.
ConfidentialClientApplication
A ConfidentialClientApplication
instance is created in the AuthHelper.java file, as shown in the following example. This object helps craft the Microsoft Entra authorization URL and also helps exchange the authentication token for an access token.
// getConfidentialClientInstance method
IClientSecret secret = ClientCredentialFactory.createFromSecret(SECRET);
confClientInstance = ConfidentialClientApplication
.builder(CLIENT_ID, secret)
.authority(AUTHORITY)
.build();
The following parameters are used for instantiation:
- The client ID of the app.
- The client secret, which is a requirement for Confidential Client Applications.
- The Microsoft Entra ID Authority, which includes your Microsoft Entra tenant ID.
In this sample, these values are read from the authentication.properties file using a properties reader in the Config.java file.
Step-by-step walkthrough
The following steps provide a walkthrough of the app's functionality:
The first step of the sign-in process is to send a request to the
/authorize
endpoint on for your Microsoft Entra ID tenant. The MSAL4JConfidentialClientApplication
instance is used to construct an authorization request URL. The app redirects the browser to this URL, which is where the user signs in.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);
The following list describes the features of this code:
AuthorizationRequestUrlParameters
: Parameters that must be set in order to build an AuthorizationRequestUrl.REDIRECT_URI
: Where Microsoft Entra redirects the browser - along with the auth code - after collecting user credentials. It must match the redirect URI in the Microsoft Entra ID app registration in the Azure portal.SCOPES
: Scopes are permissions requested by the application.- Normally, the three scopes
openid profile offline_access
suffice for receiving an ID token response. - Full list of scopes requested by the app can be found in the authentication.properties file. You can add more scopes, such as
User.Read
.
- Normally, the three scopes
The user is presented with a sign-in prompt by Microsoft Entra ID. If the sign-in attempt is successful, the user's browser is redirected to the app's redirect endpoint. A valid request to this endpoint contains an authorization code.
The
ConfidentialClientApplication
instance then exchanges this authorization code for an ID token and access token from Microsoft Entra 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();
The following list describes the features of this code:
AuthorizationCodeParameters
: Parameters that must be set in order to exchange the Authorization Code for an ID and/or access token.authCode
: The authorization code that was received at the redirect endpoint.REDIRECT_URI
: The redirect URI used in the previous step must be passed again.SCOPES
: The scopes used in the previous step must be passed again.
If
acquireToken
is successful, the token claims are extracted. If the nonce check passes, the results are placed incontext
- an instance ofIdentityContextData
- and saved to the session. The application can then instantiate theIdentityContextData
from the session by way of an instance ofIdentityContextAdapterServlet
whenever it needs access to it, as shown in the following code:// 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()); // handle groups overage if it has occurred. handleGroupsOverage(contextAdapter);
After previous step, you can extract group memberships by calling
context.getGroups()
using an instance ofIdentityContextData
.If the user is a member of too many groups - more than 200 - a call to
context.getGroups()
might be empty if not for the call tohandleGroupsOverage()
. Meanwhile,context.getGroupsOverage()
returnstrue
, signaling that an overage occurred, and that getting the full list of groups requires a call to Microsoft Graph. See thehandleGroupsOverage()
method in AuthHelper.java to see how this application usescontext.setGroups()
when there's an overage.
Protect the routes
See AuthenticationFilter.java to see how the sample app filters access to routes. In the authentication.properties file, the app.protect.authenticated
property contains the comma-separated routes that only authenticated users can access, as shown in the following example:
# for example, /token_details requires any user to be signed in and does not require special groups claim
app.protect.authenticated=/token_details
Any of the routes listed in the comma-separated rule sets under the app.protect.groups
are also off-limits to non-authenticated authenticated users, as shown in the following example. However, these routes also contain a space-separated list of group memberships. Only users belonging to at least one of the corresponding groups can access these routes after authenticating.
# define short names for group IDs here for the app. This is useful in the next property (app.protect.groups).
# EXCLUDE the curly braces, they are in this file only as delimiters.
# example:
# app.groups=groupA abcdef-qrstuvw-xyz groupB abcdef-qrstuv-wxyz
app.groups=admin {enter-your-admins-group-id-here}, user {enter-your-users-group-id-here}
# A route and its corresponding group(s) that can view it, <space-separated>; the start of the next route & its group(s) is delimited by a <comma-and-space-separator>
# this says: /admins_only can be accessed by admin group, /regular_user can be accessed by admin group and user group
app.protect.groups=/admin_only admin, /regular_user admin user
Scopes
Scopes tell Microsoft Entra ID the level of access that the application is requesting.
Based on the requested scopes, Microsoft Entra ID presents a consent dialogue to the user upon sign-in. If the user consents to one or more scopes and obtains a token, the scopes-consented-to are encoded into the resulting access_token
.
For the scopes requested by the application, see authentication.properties. By default, the application sets the scopes value to GroupMember.Read.All
. This particular Microsoft Graph API scope is required in case the application needs to call Graph for getting the user's group memberships.
More information
- Microsoft Authentication Library (MSAL) for Java
- Microsoft identity platform (Microsoft Entra ID for developers)
- Quickstart: Register an application with the Microsoft identity platform
- Understanding Microsoft Entra ID application consent experiences
- Understand user and admin consent
- MSAL code samples