Activer la connexion pour les applications Java WebSphere à l’aide de MSAL4J avec Azure Active Directory B2C

  • Article

Cet article illustre une application Servlet Java qui authentifie les utilisateurs auprès d’Azure Active Directory B2C (Azure AD B2C) à l’aide de la bibliothèque d’authentification Microsoft pour Java (MSAL4J).

Le diagramme suivant illustre la topologie de l’application :

Diagramme montrant la topologie de l’application.

L’application utilise MSAL4J pour connecter des utilisateurs et obtenir un jeton d’ID auprès d’Azure AD B2C. Le jeton d’ID prouve que l’utilisateur est authentifié sur un locataire Azure AD B2C.

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 1-Authentication/sign-in-b2c

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 Azure AD B2C

L’exemple est fourni avec une application préinscriée à des fins de test. Si vous souhaitez utiliser votre propre locataire et application Azure AD B2C, suivez les étapes décrites dans les sections suivantes pour inscrire et configurer l’application dans le Portail Azure. Sinon, passez aux étapes de l’exemple d’exécution.

Choisissez le locataire Azure AD B2C dans lequel vous souhaitez créer vos applications

Pour choisir votre locataire, procédez comme suit :

  1. Connectez-vous au portail Azure.

  2. Si votre compte est présent dans plusieurs locataires Azure AD B2C, sélectionnez votre profil dans le coin de l’Portail Azure, puis sélectionnez Changer d’annuaire pour modifier votre session en locataire Azure AD B2C souhaité.

Créer des flux utilisateur et des stratégies personnalisées

Pour créer des flux utilisateur courants tels que l’inscription, la connexion, la modification de profil et la réinitialisation de mot de passe, consultez tutoriel : Créer des flux utilisateur dans Azure Active Directory B2C.

Vous devez également envisager de créer des stratégies personnalisées dans Azure Active Directory B2C , mais cela dépasse l’étendue de ce didacticiel.

Ajouter des fournisseurs d’identité externes

Consultez le tutoriel : Ajouter des fournisseurs d’identité à vos applications dans Azure Active Directory B2C.

Inscrire l’application (ms-identity-b2c-java-servlet-webapp-authentication)

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

  1. Accédez au Portail Azure et sélectionnez Azure AD B2C.

  2. Sélectionnez Inscriptions d’applications dans le volet de navigation, puis Nouvelle inscription.

  3. Dans la page Inscrire une application qui s’affiche, entrez les informations d’inscription d’application suivantes :

    • Dans la section Nom , entrez un nom d’application explicite pour l’affichage aux utilisateurs de l’application, par exemple ms-identity-b2c-java-servlet-webapp-authentication.
    • Sous Types de comptes pris en charge, sélectionnez Comptes dans un annuaire organisationnel et comptes personnels Microsoft (par exemple, Skype, Xbox, Outlook.com).
    • Dans la section URI de redirection (facultatif), sélectionnez Web dans la zone de liste déroulante et entrez l’URI de redirection suivant : http://localhost:8080/ms-identity-b2c-java-servlet-webapp-authentication/auth_redirect.

  4. Sélectionnez Inscrire pour créer l’application.

  5. Dans la page d’inscription de l’application, recherchez et copiez la valeur d’ID d’application (client) à utiliser ultérieurement. Vous utilisez cette valeur dans le fichier de configuration ou les fichiers de votre application.

  6. Cliquez sur Enregistrer pour enregistrer vos modifications.

  7. Dans la page d’inscription de l’application, sélectionnez Certificats et secrets dans le volet de navigation pour ouvrir la page dans laquelle vous pouvez générer des secrets et charger des certificats.

  8. Dans la section Secrets client, sélectionnez Nouveau secret client.

  9. Tapez une description ( par exemple, secret d’application).

  10. Sélectionnez l’une des durées disponibles : En 1 an, En 2 ans ou Jamais expire.

  11. Sélectionnez Ajouter. La valeur générée s’affiche.

  12. Copiez et enregistrez la valeur générée à utiliser dans les étapes ultérieures. Vous avez besoin de cette valeur pour les fichiers de configuration de votre code. Cette valeur n’est plus affichée et vous ne pouvez pas la récupérer par d’autres moyens. Veillez donc à l’enregistrer à partir de l’Portail Azure avant d’accéder à n’importe quel autre écran ou volet.

