Tutoriel : Configurer l’identité Ping avec Azure Active Directory B2C pour un accès hybride sécurisé

Dans ce tutoriel, découvrez comment étendre les fonctionnalités d’Azure Active Directory B2C (Azure AD B2C) avec PingAccess et PingFederate. PingAccess fournit l’accès aux applications et aux API, ainsi qu’à un moteur de stratégie pour l’accès utilisateur autorisé. PingFederate est un serveur de fédération d’entreprise pour l’authentification utilisateur et l’authentification unique, une autorité qui permet aux clients, aux employés et aux partenaires d’accéder aux applications à partir d’appareils. Utilisez-les ensemble pour activer l’accès hybride sécurisé (SHA).

De nombreux sites de commerce électronique et applications web exposés à Internet sont déployés derrière des systèmes proxy ou un système de proxy inverse. Ces systèmes proxy pré-authentifient, appliquent la stratégie et routent le trafic. Les scénarios classiques incluent la protection des applications web contre le trafic web entrant et la fourniture d’une gestion de session uniforme sur les déploiements de serveurs distribués.

En règle générale, les configurations incluent une couche de traduction d’authentification qui externalise l’authentification à partir de l’application web. Les proxys inverses fournissent le contexte utilisateur authentifié aux applications web, comme une valeur d’en-tête sous une forme claire ou condensée. Les applications n’utilisent pas de jetons standard du secteur, tels que SECURITY Assertion Markup Language (SAML), OAuth ou OpenID Connect (OIDC). Au lieu de cela, le proxy fournit un contexte d’authentification et gère la session avec l’agent de l’utilisateur final, tel que le navigateur ou l’application native. En tant que service exécuté comme man-in-the-middle, les proxys fournissent un contrôle de session significatif. Le service proxy est efficace et évolutif, et non un goulot d’étranglement pour les applications derrière le service proxy. Le diagramme est une implémentation de proxy inverse et un flux de communications.

Modernisation

Si vous souhaitez moderniser une plateforme d’identités dans ces configurations, il peut y avoir des préoccupations des clients :

• Dissocier l’effort de modernisation des applications de la modernisation d’une plateforme d’identité
• Environnements avec une authentification moderne et une authentification héritée, qui utilisent le fournisseur de service d’identité modernisé
  • Assurer la cohérence de l’expérience utilisateur final
  • Fournir une expérience d’authentification unique entre les applications

En réponse à ces problèmes, l’approche de ce didacticiel est une intégration Azure AD B2C, PingAccess et PingFederate .

Environnement partagé

Une solution techniquement viable et rentable consiste à configurer le système de proxy inverse pour utiliser le système d’identité modernisé, déléguer l’authentification.
Les proxys prennent en charge les protocoles d’authentification modernes et utilisent l’authentification basée sur la redirection (passive) qui envoie des utilisateurs au nouveau fournisseur d’identité (IdP).

Azure AD B2C en tant que fournisseur d’identité

Dans Azure AD B2C, vous définissez des stratégies qui pilotent les expériences utilisateur et les comportements, également appelés parcours utilisateur. Chacune de ces stratégies expose un point de terminaison de protocole en mesure d’effectuer l’authentification en tant qu’IdP. Côté application, il n’existe aucune gestion spéciale requise pour certaines stratégies. Une application fait une demande d’authentification standard au point de terminaison d’authentification spécifique au protocole exposé par une stratégie.
Vous pouvez configurer Azure AD B2C pour partager le même émetteur entre des stratégies ou un émetteur unique pour chaque stratégie. Chaque application peut pointer vers des stratégies en effectuant une demande d’authentification native par protocole, qui pilote les comportements utilisateur tels que la connexion, l’inscription et les modifications de profil. Le diagramme montre les flux de travail d’application OIDC et SAML.

Le scénario peut être difficile pour les applications anciennes de rediriger l'utilisateur avec précision. La demande d’accès aux applications peut ne pas inclure le contexte d’expérience utilisateur. Dans la plupart des cas, la couche proxy ou un agent intégré sur l’application web intercepte la demande d’accès.

Proxy inverse PingAccess

Vous pouvez déployer PingAccess en tant que proxy inverse. PingAccess intercepte une requête directe en tant qu'intermédiaire, ou comme une redirection d’un agent s’exécutant sur le serveur d'application web.

