Sécuriser les applications WebSphere Java à l’aide de rôles d’application et de revendications de rôle

  • Article

Cet article illustre une application Java WebSphere qui utilise openID Connecter 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 d’ID Microsoft Entra et des revendications de groupe. Les groupes d’ID Microsoft Entra et les rôles d’application ne sont pas mutuellement exclusifs. Vous pouvez les utiliser pour fournir un contrôle d’accès affiné.

Vous pouvez également utiliser 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 obtenir une vidéo qui couvre ce scénario et cet exemple, consultez Implémenter l’autorisation dans vos applications à l’aide de rôles d’application, de groupes de sécurité, d’étendues et de rôles d’annuaire.

Pour plus d’informations sur le fonctionnement des protocoles dans ce scénario et dans d’autres scénarios, consultez Authentification et autorisation.

Cette application utilise MSAL pour Java (MSAL4J) pour se connecter à un utilisateur et obtenir un jeton d’ID à partir de l’ID Microsoft Entra.

Cet exemple utilise d’abord MSAL pour Java (MSAL4J) pour se connecter à l’utilisateur. Dans la page d’accueil, il affiche une option permettant à l’utilisateur d’afficher les revendications dans leurs jetons d’ID. Cette application permet également aux utilisateurs d’afficher une page d’administration privilégiée ou une page utilisateur régulière, en fonction du rôle d’application auquel ils ont été affectés. L’idée est de fournir un exemple de la façon dont, dans une application, l’accès à certaines fonctionnalités ou pages est limité aux sous-ensembles d’utilisateurs en fonction du rôle auquel ils appartiennent.

Ce type d’autorisation est implémenté à l’aide de RBAC. Avec RBAC, un administrateur accorde des autorisations aux rôles, et non aux utilisateurs ou groupes individuels. L’administrateur peut ensuite attribuer des rôles à différents utilisateurs et groupes pour contrôler qui a 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 Administration uniquement et aux pages Utilisateurs réguliers.
  • RegularUser: autorisé à accéder à la page Utilisateurs réguliers .

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’appartenance au rôle.

Vous pouvez affecter des utilisateurs et des groupes à des rôles via le Portail Azure ou par programmation à l’aide de Microsoft Graph et de Microsoft Azure AD PowerShell. Cet article décrit les deux techniques.

Remarque

Les revendications de rôle ne sont pas présentes pour les utilisateurs invités d’un locataire si le https://login.microsoftonline.com/common/ point de terminaison est utilisé comme autorité pour connecter des utilisateurs. Vous devez connecter un utilisateur à un point de terminaison locataire tel que https://login.microsoftonline.com/tenantid.

Prérequis

Recommandations

  • Certaines familiarités avec java / Jakarta Servlets.
  • Vous connaissez bien le terminal Linux/OSX ou Windows PowerShell.
  • 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 à jour avec les derniers développements.

Configurer l’exemple

Les sections suivantes vous montrent comment configurer l’exemple d’application.

Cloner ou télécharger l’exemple de référentiel

Pour cloner l’exemple, ouvrez une fenêtre Bash et utilisez la commande suivante :

git clone https://github.com/Azure-Samples/ms-identity-java-servlet-webapp-authentication.git
cd 3-Authorization-II/roles

Vous pouvez également accéder au référentiel ms-identity-java-servlet-webapp-authentication , puis le télécharger en tant que fichier .zip et l’extraire sur votre disque dur.

Important

Pour éviter les limitations de longueur du chemin de fichier sur Windows, clonez ou extrayez le référentiel dans un répertoire près de la racine de votre disque dur.

Inscrire l’exemple d’application auprès de votre locataire Microsoft Entra ID

Il existe un projet dans cet exemple. Pour inscrire l’application sur le Portail Azure, vous pouvez suivre les étapes de configuration manuelles ou utiliser un script PowerShell. Le script effectue les tâches suivantes :

  • Crée les applications Microsoft Entra ID et les objets associés, tels que les mots de passe, les autorisations et les dépendances.
  • Modifie les fichiers de configuration du projet.
  • Par défaut, configure une application qui fonctionne avec des comptes dans votre annuaire organisationnel uniquement.

Pour exécuter le script PowerShell, procédez comme suit :

  1. Sur Windows, ouvrez PowerShell et accédez à la racine du répertoire cloné.

  2. Utilisez la commande suivante pour définir la stratégie d’exécution pour PowerShell :

    Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process -Force

  3. Utilisez les commandes suivantes pour exécuter le script de configuration :

    cd .\AppCreationScripts\
.\Configure.ps1

    Remarque

    D’autres méthodes d’exécution des scripts sont décrites dans les scripts de création d’application. Les scripts fournissent également un guide pour l’inscription, la configuration et la suppression automatisées des applications, ce qui peut vous aider dans vos scénarios CI/CD.

