Sécuriser des applications Java JBoss EAP à l’aide de rôles et de revendications de rôle
Cet article présente une application Java JBoss EAP qui utilise OpenID Connect pour connecter des utilisateurs et des rôles d’application Microsoft Entra ID (rôles d’application) pour l’autorisation.
Cette application implémente le contrôle d’accès en fonction du rôle (RBAC) à l’aide des rôles d’application et de la fonctionnalité de revendications de rôle de Microsoft Entra ID. Une autre approche consiste à utiliser des groupes Microsoft Entra ID et des revendications de groupe. Les groupes Microsoft Entra ID et les rôles d’application ne s’excluent pas mutuellement. Vous pouvez utiliser les deux pour fournir un contrôle d’accès précis.
Vous pouvez également utiliser le RBAC avec des rôles d’application et des revendications de rôle pour appliquer en toute sécurité des stratégies d’autorisation.
Pour voir une vidéo qui couvre ce scénario et cet exemple, consultez Implémenter l’autorisation dans vos applications avec des rôles d’application, des groupes de sécurité, des étendues et des rôles d’annuaire.
Pour en savoir plus sur le fonctionnement des protocoles dans ce scénario et dans d’autres, consultez Authentification ou autorisation.
Cette application utilise MSAL pour Java (MSAL4J) pour connecter un utilisateur et obtenir un jeton d’ID à partir de Microsoft Entra ID.
Cet exemple utilise d’abord MSAL pour Java (MSAL4J) pour connecter l’utilisateur. La page d’accueil affiche une option permettant à l’utilisateur de voir les revendications dans ses jetons d’ID. Cette application permet également aux utilisateurs d’afficher une page d’administrateur privilégié ou une page d’utilisateur habituel, en fonction du rôle d’application qui leur a été affecté. Le but est de montrer comment, dans une application, l’accès à certaines fonctionnalités ou pages est limité à des sous-ensembles d’utilisateurs en fonction du rôle qui leur est affecté.
Ce type d’autorisation est implémenté à l’aide du RBAC. En utilisant le RBAC, un administrateur accorde des autorisations aux rôles, pas à des utilisateurs individuels ou à des groupes. L’administrateur peut alors attribuer des rôles aux différents utilisateurs et groupes pour contrôler l’accès à certains contenus et fonctionnalités.
Cet exemple d’application définit les deux rôles d’application suivants :
PrivilegedAdmin
: autorisé à accéder aux pages Administrateurs uniquement et Utilisateurs habituels.RegularUser
: autorisé à accéder à la page Utilisateurs habituels.
Ces rôles d’application sont définis dans le portail Azure au sein du manifeste de l’inscription d’application. Lorsqu’un utilisateur se connecte à l’application, Microsoft Entra ID émet une revendication de rôles pour chaque rôle accordé individuellement à l’utilisateur sous la forme d’une appartenance à un rôle.
Vous affecter des utilisateurs et des groupes à des rôles sur le portail Azure.
Remarque
Les revendications de rôle ne sont pas disponibles pour les utilisateurs invités d’un locataire si le point de terminaison https://login.microsoftonline.com/common/
est utilisé comme autorité pour connecter des utilisateurs. Vous devez connecter un utilisateur à un point de terminaison client tel que https://login.microsoftonline.com/tenantid
.
Prérequis
- JDK version 8 ou ultérieure
- Maven 3
- Un locataire Microsoft Entra ID. Pour en savoir plus, consultez Comment obtenir un locataire Microsoft Entra ID.
- Un compte d’utilisateur dans votre propre locataire Microsoft Entra ID si vous souhaitez utiliser des comptes dans votre annuaire organisationnel uniquement, c’est-à-dire en mode monolocataire. Si vous n’avez pas encore créé de compte d’utilisateur dans votre locataire, vous devez le faire avant de continuer. Pour en savoir plus, consultez Comment créer, inviter et supprimer des utilisateurs.
Recommandations
- Être familiarisé avec Java/Jakarta Servlets.
- Être familiarisé avec le terminal Linux/OSX.
- jwt.ms pour inspecter vos jetons.
- Fiddler pour la supervision de votre activité réseau et la résolution des problèmes.
- Suivez le blog Microsoft Entra ID pour rester au courant des dernières évolutions.
Configurer l’exemple
Les sections suivantes vous montrent comment configurer l’exemple d’application.
Clonez ou téléchargez l’exemple de dépôt
Pour cloner l’exemple, ouvrez une fenêtre Bash et utilisez la commande suivante :
git clone https://github.com/Azure-Samples/ms-identity-msal-java-samples.git
cd 3-java-servlet-web-app/3-Authorization-II/roles
Vous pouvez également accéder au dépôt ms-identity-msal-java-samples, puis le télécharger en tant que fichier .zip et l’extraire sur votre disque dur.
Important
Pour éviter les limitations de longueur de fichier sous Windows, clonez ou extrayez le dépôt dans un répertoire proche de la racine de votre disque dur.
Inscrivez l’exemple d’application auprès de votre locataire Microsoft Entra ID
Cet exemple contient un seul projet. Les sections suivantes vous montrent comment inscrire l’application à l’aide du Portail Azure.
Choisissez le locataire Microsoft Entra ID où vous voulez créer vos applications.
Pour choisir votre locataire, suivez les étapes ci-dessous :
Connectez-vous au portail Azure.
Si votre compte est présent dans plusieurs locataires Microsoft Entra ID, sélectionnez votre profil dans le coin du portail Azure, puis sélectionnez Changer d’annuaire pour faire correspondre votre session au locataire Microsoft Entra ID souhaité.
Inscrire l’application (java-servlet-webapp-roles)
Commencez par inscrire une nouvelle application dans le portail Azure en suivant les instructions de Démarrage rapide : inscrire une application sur la plateforme d’identité Microsoft.
Procédez comme suit pour compléter l’inscription :
Accédez à la page Inscriptions d’applications de la plateforme d’identités Microsoft pour les développeurs.
Sélectionnez Nouvelle inscription.
Dans la page Inscrire une application qui s’affiche, saisissez les informations suivantes relatives à l’inscription de votre application :
Dans la section Nom, saisissez un nom d’application cohérent qui s’affichera pour les utilisateurs de l’application, par exemple
java-servlet-webapp-roles
.Sous Types de comptes pris en charge, sélectionnez l’une des options suivantes :
- Sélectionnez Comptes dans cet annuaire organisationnel uniquement si vous créez une application destinée uniquement aux utilisateurs de votre locataire, c’est-à-dire une application monolocataire.
Dans la section URI de redirection, sélectionnez Web dans la zone de liste modifiable et entrez l’URI de redirection suivant :
http://localhost:8080/msal4j-servlet-roles/auth/redirect
.
Sélectionnez Inscrire pour créer l’application.
Dans la page d’inscription de l’application, recherchez et copiez la valeur ID d’application (client) pour l’utiliser ultérieurement. Vous utilisez cette valeur dans le ou les fichiers de configuration de votre application.
Cliquez sur Enregistrer pour enregistrer vos modifications.
Sur la page d’inscription de l’application, sélectionnez Certificats et secrets dans le volet de navigation pour ouvrir la page permettant de générer des secrets et de charger des certificats.
Dans la section Secrets client, sélectionnez Nouveau secret client.
Saisissez une description (par exemple, secret de l’application).
Sélectionnez l’une des durées disponibles : Dans 1 an, Dans 2 ans ou N’expire jamais.
Sélectionnez Ajouter. La valeur générée s’affiche.
Copiez et sauvegardez la valeur générée pour l’utiliser dans les étapes ultérieures. Vous avez besoin de cette valeur pour les fichiers de configuration de votre code. Cette valeur n’apparaîtra plus, et vous ne pouvez pas la récupérer par d’autres moyens. Veillez donc à la sauvegarder à partir du portail Azure avant d’accéder un autre écran ou à un autre volet.
Définition des rôles d’application
Pour définir les rôles d’application, procédez comme suit :
Sans quitter l’inscription d’application, sélectionnez Rôles d’application dans le volet de navigation.
Sélectionnez Créer un rôle d’application, puis saisissez les valeurs suivantes :
- Pour Nom d’affichage, saisissez un nom approprié, par exemple PrivilegedAdmin.
- Pour Types de membres autorisés, choisissez Utilisateur.
- Pour Valeur, saisissez PrivilegedAdmin.
- Pour Description, saisissez PrivilegedAdmins qui peut consulter la page d’administration.
Sélectionnez Créer un rôle d’application, puis saisissez les valeurs suivantes :
- Pour Nom d’affichage, saisissez un nom approprié, par exemple RegularUser.
- Pour Types de membres autorisés, choisissez Utilisateur.
- Pour Valeur, saisissez RegularUser.
- Pour Description, saisissez RegularUsers qui peut consulter la page utilisateur.
Sélectionnez Appliquer pour enregistrer vos modifications.
Attribuer des utilisateurs aux rôles d’application
Pour ajouter des utilisateurs au rôle d’application défini précédemment, suivez les instructions suivantes : Affecter des utilisateurs et des groupes à des rôles.
Configurer l’application (java-servlet-webapp-call-roles) pour utiliser l’inscription de votre application
Pour configurer l’application, procédez comme suit :
Remarque
Dans les étapes suivantes, ClientID
est identique à Application ID
ou AppId
.
Ouvrez le projet dans votre IDE.
Ouvrez le fichier authentication.properties.
Recherchez la chaîne
{enter-your-tenant-id-here}
. Remplacez la valeur existante par votre ID de locataire Microsoft Entra ID.Recherchez la chaîne
{enter-your-client-id-here}
et remplacez la valeur existante par l’ID d’application ou l’clientId
de l’applicationjava-servlet-webapp-call-graph
que vous avez copié à partir du portail Azure.Recherchez la chaîne
{enter-your-client-secret-here}
et remplacez la valeur existante par celle que vous avez sauvegardée durant la création de l’applicationjava-servlet-webapp-roles
dans le portail Azure.Recherchez la propriété
app.roles
et vérifiez que la valeur est définie surapp.roles=admin PrivilegedAdmin, user RegularUser
, ou remplacez les noms de vos rôles spécifiques.
Générer l’exemple
Pour générer l’exemple à l’aide de Maven, accédez au répertoire contenant le fichier pom.xml pour l’exemple, puis exécutez la commande suivante :
mvn clean package
Cette commande génère un fichier .war que vous pouvez exécuter sur différents serveurs d’applications.
Exécution de l'exemple
Les sections suivantes vous montrent comment déployer l’exemple dans Azure App Service.
Prérequis
Plug-in Maven pour les applications Azure App Service
Si Maven n’est pas votre outil de développement préféré, consultez les tutoriels similaires suivants qui utilisent d’autres outils :
Configurer le plug-in Maven
Le processus de déploiement sur Azure App Service utilise automatiquement vos informations d’identification Azure dans Azure CLI. Si Azure CLI n’est pas installé localement, le plug-in Maven s’authentifie avec OAuth ou la connexion de l’appareil. Pour plus d’informations, consultez Authentification avec les plug-ins Maven.
Pour configurer le plug-in, procédez comme suit :
Exécutez la commande Maven ci-dessous pour configurer le déploiement. Cette commande vous permet de configurer le système d’exploitation App Service, les versions de Java et Tomcat.
mvn com.microsoft.azure:azure-webapp-maven-plugin:2.12.0:config
Pour Créer une nouvelle configuration d’exécution, appuyez sur Y, puis sur Entrée.
Pour Définir la valeur du système d’exploitation, appuyez sur 2 pour Linux, puis sur Entrée.
Pour Définir la valeur pour javaVersion, appuyez sur 2 pour Java 11, puis appuyez sur Entrée.
Pour Définir la valeur de webContainer, appuyez sur 1 pour JBosseap7, puis sur Entrée.
Pour Définir la valeur de pricingTier, appuyez sur Entrée pour sélectionner le niveau P1v3 par défaut.
Pour Confirmer, appuyez sur Y, puis sur Entrée.
L’exemple suivant montre le résultat du processus de déploiement :
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] ------------------------------------------------------------------------
Une fois que vous avez confirmé vos choix, le plug-in ajoute la configuration du plug-in et les paramètres requis au fichier pom.xml de votre projet pour configurer votre application afin qu’elle s’exécute dans Azure App Service.
La partie concernée du fichier pom.xml doit ressembler à l’exemple suivant :
<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>
Vous pouvez modifier les configurations d’App Service directement dans votre pom.xml. Certaines configurations courantes sont répertoriées dans le tableau suivant :
Propriété | Obligatoire | Description | Version |
---|---|---|---|
schemaVersion |
false | La version du schéma de configuration. Les valeurs prises en charge sont v1 et v2 . |
1.5.2 |
subscriptionId |
false | L'ID de l'abonnement. | 0.1.0+ |
resourceGroup |
true | Le groupe de ressources Azure pour votre application. | 0.1.0+ |
appName |
true | Nom de votre application. | 0.1.0+ |
region |
false | Région dans laquelle héberger votre application. La valeur par défaut est centralus . Pour connaître les régions valides, consultez la section Régions prises en charge. |
0.1.0+ |
pricingTier |
false | Le niveau tarifaire pour votre application. La valeur par défaut est P1v2 pour une charge de travail de production. La valeur minimale recommandée pour le développement et le test Java est B2 . Pour en savoir plus, consultez Tarification d’App Service |
0.1.0+ |
runtime |
false | Configuration de l’environnement d’exécution. Pour plus d’informations, consultez Détails de configuration. | 0.1.0+ |
deployment |
false | Configuration du déploiement. Pour plus d’informations, consultez Détails de configuration. | 0.1.0+ |
Pour obtenir la liste complète des configurations, consultez la documentation de référence sur le plug-in. Tous les plug-ins Azure Maven partagent un ensemble commun de configurations. Pour ces configurations, voir Configurations communes. Pour les configurations spécifiques à Azure App Service, consultez Application Azure : détails de configuration.
Veillez à conserver les valeurs appName
et resourceGroup
pour une utilisation ultérieure.
Préparer l’application pour le déploiement
Lorsque vous déployez votre application sur App Service, votre URL de redirection devient l’URL de redirection de votre instance d’application déployée. Suivez les étapes ci-dessous pour modifier ces paramètres dans votre fichier des propriétés :
Naviguez jusqu’au fichier authentication.properties de votre application et remplacez la valeur
app.homePage
par le nom de domaine de votre application déployée, comme indiqué dans l’exemple suivant Par exemple, si vous avez choisiexample-domain
comme nom votre application à l’étape précédente, vous devez maintenant utiliserhttps://example-domain.azurewebsites.net
pour la valeurapp.homePage
. Assurez-vous d’avoir également remplacé le protocolehttp
parhttps
.# 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
Après avoir enregistré ce fichier, utilisez la commande suivante pour reconstruire votre application :
mvn clean package
Important
Dans ce même fichier authentication.properties , vous avez un paramètre pour votre aad.secret
. Il n’est pas recommandé de déployer cette valeur sur App Service. Il n’est pas non plus recommandé de laisser cette valeur dans votre code et de l’envoyer vers votre dépôt Git. Pour supprimer cette valeur secrète de votre code, vous trouverez des instructions plus détaillées dans la section Déployer sur App Service - Supprimer le secret. Ces instructions ajoutent des étapes supplémentaires pour envoyer la valeur secrète à Key Vault et utiliser les références Key Vault.
Mettez à jour l’enregistrement de votre application Microsoft Entra ID
Étant donné que l’URI de redirection change pour votre application déployée sur Azure App Service, vous devez également modifier l’URI de redirection dans votre enregistrement d’application Microsoft Entra ID. Pour cela, effectuez les étapes suivantes :
Accédez à la page Inscriptions d’applications de la plateforme d’identités Microsoft pour les développeurs.
Utilisez le champ de recherche pour rechercher l’enregistrement de votre application - par exemple,
java-servlet-webapp-authentication
.Ouvrez votre enregistrement d’application en sélectionnant son nom.
Sélectionnez Authentification dans le menu déroulant.
Dans la section Web - Redirection des URI, sélectionnez Ajouter un URI.
Remplissez l’URI de votre application, en ajoutant
/auth/redirect
- par exemple,https://<your-app-name>.azurewebsites.net/auth/redirect
.Cliquez sur Enregistrer.
Déployer l’application
Vous êtes maintenant prêt(e) à déployer votre application sur Azure App Service. Utilisez la commande suivante pour vous assurer que vous êtes connecté(e) à votre environnement Azure pour exécuter le déploiement :
az login
Une fois que la configuration est prête dans votre fichier pom.xml, vous pouvez utiliser la commande suivante pour déployer votre application Java sur Azure :
mvn package azure-webapp:deploy
Une fois le déploiement terminé, votre application est prête sur http://<your-app-name>.azurewebsites.net/
. Ouvrez l’URL avec votre navigateur web local, dans lequel doit s’afficher la page de démarrage de l’application msal4j-servlet-auth
.
Explorer l’exemple
Procédez comme suit pour examiner l’exemple :
- Notez l’état de connexion ou de déconnexion qui s’affiche au centre de l’écran.
- Sélectionnez le bouton contextuel dans le coin. Ce bouton indique Connexion lorsque vous exécutez l’application pour la première fois.
- Suivez les instructions de la page suivante et connectez-vous avec un compte dans le locataire Microsoft Entra ID.
- Sur l’écran de consentement, notez les portées demandées.
- Notez que le bouton contextuel indique maintenant Déconnexion et affiche votre nom d’utilisateur.
- Sélectionnez Détails du jeton d’ID pour voir certaines des revendications décodées du jeton d’ID.
- Sélectionnez Administrateurs uniquement pour afficher la page
/admin_only
. Seuls les utilisateurs disposant d’un rôle d’applicationPrivilegedAdmin
peuvent voir cette page. Pour les autres, un message d’échec d’autorisation s’affiche. - Sélectionnez Utilisateurs habituels pour afficher la page
/regular_user
. Seuls les utilisateurs disposant d’un rôle d’applicationRegularUser
ouPrivilegedAdmin
peuvent voir cette page. Pour les autres, un message d’échec d’autorisation s’affiche. - Utilisez le bouton dans le coin pour vous déconnecter.
À propos du code
Dans cet exemple, nous utilisons MSAL pour Java (MSAL4J) pour connecter un utilisateur et obtenir un jeton d’ID susceptible de contenir la revendication de rôles. En fonction de la revendication de rôles disponible, l’utilisateur connecté ne peut accéder à aucune, à une ou aux deux des pages protégées, Admins Only
et Regular Users
.
Si vous souhaitez répliquer le comportement de cet exemple, vous pouvez copier le fichier pom.xml et le contenu des dossiers helpers et authservlets dans le dossier src/main/java/com/microsoft/azuresamples/msal4j. Vous avez également besoin du fichier authentication.properties. Ces classes et ces fichiers contiennent du code générique que vous pouvez utiliser dans un large éventail d’applications. Vous pouvez également copier le reste de l’exemple, mais les autres classes et fichiers sont créés spécifiquement aux fins de l’objectif de cet exemple.
Contenu
Le tableau suivant montre le contenu de l’exemple de dossier du projet :
Fichier/Dossier | Description |
---|---|
src/main/java/com/microsoft/azuresamples/msal4j/roles/ | Ce répertoire contient les classes qui définissent la logique métier principale de l’application. |
src/main/java/com/microsoft/azuresamples/msal4j/authservlets/ | Ce répertoire contient les classes utilisées pour les points de terminaison de connexion et de déconnexion. |
____Servlet.java | Tous les points de terminaison disponibles sont définis dans les classe .java qui se terminent par ____Servlet.java. |
src/main/java/com/microsoft/azuresamples/msal4j/helpers/ | Classes d’assistance pour l’authentification. |
AuthenticationFilter.java | Redirige les demandes non authentifiées vers des points de terminaison protégés vers une page 401. |
src/main/resources/authentication.properties | Configuration de Microsoft Entra ID et du programme. |
src/main/webapp/ | Ce répertoire contient l’interface utilisateur - Modèles JSP |
CHANGELOG.md | Liste des modifications apportées à l’exemple. |
CONTRIBUTING.md | Instructions pour contribuer à l’exemple. |
LICENCE | Licence de l’exemple. |
Traiter une revendication de rôles dans le jeton d’ID
La revendication de rôles du jeton inclut les noms des rôles auxquels l’utilisateur connecté est affecté, comme dans l’exemple suivant :
{
...
"roles": [
"Role1",
"Role2",]
...
}
ConfidentialClientApplication
Une ConfidentialClientApplication
instance est créée dans le fichier AuthHelper.java, comme le montre l’exemple suivant. Cet objet permet de créer l’URL d’autorisation de Microsoft Entra et d’échanger le jeton d’authentification contre un jeton d’accès.
// getConfidentialClientInstance method
IClientSecret secret = ClientCredentialFactory.createFromSecret(SECRET);
confClientInstance = ConfidentialClientApplication
.builder(CLIENT_ID, secret)
.authority(AUTHORITY)
.build();
Les paramètres suivants sont utilisés pour l’instanciation :
- ID client de l’application.
- Secret client, lequel est une exigence pour les applications clientes confidentielles.
- L’autorité Microsoft Entra ID, qui inclut votre ID de locataire Microsoft Entra.
Dans cet exemple, ces valeurs sont lues à partir du fichier authentication.properties avec un lecteur de propriétés dans le fichier Config.java.
Procédure pas-à-pas
Les étapes suivantes présentent le fonctionnement détaillé de l’application :
La première étape du processus de connexion consiste à envoyer une demande au point de terminaison
/authorize
de votre locataire Microsoft Entra ID. L’instanceConfidentialClientApplication
MSAL4J est utilisée pour construire une URL de demande d’autorisation. L’application redirige le navigateur vers cette URL, où l’utilisateur se connecte.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);
La liste suivante décrit les fonctionnalités de ce code :
AuthorizationRequestUrlParameters
: paramètres qui doivent être définis pour générer un AuthorizationRequestUrl.REDIRECT_URI
: où Microsoft Entra ID redirige le navigateur, avec le code d’authentification, après avoir collecté les informations d’identification de l’utilisateur. Il doit correspondre à l’URI de redirection dans l’inscription de l’application Microsoft Entra ID sur le portail Azure.SCOPES
: les Étendues sont des autorisations demandées par l’application.- Normalement, les trois étendues
openid profile offline_access
suffisent pour recevoir une réponse du jeton d’ID. - Vous trouverez la liste complète des étendues demandées par l’application dans le fichier authentication.properties. Vous pouvez ajouter d’autres étendues telles que
User.Read
.
- Normalement, les trois étendues
L’utilisateur reçoit une invite de connexion de Microsoft Entra ID. Si la tentative de connexion réussit, le navigateur de l’utilisateur est redirigé vers le point de terminaison de redirection de l’application. Une requête valide à ce point de terminaison contient un code d’autorisation.
L’instance
ConfidentialClientApplication
échange ensuite ce code d’autorisation contre un jeton d’ID et un jeton d’accès à partir de 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();
La liste suivante décrit les fonctionnalités de ce code :
AuthorizationCodeParameters
: paramètres qui doivent être définis pour échanger le code d’autorisation contre un ID et/ou un jeton d’accès.authCode
: code d’autorisation reçu au niveau du point de terminaison de redirection.REDIRECT_URI
: l’URI de redirection utilisé à l’étape précédente doit être repassé.SCOPES
: les étendues utilisées à l’étape précédente doivent être repassées.
Si
acquireToken
réussit, les revendications du jeton sont extraites. Si le contrôle nonce réussit, les résultats sont placés danscontext
(instance deIdentityContextData
) et enregistrés dans la session. L’application peut ensuite instancier lesIdentityContextData
à partir de la session (au moyen d’une instance deIdentityContextAdapterServlet
) chaque fois qu’elle a besoin d’y accéder, comme montré dans le code suivant :// 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());
Protéger les itinéraires
Pour en savoir plus sur la façon dont l’exemple d’application filtre l’accès aux itinéraires, consultez AuthenticationFilter.java. Dans le fichier authentication.properties, la propriété app.protect.authenticated
contient les itinéraires séparés par des virgules auxquels seuls les utilisateurs authentifiés peuvent accéder, comme illustré dans l’exemple suivant :
# for example, /token_details requires any user to be signed in and does not require special roles claim(s)
app.protect.authenticated=/token_details
Les itinéraires répertoriés dans les ensembles de règles séparés par des virgules sous le app.protect.roles
ont également hors limites pour les utilisateurs non authentifiés, comme le montre l’exemple suivant. Cependant, ces itinéraires contiennent également une liste de rôles d’application séparés par des espaces : seuls les utilisateurs ayant au moins l’un des rôles correspondants peuvent accéder à ces itinéraires après s’être authentifiés.
# 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
Étendues
Les étendues indiquent à Microsoft Entra ID le niveau d’accès demandé par l’application.
Selon les étendues demandées, Microsoft Entra ID affiche une boîte de dialogue invitant l’utilisateur à donner son consentement au moment de la connexion. Si l’utilisateur donne son consentement pour une ou plusieurs étendues et obtient un jeton, les étendues qui ont fait l’objet d’un consentement sont encodées dans le access_token
obtenu.
Pour connaître les étendues demandées par l’application, consultez authentication.properties. Ces trois étendues sont demandées par MSAL et fournies par Microsoft Entra ID par défaut.
Plus d’informations
- Bibliothèque d’authentification Microsoft (MSAL) pour Java
- Plateforme d’identité Microsoft
- Démarrage rapide : Inscrire une application à l’aide de la plateforme d’identités Microsoft
- Comprendre les expériences de consentement à l’application Microsoft Entra ID
- Comprendre le consentement de l’utilisateur et de l’administrateur
- Exemples de code MSAL
- Procédure : ajouter des rôles d’application dans votre application et les recevoir dans le jeton
- Gestion de l’attribution d’utilisateurs pour une application dans Microsoft Entra ID