Configurez PingAccess avec OIDC, OAuth2 ou SAML pour l’authentification auprès d’un fournisseur d’authentification en amont. Vous pouvez configurer un IdP en amont à cet effet sur le serveur PingAccess. Consultez le schéma suivant.

Dans un déploiement typique d’Azure AD B2C avec des stratégies exposant des IdP, il y a un souci. PingAccess est configuré avec un idP en amont.

Proxy de fédération PingFederate

Vous pouvez configurer PingFederate en tant que fournisseur d’authentification ou en tant que proxy pour des fournisseurs d’identité en amont. Consultez le schéma suivant.

Utilisez cette fonction pour basculer de manière contextuelle, dynamique ou déclarative une requête entrante vers une stratégie Azure AD B2C. Consultez le diagramme suivant du flux de séquence de protocole.

Conditions préalables

Avant de commencer, vérifiez que vous disposez des éléments suivants :

• Un abonnement Azure
  • Si vous n’en avez pas, obtenez un compte gratuit Azure
• Un client Azure AD B2C lié à votre abonnement Azure
• PingAccess et PingFederate déployés dans des conteneurs Docker ou sur des machines virtuelles Azure

Connectivité et communication

Confirmez la connectivité et la communication suivantes.

• Serveur PingAccess – Communique avec le serveur PingFederate, le navigateur client, OIDC, OAuth well-known et découverte des clés publiée par le service Azure AD B2C et le serveur PingFederate
• Serveur PingFederate – Communique avec le serveur PingAccess, le navigateur client, OIDC, OAuth well-known et découverte des clés publiée par le service Azure AD B2C
• Application AuthN héritée ou basée sur un en-tête : communique avec et depuis le serveur PingAccess
• Application par partie de confiance SAML – Atteint le trafic du navigateur à partir du client. Accède aux métadonnées de fédération SAML publiées par le service Azure AD B2C.
• Application moderne – Reçoit le trafic du navigateur provenant du client. Accède à OIDC, OAuth well-known et découverte des clés publiée par le service Azure AD B2C.
• API REST : atteint le trafic à partir d’un client web ou natif. Accède à OIDC, OAuth well-known et découverte des clés publiée par le service Azure AD B2C

Configurer Azure AD B2C

Vous pouvez utiliser des flux utilisateur de base ou des stratégies IEF (Identity Enterprise Framework) avancées. PingAccess génère le point de terminaison des métadonnées en se basant sur la valeur de l’émetteur et en utilisant le protocole WebFinger pour la convention de découverte. Pour suivre cette convention, mettez à jour l’émetteur Azure AD B2C à l’aide des propriétés de stratégie de flux utilisateur.

Dans les stratégies avancées, la configuration inclut l’élément de métadonnées IssuerClaimPattern sur la valeur AuthorityWithTfp dans le profil technique de l’émetteur JWT.

Configurer PingAccess et PingFederate

Utilisez les instructions des sections suivantes pour configurer PingAccess et PingFederate. Consultez le diagramme suivant du flux d’utilisateur d’intégration global.

Configurer PingFederate en tant que fournisseur de jetons

Pour configurer PingFederate en tant que fournisseur de jetons pour PingAccess, vérifiez la connectivité de PingFederate à PingAccess. Confirmez la connectivité de PingAccess à PingFederate.

Configurer une application PingAccess pour l’authentification basée sur l’en-tête

Utilisez les instructions suivantes pour créer une application PingAccess pour l’application web cible, pour l’authentification basée sur l’en-tête.

Créer un hôte virtuel

Pour créer un hôte virtuel :

1. Accédez aux paramètres>pour accéder aux>hôtes virtuels.
2. Sélectionnez Ajouter un hôte virtuel.
3. Pour l’hôte, entrez la partie FQDN de l’URL de l’application.
4. Pour port, entrez 443.
5. Cliquez sur Enregistrer.

Créer une session web

Pour créer une session web :

1. Accédez à Paramètres>Accès>Sessions web.
2. Sélectionnez Ajouter une session web.
3. Entrez un nom pour la session web.
4. Sélectionnez le type de cookie : JWT signé ou JWT chiffré.
5. Entrez une valeur unique pour Audience.
6. Pour l’ID client, entrez l’ID d’application Microsoft Entra.
7. Pour la clé secrète client, entrez la clé que vous avez générée pour l’application dans l’ID Microsoft Entra.
8. (Facultatif) Créez et utilisez des revendications personnalisées avec l’API Microsoft Graph : Sélectionnez Avancé. Désélectionnez le profil de requête et actualisez les attributs utilisateur. En savoir plus sur les revendications personnalisées : Authentification unique basée sur l’en-tête pour les applications locales avec le proxy d’application Microsoft Entra.
9. Cliquez sur Enregistrer

