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

Dans ce tutoriel, apprenez à étendre les fonctionnalités d’Azure Active Directory B2C (Azure AD B2C) avec PingAccess et PingFederate. PingAccess fournit un accès aux applications et aux API, ainsi qu’un moteur de stratégie pour les accès utilisateur autorisés. 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 obtenir un accès hybride sécurisé (SHA).

Un grand nombre de sites marchands et d’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 une stratégie et routent le trafic. Scénarios typiques : protection des applications web du trafic web entrant et gestion uniforme des sessions entre des déploiements de serveurs distribués.

Généralement, les configurations comprennent une couche de traduction d’authentification qui externalise l’authentification 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 d’entreprise tels que SAML (Security Assertion Markup Language), OAuth ou OIDC (Open ID Connect). Au lieu de cela, le proxy fournit le contexte d’authentification et gère la session avec l’agent de l’utilisateur final tel qu’un navigateur ou une 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. Il n’est pas un goulot d’étranglement pour les applications derrière le service proxy. Le schéma représente une implémentation de proxy inverse et un flux de communications.

Modernisation

Si vous souhaitez moderniser une plateforme d’identités avec ces configurations, des soucis peuvent apparaître avec les clients :

• Séparer l’effort de modernisation des applications de l’effort de modernisation d’une plateforme d’identités
• 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 de l’utilisateur final
  • Fournir une expérience d’authentification unique pour toutes les applications

En réponse à ces préoccupations, l’approche de ce tutoriel est une intégration Azure AD B2C de PingAccess et de PingFederate.

Environnement partagé

Une solution techniquement viable et rentable consiste à configurer le système proxy inverse pour utiliser le système d’identité modernisé en déléguant l’authentification.
Les proxys prennent en charge les protocoles d’authentification modernes et utilisent l’authentification redirigée (passive) qui envoie les 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 déterminent les expériences et les comportements des utilisateurs, é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, aucune gestion spéciale n’est 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 fournisseur parmi les stratégies ou un fournisseur unique pour chaque stratégie. Chaque application peut pointer vers des stratégies en faisant une demande d’authentification de protocole native, qui gère les comportements utilisateur comme les connexions, les inscriptions et les modifications de profil. Le diagramme montre les workflows d’application OIDC et SAML.

Le scénario peut être compliqué pour les applications héritées qui doivent rediriger l’utilisateur avec exactitude. La demande d’accès aux applications risque de ne pas inclure le contexte de l’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 demande directe en tant qu’intercepteur ou redirection à partir d’un agent exécuté sur le serveur d’applications web.

Configurez PingAccess avec OIDC, OAuth2 ou SAML pour l’authentification avec 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 seul 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 faire basculer de manière contextuelle, dynamique ou déclarative une demande entrante vers une stratégie Azure AD B2C. Consultez le schéma suivant du flux de séquence de protocole.

Prérequis

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

• Un abonnement Azure
  • Si vous n’en avez pas déjà un, procurez-vous un compte Azure gratuit.
• Un locataire 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 basée sur un en-tête ou héritée – Communique vers 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 – Atteint le trafic du navigateur à partir 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 natif ou web. 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 d’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 respecter cette convention, effectuez la mise à jour de l’émetteur Azure AD B2C à l’aide des propriétés des stratégies de flux d’utilisateurs.

Dans les stratégies avancées, la configuration comprend l’élément de métadonnées IssuanceClaimPattern avec la valeur AuthorityWithTfp dans le profil technique de l’émetteur de jetons JWT.

Configurer PingAccess et PingFederate

Utilisez les instructions des sections suivantes pour configurer PingAccess et PingFederate. Consultez le schéma 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.

Pour plus d’informations, consultez Configurer PingFederate en tant que fournisseur de jetons pour PingAccess dans la documentation Ping Identity.

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

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

Créer un hôte virtuel

Pour créer un hôte virtuel :

1. Accédez à Paramètres>Accès>Hôtes virtuels.
2. Sélectionnez Ajouter un hôte virtuel.
3. Pour Hôte, entrez la partie FQDN de l’URL de l’application.
4. Pour Port, entrez 443.
5. Sélectionnez 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 Microsoft Entra ID.
8. (Facultatif) Créez et utilisez des revendications personnalisées avec l’API Microsoft Graph : sélectionnez Avancé. Désélectionnez Demander le profil et Actualiser 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. Sélectionnez 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 *Nom.
4. Sélectionnez le mappage d’identité Mappage d’identité selon le type d’en-tête.
5. Dans la table Mappage d’attributs, spécifiez les mappages requis. Par exemple,

6. Sélectionnez Enregistrer.

Créer un site

Pour créer un site :

1. Accédez à Principal>Sites.
2. Sélectionner Ajouter un site.
3. Entrez le Nom du site.
4. Entrer la Cible du site. La cible est la paire nom_d’hôte:port pour le serveur hébergeant l’application. N’entrez pas le chemin de l’application dans ce champ. Par exemple, une application sur https://mysite:9999/AppName a la valeur cible mysite:9999.
5. Indiquez si la cible attend des connexions sécurisées.
6. Si la cible attend des connexions sécurisées, définissez le groupe de certificats approuvés sur Faire confiance à tous.
7. Sélectionnez Enregistrer.

Créer une application

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

1. Accédez à Principal>Applications.

2. Sélectionnez Ajouter une application.

3. Spécifiez un Nom pour l’application.

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

5. Spécifiez la Racine du contexte pour l’application. Par exemple, une application à l’adresse https://mysite:9999/AppName a une racine du contexte /AppName. La racine du contexte doit commencer par une barre oblique (/), ne doit pas se terminer par une barre oblique (/) et peut avoir une profondeur de plus d’une couche par exemple : /Apps/MyApp.

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

   Notes

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

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

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

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

10. Sélectionnez Activé pour activer le site lors de l’enregistrement.

11. Sélectionnez Enregistrer.

Configurer la stratégie d’authentification de 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 devrez avoir besoin d’un seul contrat, sauf si le fournisseur SP requiert un ensemble d’attributs différent pour chaque fournisseur IdP. Pour plus d’informations, consultez Contrats de hub de fédération et de stratégie d’authentification dans la documentation Ping Identity.

2. Pour chaque fournisseur IdP, créez une connexion IdP entre l’IdP et PingFederate, le hub de fédération 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 la 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

• Bien démarrer avec les stratégies personnalisées dans Azure AD B2C