Configurer l’application (ms-identity-b2c-java-servlet-webapp-authentication) pour utiliser votre inscription d’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 ./src/main/resources/authentication.properties .

  3. Recherchez la aad.clientId propriété et remplacez la valeur existante par l’ID d’application ou clientId l’application ms-identity-b2c-java-servlet-webapp-authentication à partir du Portail Azure.

  4. Recherchez la aad.secret propriété et remplacez la valeur existante par la valeur que vous avez enregistrée lors de la création de l’application ms-identity-b2c-java-servlet-webapp-authentication à partir du Portail Azure.

  5. Recherchez la aad.scopes propriété et remplacez l’ID client d’application existant par la valeur que vous avez placée à aad.clientId l’étape 1 de cette section.

  6. Recherchez la aad.authority propriété et remplacez la première instance par fabrikamb2c le nom du locataire Azure AD B2C dans lequel vous avez créé l’application ms-identity-b2c-java-servlet-webapp-authentication dans le Portail Azure.

  7. Recherchez la aad.authority propriété et remplacez la deuxième instance par fabrikamb2c le nom du locataire Azure AD B2C dans lequel vous avez créé l’application ms-identity-b2c-java-servlet-webapp-authentication dans le Portail Azure.

  8. Recherchez la propriété et remplacez-la aad.signInPolicy par le nom de la stratégie de flux utilisateur d’inscription/connexion que vous avez créée dans le locataire Azure AD B2C dans lequel vous avez créé l’application ms-identity-b2c-java-servlet-webapp-authentication dans le Portail Azure.

  9. Recherchez la propriété et remplacez-la aad.passwordResetPolicy par le nom de la stratégie de réinitialisation de flux utilisateur que vous avez créée dans le locataire Azure AD B2C dans lequel vous avez créé l’application ms-identity-b2c-java-servlet-webapp-authentication dans le Portail Azure.

  10. Recherchez la propriété et remplacez-la aad.editProfilePolicy par le nom de la stratégie de flux utilisateur de profil de modification que vous avez créée dans le locataire Azure AD B2C dans lequel vous avez créé l’application ms-identity-b2c-java-servlet-webapp-authentication dans le Portail Azure.

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 de votre fournisseur d’identité choisi.
  4. Notez que le bouton contextuel indique maintenant se déconnecter et affiche votre nom d’utilisateur.
  5. Sélectionnez Détails du jeton d’ID pour afficher certaines revendications décodées du jeton d’ID.
  6. Vous avez également la possibilité de modifier votre profil. Sélectionnez le lien pour modifier les détails tels que votre nom d’affichage, votre lieu de résidence et votre profession.
  7. Utilisez le bouton dans le coin pour vous déconnecter.
  8. Après la déconnexion, accédez à l’URL suivante pour la page de détails du jeton : http://localhost:8080/ms-identity-b2c-java-servlet-webapp-authentication/auth_token_details. Ici, vous pouvez observer comment l’application affiche une 401: unauthorized erreur au lieu des revendications de jeton d’ID.

À propos du code

Cet exemple montre comment utiliser MSAL4J pour connecter des utilisateurs à votre locataire Azure AD B2C.

Contenu

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

Fichier/Dossier Description
AuthHelper.java Fonctions d’assistance pour l’authentification.
Config.java S’exécute au démarrage et configure le lecteur de propriétés et l’enregistreur d’événements.
authentication.properties Configuration de l’ID et du programme Microsoft Entra.
AuthenticationFilter.java Redirige les demandes non authentifiées vers des ressources protégées vers une page 401.
MsalAuthSession Instancié avec un HttpSession. Stocke tous les attributs de session associés MSAL dans l’attribut de session.
____Servlet.java Tous les points de terminaison disponibles sont définis dans .java classes se terminant par ____Servlet.java.
CHANGELOG.md Liste des modifications apportées à l’exemple.
CONTRIBUTING.md Instructions pour contribuer à l’exemple.
LICENCE Licence de l’exemple.

ConfidentialClientApplication

Une ConfidentialClientApplication instance est créée dans le fichier AuthHelper.java , comme illustré dans l’exemple suivant. Cet objet permet de créer l’URL d’autorisation Azure AD B2C et d’échanger le jeton d’authentification pour un jeton d’accès.