Créer un mappage d’identité

Pour créer un mappage d’identité :

1. Accédez à Paramètres>Accès>Mappages d’identité.
2. Sélectionnez Ajouter un mappage d’identité.
3. Spécifiez un *Name.
4. Sélectionnez le mappage d’identité Mappage d’identité selon le type d’en-tête.
5. Dans la table Attribute-Mapping , spécifiez les mappages requis. Par exemple,

6. Cliquez sur Enregistrer

Créer un site

Pour créer un site :

1. Accédez auxsites>.
2. Sélectionnez Ajouter un site.
3. Entrez le nom du site.
4. Entrez la cible du site. La cible est la paire hostname :port pour le serveur hébergeant l’application. N’entrez pas le chemin d’accès de l’application dans ce champ. Par exemple, une application à l’adresse https://mysite:9999/AppName a une valeur cible de mysite :9999.
5. Indiquez si la cible attend des connexions sécurisées.
6. Si la cible s’attend à des connexions sécurisées, définissez le groupe de certificats approuvés sur Approbation n’importe quelle.
7. Cliquez sur Enregistrer.

Créer une application

Pour créer une application dans PingAccess pour chaque application dans Azure que vous souhaitez protéger.

1. Accéder auxapplications>

2. Sélectionnez Ajouter une application.

3. Spécifier un nom pour l’application

4. Si vous le souhaitez, entrez une description pour l’application

5. Spécifiez la racine de contexte de l’application. Par exemple, une application à https://mysite:9999/AppName aura une racine de contexte de /AppName. La racine de contexte doit commencer par une barre oblique (/), ne doit pas se terminer par une barre oblique (/) et peut être plusieurs couches profondes, par exemple /Apps/MyApp.

6. Sélectionnez l’hôte virtuel que vous avez créé

   Remarque

   La combinaison de l’hôte virtuel et de la racine de contexte doit être unique dans PingAccess.

7. Sélectionnez la session web que vous avez créée

8. Sélectionnez le site que vous avez créé qui contient l’application

9. Sélectionnez le mappage d’identité que vous avez créé

10. Sélectionnez Activé pour activer le site lorsque vous enregistrez

11. Cliquez sur Enregistrer

Configurer la stratégie d’authentification PingFederate

Configurez la stratégie d’authentification de PingFederate pour fédérer sur plusieurs fournisseurs IdP fournis par les locataires Azure AD B2C.

1. Créez un contrat pour relier les attributs entre les fournisseurs IdP et SP. Vous ne devez avoir besoin que d'un seul contrat, sauf si le SP nécessite un ensemble différent d'attributs de chaque IdP. Pour plus d’informations, consultez le hub de fédération et les contrats de stratégie d’authentification dans la documentation Ping Identity.

2. Pour chaque IdP, créez une connexion entre l'IdP et PingFederate, le hub de fédération agissant en tant que SP.

3. Dans la fenêtre Mappage de session cible, ajoutez les contrats de stratégie d’authentification applicables à la connexion IdP.

4. Dans la fenêtre Sélecteurs , configurez un sélecteur d’authentification. Par exemple, reportez-vous à une instance du premier adaptateur de l’identificateur pour mapper chaque fournisseur IdP à la connexion IdP correspondante dans une stratégie d’authentification.

5. Créez une connexion SP entre PingFederate, le hub de fédération en tant que fournisseur IdP et le fournisseur SP.

6. Ajoutez le contrat de stratégie d'authentification correspondant à la connexion SP dans la fenêtre Mappage de source d'authentification.

7. Travaillez avec chaque fournisseur IdP pour vous connecter à PingFederate, avec le hub de fédération en tant que SP.

8. Travaillez avec le fournisseur SP pour vous connecter à PingFederate, avec le hub de fédération en tant que IdP.

Étapes suivantes

Pour plus d’informations, consultez les articles suivants

• Stratégies personnalisées dans Azure AD B2C

• Prise en main des stratégies personnalisées dans Azure AD B2C