Configurer l’application (java-servlet-webapp-roles) pour utiliser l’inscription de votre application

Pour configurer l’application, procédez comme suit :

Remarque

Dans les étapes suivantes, ClientID il s’agit de la même chose que Application ID ou AppId.

  1. Ouvrez le projet dans votre IDE.

  2. Ouvrez le fichier authentication.properties .

  3. Recherchez la chaîne {enter-your-tenant-id-here}. Remplacez la valeur existante par votre ID de locataire Microsoft Entra ID.

  4. Recherchez la chaîne {enter-your-client-id-here} et remplacez la valeur existante par l’ID d’application ou clientId l’application java-servlet-webapp-call-graph copiée à partir du Portail Azure.

  5. Recherchez la chaîne {enter-your-client-secret-here} et remplacez la valeur existante par la valeur que vous avez enregistrée lors de la création de l’applicationjava-servlet-webapp-roles, dans le Portail Azure.

  6. Recherchez la app.roles propriété et vérifiez que la valeur est définie app.roles=admin PrivilegedAdmin, user RegularUsersur , 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 de 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

Ces instructions supposent que vous avez installé WebSphere et configuré un serveur. Vous pouvez utiliser les instructions du cluster Deploy WebSphere Application Server (traditionnel) sur Azure Machines Virtuelles pour une configuration de serveur de base.

Avant de pouvoir déployer sur WebSphere, procédez comme suit pour apporter des modifications de configuration dans l’exemple lui-même, puis générer ou reconstruire le package :

  1. Accédez au fichier authentication.properties de votre application et modifiez la valeur de l’URL de votre serveur et du numéro de app.homePage port que vous envisagez d’utiliser, comme illustré dans l’exemple suivant :

    # 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://<server-url>:<port-number>/msal4j-servlet-auth/

  2. Après avoir enregistré ce fichier, utilisez la commande suivante pour reconstruire votre application :

    mvn clean package

  3. Une fois le code terminé, copiez le fichier .war sur le système de fichiers de votre serveur cible.

Vous devez également apporter la même modification dans l’inscription d’application Azure, où vous l’avez définie dans le Portail Azure comme valeur d’URI de redirection sous l’onglet Authentification.

  1. Accédez à la page Inscriptions d’applications de la plateforme d’identités Microsoft pour les développeurs.

  2. Utilisez la zone de recherche pour rechercher l’inscription de votre application , par exemple java-servlet-webapp-authentication.

  3. Ouvrez votre inscription d’application en sélectionnant son nom.

  4. Sélectionnez Authentification dans le menu déroulant.

  5. Dans la section URI de redirection web - , sélectionnez Ajouter un URI.

  6. Renseignez l’URI de votre application, en ajoutant /auth/redirect , par exemple https://<server-url>:<port-number>/auth/redirect.

  7. Sélectionnez Enregistrer.

Procédez comme suit pour déployer l’exemple à l’aide de la console solutions intégrées de WebSphere :

  1. Sous l’onglet Applications , sélectionnez Nouvelle application, puis Nouvelle application d’entreprise.

  2. Choisissez le fichier .war que vous avez créé, puis sélectionnez Suivant jusqu’à atteindre les racines du contexte mapper pour l’étape d’installation des modules web. Les autres paramètres par défaut doivent être corrects.

  3. Pour la racine de contexte, définissez-la sur la même valeur qu’après le numéro de port dans l’URI de redirection que vous avez défini dans l’exemple de configuration/inscription d’application Azure. Autrement dit, si l’URI de redirection est http://<server-url>:9080/msal4j-servlet-auth/, la racine de contexte doit être msal4j-servlet-auth.

  4. Sélectionnez Terminer.

  5. Une fois l’application installée, accédez à la section Applications d’entreprise WebSphere de l’onglet Applications .

  6. Sélectionnez le fichier .war que vous avez installé dans la liste des applications, puis sélectionnez Démarrer pour déployer.

  7. Une fois le déploiement terminé, accédez à http://<server-url>:9080/{whatever you set as the context root} l’application et vous devriez être en mesure de voir l’application.

Explorer l’exemple