IClientSecret secret = ClientCredentialFactory.createFromSecret(SECRET);
confClientInstance = ConfidentialClientApplication
                     .builder(CLIENT_ID, secret)
                     .b2cAuthority(AUTHORITY + policy)
                     .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.
  • L’autorité Azure AD B2C concaténée avec la configuration appropriée UserFlowPolicy pour l’inscription, la connexion, la modification de profil ou la réinitialisation de mot de passe.

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 de votre locataire Azure Active Directory B2C. L’instance MSAL4J ConfidentialClientApplication est utilisée pour construire une URL de demande d’autorisation et l’application redirige le navigateur vers cette URL, comme illustré dans l’exemple suivant :

    final ConfidentialClientApplication client = getConfidentialClientInstance(policy);
final AuthorizationRequestUrlParameters parameters = AuthorizationRequestUrlParameters
    .builder(REDIRECT_URI, Collections.singleton(SCOPES)).responseMode(ResponseMode.QUERY)
    .prompt(Prompt.SELECT_ACCOUNT).state(state).nonce(nonce).build();

final String redirectUrl = client.getAuthorizationRequestUrl(parameters).toString();
Config.logger.log(Level.INFO, "Redirecting user to {0}", redirectUrl);
resp.setStatus(302);
resp.sendRedirect(redirectUrl);

    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ù Azure AD B2C redirige le navigateur, ainsi que le code d’authentification, après avoir collecté les informations d’identification de l’utilisateur.

    • SCOPES: les étendues sont des autorisations demandées par l’application.

      Normalement, les trois étendues openid profile offline_access suffiraient pour recevoir une réponse de jeton d’ID. Toutefois, MSAL4J nécessite que toutes les réponses d’Azure AD B2C contiennent également un jeton d’accès.

      Pour qu’Azure AD B2C distribue un jeton d’accès ainsi qu’un jeton d’ID, la demande doit inclure une étendue de ressource supplémentaire. Étant donné que cette application ne nécessite pas réellement d’étendue de ressource externe, elle ajoute son propre ID client en tant que quatrième étendue afin de recevoir un jeton d’accès.

      Vous trouverez une liste complète des étendues demandées par l’application dans le fichier authentication.properties .

    • ResponseMode.QUERY: Azure AD B2C peut retourner la réponse sous forme d’analyseurs de formulaire dans une requête HTTP POST ou en tant qu’analyseurs de chaîne de requête dans une requête HTTP GET.

    • Prompt.SELECT_ACCOUNT: Azure AD B2C doit demander à l’utilisateur de sélectionner le compte sur lequel il a l’intention de s’authentifier.

    • state: variable unique définie par l’application dans la session sur chaque demande de jeton et détruite après avoir reçu le rappel de redirection Azure AD B2C correspondant. La variable d’état garantit que les demandes Azure AD B2C adressées aux /auth_redirect endpoint demandes d’autorisation Azure AD B2C proviennent de cette application et de cette session, ce qui empêche les attaques CSRF. Cette opération est effectuée dans le fichier AADRedirectServlet.java .

    • nonce: variable unique définie par l’application dans la session sur chaque demande de jeton et détruite après avoir reçu le jeton correspondant. Ce nonce est transcrit aux jetons résultants distribués par Azure AD B2C, ce qui garantit qu’il n’y a pas d’attaque par relecture de jetons.

  2. L’utilisateur reçoit une invite de connexion par Azure Active Directory B2C. 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 d’Azure Active Directory B2C, comme indiqué dans l’exemple suivant :

    final AuthorizationCodeParameters authParams = AuthorizationCodeParameters
                    .builder(authCode, new URI(REDIRECT_URI))
                    .scopes(Collections.singleton(SCOPES)).build();

final ConfidentialClientApplication client = AuthHelper
        .getConfidentialClientInstance(policy);
final Future<IAuthenticationResult> future = client.acquireToken(authParams);
final IAuthenticationResult result = future.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 elle réussit, les revendications de jeton sont extraites et la revendication de nonce est validée par rapport au nonce stocké dans la session, comme illustré dans l’exemple suivant :

    parseJWTClaimsSetAndStoreResultInSession(msalAuth, result, serializedTokenCache);
validateNonce(msalAuth)
processSuccessfulAuthentication(msalAuth);

  5. Si la nonce est correctement validée, l’état de l’authentification est placé dans une session côté serveur, en tirant parti des méthodes exposées par la MsalAuthSession classe, comme illustré dans l’exemple suivant :

    msalAuth.setAuthenticated(true);
msalAuth.setUsername(msalAuth.getIdTokenClaims().get("name"));

Plus d’informations

Pour plus d’informations sur le fonctionnement des protocoles OAuth 2.0 dans ce scénario et d’autres scénarios, consultez Scénarios d’authentification pour Microsoft Entra ID.

Étape suivante

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