Pour explorer l’exemple, procédez comme suit :

  1. Notez que l’état de connexion ou de déconnexion s’affiche au centre de l’écran.
  2. Sélectionnez le bouton contextuel dans le coin. Ce bouton lit la connexion lorsque vous exécutez l’application pour la première fois.
  3. Dans la page suivante, suivez les instructions et connectez-vous avec un compte dans le locataire Microsoft Entra ID.
  4. Sur l’écran de consentement, notez les étendues demandées.
  5. Notez que le bouton contextuel indique maintenant se déconnecter et affiche votre nom d’utilisateur.
  6. Sélectionnez Détails du jeton d’ID pour afficher certaines revendications décodées du jeton d’ID.
  7. Sélectionnez Administration s uniquement pour afficher la /admin_only page. Seuls les utilisateurs disposant d’un rôle PrivilegedAdmin d’application peuvent afficher cette page. Sinon, un message d’échec d’autorisation s’affiche.
  8. Sélectionnez Utilisateurs réguliers pour afficher la /regular_user page. Seuls les utilisateurs disposant d’un rôle RegularUser d’application ou PrivilegedAdmin peuvent afficher cette page. Sinon, un message d’échec d’autorisation s’affiche.
  9. Utilisez le bouton dans le coin pour vous déconnecter.

À propos du code

Cet exemple utilise MSAL pour Java (MSAL4J) pour connecter un utilisateur et obtenir un jeton d’ID qui peut contenir la revendication des rôles. En fonction de la revendication de rôles présente, l’utilisateur connecté ne peut accéder à aucun, un ou les deux des pages protégées et Admins OnlyRegular Users.

Si vous souhaitez répliquer le comportement de cet exemple, vous pouvez copier le fichier pom.xml et le contenu des dossiers d’assistanceet d’authentification dans le dossier src/main/java/com/microsoft/azuresamples/msal4j. Vous avez également besoin du fichier authentication.properties . Ces classes et 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 pour traiter l’objectif de cet exemple.

Contenu

Le tableau suivant montre le contenu de l’exemple de dossier de projet :

Fichier/Dossier Description
AppCreationScripts/ Scripts pour configurer automatiquement les inscriptions d’applications Microsoft Entra ID.
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 .java classes se terminant 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 l’ID et du programme Microsoft Entra.
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 illustré dans l’exemple suivant :

{
  ...
  "roles": [
    "Role1",
    "Role2",]
  ...
}

ConfidentialClientApplication

Une ConfidentialClientApplication instance est créée dans le fichier AuthHelper.java , comme illustré dans l’exemple suivant. Cet objet permet d’élaborer l’URL d’autorisation Microsoft Entra et d’échanger le jeton d’authentification pour 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, qui est une exigence pour les applications clientes confidentielles.
  • Autorité d’IDENTIFICATION Microsoft Entra, qui inclut votre ID de locataire Microsoft Entra.

Dans cet exemple, ces valeurs sont lues à partir du fichier authentication.properties à l’aide d’un lecteur de propriétés dans le fichier Config.java.

Procédure pas-à-pas

Les étapes suivantes fournissent une procédure pas à pas des fonctionnalités de l’application :

  1. La première étape du processus de connexion consiste à envoyer une demande au /authorize point de terminaison sur votre locataire Microsoft Entra ID. L’instance MSAL4J ConfidentialClientApplication est utilisée pour construire une URL de demande d’autorisation. L’application redirige le navigateur vers cette URL, qui est l’emplacement 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, ainsi que 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 dans 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 de 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, etc.

  2. 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 demande valide adressée à ce point de terminaison contient un code d’autorisation.

  3. L’instance ConfidentialClientApplication échange ensuite ce code d’autorisation pour 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 pour un ID et/ou un jeton d’accès.
    • authCode: code d’autorisation reçu au 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 passées à nouveau.

  4. Si acquireToken réussit, les revendications du jeton sont extraites. Si la nonce case activée passe, les résultats sont placés dans context - une instance de IdentityContextData - et enregistrées dans la session. L’application peut ensuite instancier la IdentityContextData session à partir d’une instance de chaque fois qu’elle a besoin d’y IdentityContextAdapterServlet accéder, comme indiqué 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 plus d’informations 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 app.protect.authenticated propriété 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 les app.protect.roles ensembles de règles sont également hors limites pour les utilisateurs authentifiés non authentifiés, comme illustré dans l’exemple suivant. Toutefois, ces itinéraires contiennent également une liste séparée par l’espace des appartenances aux rôles d’application : seuls les utilisateurs ayant au moins un des rôles correspondants peuvent accéder à ces itinéraires après l’authentification.

# 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.

En fonction des étendues demandées, l’ID Microsoft Entra présente un dialogue de consentement à l’utilisateur lors de la connexion. Si l’utilisateur consent à une ou plusieurs étendues et obtient un jeton, les étendues consentées sont encodées dans le résultat access_token.

Pour connaître les étendues demandées par l’application, consultez authentication.properties. Ces trois étendues sont demandées par MSAL et fournies par l’ID Microsoft Entra par défaut.

Plus d’informations

Étape suivante

Déployer des applications WebSphere Java sur WebSphere traditionnel sur Azure Machines Virtuelles