Dépanner des configurations SAML

Lors du dépannage, il est important de comprendre votre configuration.

• Auth0 sert-il de fournisseur de services SAML (SP), de fournisseur d’identité SAML (IdP) ou les deux?

  Le SP redirige les utilisateurs vers une autre destination pour l’authentification. L’IdP authentifie l’utilisateur en lui demandant de se connecter et en validant les informations fournies. Si votre application redirige l’utilisateur vers Auth0 pour l’authentification via SAML, alors Auth0 est l’IdP. Si Auth0 redirige les utilisateurs via une connexion vers un IdP distant via SAML, alors Auth0 est le SP de l’IdP distant. Auth0 peut agir comme fournisseur de services (SP), fournisseur d’identité (IdP), ou les deux.

• Votre flux d’authentification utilise-t-il un modèle initié par le SP, un modèle initié par l’IdP, ou les deux?

  Les flux d’authentification initiés par le SP débutent par un utilisateur qui se rend sur l’application du SP et qui est redirigé vers l’IdP pour se connecter. Un flux initié par l’IdP signifie que l’utilisateur se rend sur l’IdP, se connecte, puis est redirigé vers l’application du SP.

  Dans les configurations d’entreprise, le flux initié par l’IdP est le plus courant.

• Quel attribut de profil utilisateur identifie l’utilisateur au niveau de l’IdP (lors de la connexion) et dans chaque application?

  Si l’attribut de nom diffère entre l’IdP et la(les) application(s), vous allez devoir configurer les mappages appropriés dans Auth0 afin qu’il envoie les bons attributs de profil utilisateur à la(les) application(s).

  • Sur la base de notre expérience, nous pouvons affirmer qu’utiliser l’adresse courriel comme identifiant unique est l’option la plus simple, bien qu’elle pose des problèmes de confidentialité.

  • Les organizations d’entreprise utilisent souvent un identifiant interne de type quelconque avec l’IdP, qui doit être mappé à un autre attribut significatif pour les applications SaaS externalisées

• Vos demandes d’authentification sont-elles signées?

• Vos assertions d’authentification sont-elles cryptées?

Lors du dépannage, nous recommandons de commencer par rassembler des informations qui aident à répondre aux questions suivantes :

1. Combien d’utilisateurs font face à ce problème? Juste un utilisateur? Tous les utilisateurs?

2. S’agit-il d’un problème avec une nouvelle configuration, ou d’une intégration existante qui a cessé de fonctionner?

3. Combien d’applications sont affectées par le problème?

4. Quel est le comportement attendu? Quel comportement observez-vous?

5. À quel niveau l’utilisateur arrive-t-il dans la séquence de connexion?

• Vérifiez le profil de l’utilisateur, le navigateur ou l’appareil pour détecter d’éventuels problèmes.

• Vérifiez si cela se produit dans tous les navigateurs pour les utilisateurs affectés (indiquant un problème de données) ou uniquement dans certains types de navigateurs (indiquant un problème spécifique au navigateur).

• Vérifiez si JavaScript et les témoins sont activés dans le navigateur.

• Vérifiez que la touche de verrouillage des majuscules est désactivée.

• Si l’utilisateur utilise un appareil mobile, vérifiez s’il y a des logiciels susceptibles d’impacter l’authentification et/ou l’autorisation (par exemple, ne pas exécuter certains types de logiciels requis).

• Vérifiez si l’utilisateur peut accéder à certaines des URL clés de l’application, comme l'authentification unique (SSO) de l’URL de l’IdP (indiquant un problème de connectivité réseau).

Voici quelques erreurs courantes que vous pourriez rencontrer lorsque Auth0 agit comme fournisseur de services et les étapes à suivre pour les résoudre.

Ce message indique que l’application n’a pas de connexion active associée :

"error": "invalid_request", "error_description": "the connection was disabled"

1. Naviguez vers Auth0 Dashboard; Authentification; Entreprise, et sélectionnez un type de connexion.

2. Sélectionnez le nom de votre connexion.

3. Sélectionnez les Applications à afficher.

4. Activez au moins une application (si vous ne voyez aucune dans la liste, vous allez devoir créer une application avant de continuer).

Cette erreur se produit généralement parce que l’ URL ACS configurée dans l’IdP a utilisé le domaine par défaut du locataire Auth0, tandis que la transaction d’authentification a été initiée en appelant le point de terminaison /authorize du domaine personnalisé.

"invalid_request": "IdP-Initiated login is not enabled for connection 'CONNECTION_NAME'."

Si vous constatez cette erreur lorsque vous utilisez un flux initié par SP, l’un des éléments suivants est manquant ou vide :

• Paramètre RelayState

• L’attribut InResponseTo dans l’assertion SAML

Si ces éléments sont manquants ou vides, Auth0 traite la connexion comme étant initiée par IdP. Vous pouvez corriger cette erreur en vérifiant la configuration afin de vous assurer que les deux champs sont remplis et retournent de manière adéquate.

Pour résoudre ce problème :

1. Naviguez vers Auth0 Dashboard; Authentification; Entreprise, et sélectionnez un type de connexion.

2. Sélectionnez le nom de votre connexion.

3. Sélectionnez l’aperçu SSO initiée par l’IdP .

4. Localisez le comportement SSO initié par l’IdP, et sélectionnez Accept Requests (Accepter les requêtes) pour activer les connexions initiées par l’IdP.

5. Sélectionnez Default Application (Application par défaut) et le Response Protocol (Protocole de réponse) utilisés par cette application, et (facultativement) spécifiez tout paramètre supplémentaire que vous souhaitez transmettre à l’application.

Cette erreur se produit lorsque l’attribut InResponseTo dans la réponse SAML n’est pas reconnu par le locataire Auth0. Cette erreur pourrait être causée par :

• témoins bloqués

• identifiant non concordant issue de la dernière requête SAML

• utilisation incohérente des domaines

Si votre locataire utilise un domaine personnalisé, vous pourriez avoir une incohérence si le flux de connexion commence sur le domaine personnalisé et se termine sur le domaine canonique. Par exemple, l’utilisateur commence sur le domaine personnalisé :

https://auth.{yourDomain}.com/authorize?client_id=abc123&redirect_uri=https://jwt.io&response_type=code&scope=openid&audience=https://example.com&connection=mysamlconnection

Mais le fournisseur d’identité est configuré pour renvoyer la réponse SAML à l’URL ACS sur le domaine canonique :

https://{yourTenant}.auth0.com/login/callback

Si l’identifiant est renvoyé à un autre domaine dans l’attribut InResponseTo d’une réponse SAML, votre locataire Auth0 n’a pas un enregistrement de cela et renvoie l’erreur ci-dessus.

Pour résoudre ce problème :

Utilisez le même domaine tout au long du flux de connexion. Changez soit le domaine dans la requête initiale /authorize soit l’URL ACS avec votre fournisseur d’identité.

Cette erreur se produit généralement lorsque vous avez activé les flux initiés par l’IdP, mais que vous n’avez pas fourni les informations nécessaires pour exécuter le flux

"invalid_request": "Default App for IdP-Initiated is not configured. Make sure to configure that from connection settings or include client_id in RelayState parameter. » (L’application par défaut pour les flux IdP n’est pas configurée. Assurez-vous de toujours configurer cela à partir des paramètres de connexion ou d’inclure client_id dans le paramètre RelayState

L’ACS doit utiliser le même domaine que la requête d’authentification initiale. Si vous utilisez des domaines personnalisés, elle doit utiliser l’URL de rappel du domaine personnalisé.

Si vous constatez cette erreur lorsque vous utilisez un flux initié par SP, l’un des éléments suivants est manquant ou vide :

• Paramètre RelayState

• L’attribut InResponseTo dans l’assertion SAML

Si ces éléments sont manquants ou vides, Auth0 traite la connexion comme étant initiée par IdP. Vous pouvez corriger cette erreur en vérifiant la configuration afin de vous assurer que les deux champs sont remplis et retournent de manière adéquate.

Pour résoudre ce problème :

1. Naviguez vers Auth0 Dashboard; Authentification; Entreprise, et sélectionnez un type de connexion.

2. Sélectionnez le nom de votre connexion.

3. Sélectionnez l’aperçu SSO initiée par l’IdP .

4. Sélectionnez Default Application (Application par défaut) et le Response Protocol (Protocole de réponse) utilisés par cette application, et (facultativement) spécifiez tout paramètre supplémentaire que vous souhaitez transmettre à l’application.

Cette erreur se produit lorsque le fournisseur d’identité ne renvoie pas le paramètre RelayState avec sa réponse.

Collaborez avec le fournisseur d’identité pour vous assurer qu’il renvoie le paramètre RelayState .

Cette erreur se produit si la valeur de l’élément audience de la réponse SAML du fournisseur d’identité ne correspond pas à la valeur attendue par Auth0. Auth0 attend que la valeur soit l’identifiant d’entité pour la connexion.

Trouvez l’identifiant d’entité de votre connexion :

1. Naviguez vers Auth0 Dashboard; Authentification; Entreprise, et sélectionnez un type de connexion.

2. Sélectionnez le nom de votre connexion.

3. Sélectionnez l’aperçu Setup (Configuration) et localisez la section Common Settings (Paramètres communs); votre Entity identifiant (Identifiant d’entité) constitue le deuxième paramètre fourni.

Assurez-vous que le fournisseur d’identité envoie la valeur audience correcte dans la réponse SAML.

Une erreur courante consiste à spécifier le protocole de réponse incorrect dans l’onglet initié par l’IdP. Le protocole de réponse est celui utilisé entre Auth0 et l’application (et non le fournisseur d’identité distant) Par exemple, si vous définissez cette valeur sur SAML alors que votre application attend Openidentifiant Connect ou WS-Fed cela entraîne des erreurs en raison d’une mauvaise configuration.

1. Naviguez vers Auth0 Dashboard; Authentification; Entreprise, et sélectionnez un type de connexion.

2. Sélectionnez le nom de votre connexion.

3. Sélectionnez l’aperçu IdP-Initiated SSO (SSO initiée par l’IdP) , localisez le Response Protocol (Protocole de réponse), et vérifiez sa valeur.

Lorsque ADFS est configuré en tant que IdP SAML, si l’attribut Name ID (Identifiant de nom) de la partie de confiance relayée par ADFS n’est pas mappé, le flux de déconnexion échoue. Par exemple, avec le paramètre fédéré v2/logout?federated&... l’utilisateur n’est pas redirigé vers le point de terminaison de déconnexion SAML ADFS, mais est redirigé directement vers l’URL de rappel de l’application. En conséquence, l’utilisateur n’est pas déconnecté de l’IdP dans ce cas.

Ajoutez l’attribut Name identifiant en tant que règle sur la partie de confiance relayée par ADFS

Lors du dépannage d’une connexion SAML, il y a quatre étapes principales à vérifier :

• Étape 1 : L’utilisateur est redirigé avec succès vers un IdP et peut se connecter.

• Étape 2 : Après s’être connecté avec l’IdP, l’utilisateur revient à Auth0 avec un événement de connexion réussi enregistré.

• Étape 3 : Après un événement de connexion réussi dans Auth0, le profil utilisateur dans Auth0 est correct.

• Étape 4 : L’utilisateur est redirigé avec succès vers l’application et peut y accéder.

Les sections suivantes décrivent comment vérifier chaque étape et comment identifier s’il existe des problèmes avec une étape donnée.

1. Naviguez vers Auth0 Dashboard > Authentification > Entreprise, et sélectionnez SAML.

2. Localisez votre connexion et sélectionnez son icône Try (Essayer) (triangle/jouer) pour tester l’interaction entre Auth0 et l’IdP distant. Si la connexion ne fonctionne pas, poursuivez avec les étapes détaillées dans cette section. Si c’est le cas, passez à la section suivante.

3. À côté de la connexion SAML, cliquez sur Settings (Paramètres) (représenté par l’icône d’engrenage).

   

4. Vérifiez et confirmez ce qui suit avec l’administrateur de l’IdP :

   1. Que l'URL de connexion est l'URL d'authentification unique (SSO) correcte. C'est l'URL vers laquelle Auth0 redirigera l'utilisateur pour l'authentification.

   2. Si l’IdP attend une liaison HTTP-POST ou une liaison HTTP-Redirect. Vous pouvez changer la liaison par défaut dans l’onglet Settings (Paramètres) .

   3. Si vos requêtes d’authentification doivent être signées. Si c’est le cas, quel algorithme de signature l’IdP attend-il que vous utilisiez? (Notez que les requêtes d’authentification ne sont pas couramment signées.) Si vous envoyez des requêtes signées, activez la bascule Sign Request (Signer la requête) dans les paramètres de connexion et assurez-vous que la valeur Signing Algorithm (Algorithme de signature) corresponde à ce que l’IdP attend.

   4. Demandez à l’administrateur de l’IdP de vérifier les entrées de journal qui pourraient fournir des informations sur le problème.

Dans ce cas, l’utilisateur se connecte avec succès au fournisseur d’identité, mais les journaux d’Auth0 n’affichent pas d’événement de connexion réussi.

1. Vérifiez les pages Logs (Journaux) et Users (Utilisateurs) dans Auth0 Dashboard pour voir si Auth0 affiche un événement de connexion réussi. Si les journaux d’Auth0 n’affichent pas d’événement de connexion réussi, il y a probablement un problème avec l’Assertion d’authentification SAML renvoyée par l’IdP ou Auth0 n’est pas en mesure de consommer l’assertion.

2. Vérifiez les informations qu’Auth0 envoie à l’application en capturant un suivi HTTP de la séquence de connexion et en analysant ce suivi HTTP.

   Avant de partager un fichier HAR avec quiconque (y compris Auth0), assurez-vous de supprimer ou d’obscurcir toutes les données sensibles, telles que :

   • les informations confidentielles de l’utilisateur

   • les informations personnelles identifiables (PII)

   • les informations confidentielles relatives à l’application

   Pour en savoir plus, consultez les articles suivants sur Communauté Auth0 :

   • Assainissement des traces HTTP

   • Comment assainir automatiquement un fichier de trace HTTP

   • Comment caviarder manuellement des informations sensibles

   • Fichier HAR trop volumineux pour être téléversé dans le dossier d’assistance

3. Vous pouvez visualiser le suivi HTTP dans un analyseur de fichiers HAR, tel que l’analyseur HAR de Google.

   1. Examinez la séquence d’URL invoquées dans le suivi HTTP.

      1. Les premières seront des URL pour votre application.

      2. Il y aura ensuite une redirection vers une URL Auth0 (comme par exemple {yourDomain}).

   2. Après une ou plusieurs URL intermédiaires, il y aura un POST de retour vers Auth0 contenant l’assertion SAML ayant les informations de l’utilisateur. L’URL doit être destiné au Service consommateur d’assertions (ACS) d’Auth0, qui consomme l’assertion et extrait les informations nécessaires.

   3. Cliquez sur la ligne correspondant à l’appel POST dans l’analyseur HAR.

   4. Passez à l’onglet Données POST et recherchez l’assertion SAML.

   5. Copiez et collez la réponse SAML dans un débogueur SAML.

   6. Retirez la « réponse SAML  » au début, ainsi que tout ce qui commence par &RelayState= à la fin.

4. Après avoir récupéré et décodé le message SAML, vérifiez les champs suivants :

   Champ	Description
   Destination	Vérifiez que la destination de l’assertion SAML est le bon locataire Auth0 et la bonne connexion (https://{TENANT}.auth0.com/login/callback?connection={CONNECTION}).
   Status Field (Champ d’état)	Ce champ doit indiquer la réussite. (<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>).
   Destinataire	Vérifiez que l’élément Méthode <saml:SubjectConfirmation contient le bon locataire et la bonne connexion dans le champ “Recipient” (https://{TENANT}.auth0.com/login/callback?connection={CONNECTION}).
   Public	Vérifiez que le champ de restriction de public SAML contient les bonnes informations sur le locataire et sur la connexion (<saml:AudienceRestriction><saml:Audience>urn:auth0:{TENANT}:{CONNECTION}</saml:audience>).
   Dénomination	L’attribut identifié par le champ NameIdentifier doit être connu de l’application. Si ce n’est pas le cas, l’identifiant doit être un autre attribut dans l’assertion (tel qu’un identifiant IdP interne pour l’utilisateur ou une adresse courriel).
   Clé de signature	Vérifiez que la valeur indiquée par l’élément X509Certificate correspond à la valeur fournie à votre connexion.
   Certificat	Comparez le certificat envoyé à celui que vous avez fourni à l’application.

Dans ce cas, l’utilisateur se connecte à l’IdP avec succès, les journaux d’Auth0 affichent un événement de connexion réussi, mais les attributs du profil de l’utilisateur ne sont pas corrects.

Vérifiez si le profil Auth0 de l’utilisateur est correctement rempli :

1. Allez à Dashboard) > User Management (Gestion des utilisateurs) > Users (Utilisateurs).

2. Trouvez et cliquez sur l’utilisateur spécifique pour ouvrir son profil. Si plusieurs lignes existent pour un utilisateur précis, assurez-vous d’ouvrir l’enregistrement liée à la connexion SAML.

3. Sur le profil de l’utilisateur, vous pouvez voir ses informations de deux manières. Vous pouvez utiliser l’onglet Details (Détails) ou l’onglet Raw JSON (JSON brut) . Cela vous montre quels attributs Auth0 a reçus du fournisseur d’identité.

4. Si l’attribut est manquant, vérifiez s’il a été inclus dans l’assertion. Vous pouvez le faire en décodant l’assertion SAML, ou vous pouvez activer le débogage pour la connexion.

   1. Pour activer le débogage pour la connexion, accédez à Authentification (Authentification) > Enterprise (Entreprise).

   2. Ouvrez la liste des connexions de l’IdP SAML , cliquez sur Settings (Paramètres), et activez Debug Mode (Mode débogage).

      

   3. Avec Debug Mode (Mode débogage) activé, les entrées de journal Warning During Login (Avertissement lors de la connexion)dans le Dashboard contiennent une propriété original_profile répertoriant chaque attribut inclus dans l’assertion SAML par le fournisseur d’identité. Vous pouvez utiliser cette liste pour voir les informations que l’IdP envoie et pour pouvoir créer les mappages. Si l’attribut manquant n’est pas du tout présent dans l’assertion, veuillez travailler avec l’IdP pour vous assurer qu’il est inclus.

5. Si une valeur d’attribut existe dans le profil utilisateur Auth0, mais n’est pas mappée au bon attribut, vous pouvez corriger cela via la fonctionnalité de mappage de connexion.

   1. Vous pouvez le faire en accédant à Authentication (Authentification) > Enterprise (Entreprise).

   2. Ouvrez la liste des connexions de l’IdP SAML et allez à l’onglet Mappages.

      

   3. Dans l’éditeur fourni, il y a un extrait JSON que vous pouvez modifier pour configurer vos mappages Le nom à gauche est l’attribut du profil utilisateur Auth0 auquel la valeur de l’assertion sera mappée. La valeur à droite est l’identifiant dans l’assertion SAML d’où provient l’attribut. Lorsque Auth0 intègre des attributs SAML non mappés dans le profil utilisateur, les identifiants d’attribut contenant des points . sont remplacés par les deux points :. Lors de la configuration de vos mappages, assurez-vous que les identifiants que vous fournissez correspondent à ceux de l’assertion SAML.

Dans ce cas, l’utilisateur se connecte à l’IdP avec succès, les journaux d’Auth0 affichent un événement de connexion réussi, et les attributs du profil de l’utilisateur sont corrects, mais l’utilisateur ne peut pas accéder à l’application.

1. Vérifiez les fichiers journaux de votre application pour voir s’il y a des messages d’erreur indiquant pourquoi l’utilisateur ne peut pas accéder à l’application. Les deux causes les plus courantes de ce problème sont :

   1. Informations de profil utilisateur manquantes.

   2. Informations d’autorisation incorrectes ou manquantes.

2. Vérifiez les informations qu’Auth0 envoie à l’application en capturant un suivi HTTP de la séquence de connexion et en analysant ce suivi HTTP. Vous pouvez visualiser le suivi HTTP dans un analyseur de fichiers HAR, tel que l’analyseur HAR de Google.

   Avant de partager un fichier HAR avec quiconque (y compris Auth0), assurez-vous de supprimer ou d’obscurcir toutes les données sensibles, telles que :

   • les informations confidentielles de l’utilisateur

   • les informations personnelles identifiables (PII)

   • les informations confidentielles relatives à l’application

   Pour en savoir plus, consultez les articles suivants sur Communauté Auth0 :

   • Assainissement des traces HTTP

   • Comment assainir automatiquement un fichier de trace HTTP

   • Comment caviarder manuellement des informations sensibles

   • Fichier HAR trop volumineux pour être téléversé dans le dossier d’assistance

   1. Examinez la séquence d’URL invoquées dans le suivi HTTP.

      1. Les premières seront des URL pour votre application.

      2. Il y aura ensuite une redirection vers une URL Auth0 (comme par exemple {yourDomain}).

   2. Après une ou plusieurs URL intermédiaires, il y aura un POST de retour vers Auth0 contenant l’assertion SAML ayant les informations de l’utilisateur. L’URL doit être destiné au Service consommateur d’assertions (ACS) d’Auth0, qui consomme l’assertion et extrait les informations nécessaires.

   3. Cliquez sur la ligne correspondant à l’appel POST dans l’analyseur HAR.

   4. Passez à l’onglet Données POST et recherchez l’assertion SAML.

   5. Copiez et collez la réponse SAML dans un débogueur SAML.

   6. Retirez la réponse SAML au début, ainsi que tout ce qui commence par &RelayState= à la fin.

3. Après avoir récupéré et décodé le message SAML, vérifiez les champs suivants :

   Champ	Description
   Destination	Vérifiez que la destination de l’assertion SAML est le bon locataire Auth0 et la bonne connexion (https://{TENANT}.auth0.com/login/callback?connection={CONNECTION}).
   Status Field (Champ d’état)	Ce champ doit indiquer la réussite. (<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>).
   Destinataire	Vérifiez que l’élément Méthode <saml:SubjectConfirmation contient le bon locataire et la bonne connexion dans le champ “Recipient” (https://{TENANT}.auth0.com/login/callback?connection={CONNECTION}).
   Public	Vérifiez que le champ de restriction de public SAML contient les bonnes informations sur le locataire et sur la connexion (<saml:AudienceRestriction><saml:Audience>urn:auth0:{TENANT}:{CONNECTION}</saml:audience>).
   Dénomination	L’attribut identifié par le champ NameIdentifier doit être connu de l’application. Si ce n’est pas le cas, l’identifiant doit être un autre attribut dans l’assertion (tel qu’un identifiant IdP interne pour l’utilisateur ou une adresse courriel).
   Clé de signature	Vérifiez que la valeur indiquée par l’élément X509Certificate correspond à la valeur fournie à votre connexion.
   Certificat	Comparez le certificat envoyé à celui que vous avez fourni à l’application.

4. Si votre flux d’autorisation utilise un protocole conforme à OidentifiantC, vous pouvez capturer un suivi HAR et le visualiser à l’aide de l’analyseur HAR de Google.

   1. Examinez la séquence des URL dans le suivi et recherchez les éléments suivants :

      1. Les premières seront des URL pour votre application.

      2. Il y aura ensuite une redirection vers une URL Auth0 (comme par exemple {yourDomain}).

   2. Plus bas se trouve l’URL de rappel de votre application. Assurez-vous qu’il est correct.

   3. Récupérez le jeton d’ID de cet appel et collez-le dans un décodeur JWT. Vérifiez que les revendications dans le jeton contiennent les informations nécessaires à l’application.

5. Si vous utilisez un flux initié par l’IdP (par exemple, l’utilisateur commence à partir du fournisseur d’identité dans une application de portail), assurez-vous que :

   1. L’URL du Service consommateur d’assertions (ACS) au niveau du fournisseur d’identité inclut le nom de la connexion (p. ex., https://{yourDomain}/login/callback?connection=CONNECTION_NAME)

   2. L’onglet de configuration initié par l’IdP pour la connexion est correctement rempli, y compris :

      1. Le comportement SSO initié par l’IdP est réglé sur Accept Requests (Accepter les requêtes);

      2. L’application vers laquelle l’utilisateur doit être dirigé;

      3. Le protocole entre l’application et Auth0 (qui n’est pas nécessairement SAML comme la connexion, et qui est très probablement Openidentifiant Connect);

      4. Toute valeur spécifique au protocole à inclure dans la chaîne de requête, comme scope, response_type, redirect_uri, et audience. Ces valeurs doivent correspondre à celles attendues par l’application lors de l’utilisation d’un flux initié par le SP.

   3. Désactivez temporairement vos règles pour vous assurer qu’aucune interférence ne perturbe le processus de connexion.

   4. Si vous avez activé l’authentification multifacteur (MFA), désactivez-la temporairement pour vous assurer qu’elle ne perturbe pas le processus de connexion.

   5. Vérifiez que la connexion SAML fonctionne dans un flux initié par le SP en utilisant l’option Try (Essayer) pour exécuter un test de connexion.

L’erreur peut apparaître comme suit :

<samlp:Status> <samlp:StatusCodeValue="urn:oasis:names:tc:SAML:2.0:status:Responder" /> </samlp:Status>

1. Assurez-vous que l’algorithme de signature sur votre connexion Auth0 est le même que la configuration du côté ADFS : soit rsa-sha256 soit rsa-sha1.

2. Alternativement, vous pouvez contacter votre administrateur ADFS pour connaître la méthode de signature prévue ou pour voir si leurs journaux contiennent des informations supplémentaires sur la raison de l’erreur.

Lors du dépannage d’une connexion SAML, il y a quatre étapes principales à vérifier :

• Étape 1 : L’utilisateur est redirigé avec succès vers un IdP et peut se connecter.

• Étape 2 : Après s’être connecté avec l’IdP, l’utilisateur revient à Auth0 avec un événement de connexion réussi enregistré.

• Étape 3 : Après un événement de connexion réussi dans Auth0, le profil utilisateur dans Auth0 est correct.

• Étape 4 : L’utilisateur est redirigé avec succès vers l’application et peut y accéder.

Dans ce cas, l’utilisateur se connecte à l’IdP avec succès, mais un événement de connexion réussi n’apparaît pas dans les journaux d’Auth0.

1. Si vous utilisez une connexion à la base de données Auth0 :

   1. Vérifiez que l’utilisateur existe et que le mot de passe saisi est correct.

   2. Désactivez temporairement vos règles pour vous assurer qu’aucune interférence ne perturbe le processus de connexion.

   3. Si vous avez activé l’authentification multifacteur (MFA), désactivez-la temporairement pour vous assurer qu’elle ne perturbe pas le processus de connexion.

2. Si vous utilisez une connexion à la base de données Auth0 ou une connexion SAML distante, vérifiez que la connexion SAML fonctionne en utilisant l’option Try (Essayer) pour exécuter un test de connexion.

Dans ce cas, l’utilisateur se connecte à l’IdP avec succès, un événement de connexion réussi s’affiche dans les journaux d’Auth0, mais les attributs du profil de l’utilisateur ne sont pas corrects. Si l’utilisateur :

• Semble se connecter avec succès.

• Les pages Journaux et Utilisateurs dans Auth0 Dashboard devraient afficher les événements de connexion réussie.

La prochaine étape consiste à vérifier que le profil de l’utilisateur contient les attributs de profil utilisateur nécessaires.

1. Allez à Dashboard) > User Management (Gestion des utilisateurs) > Users (Utilisateurs).

2. Trouvez et cliquez sur l’utilisateur spécifique pour ouvrir son profil. Si plusieurs lignes existent pour un utilisateur précis, assurez-vous d’ouvrir l’enregistrement liée à la connexion SAML.

3. Sur le profil de l’utilisateur, vous pouvez voir ses informations de deux manières. Vous pouvez utiliser l’onglet Details [Détails] ou l’onglet Raw JSON . Cela vous montre quels attributs Auth0 a reçus du fournisseur d’identité. Si un attribut est manquant, vérifiez auprès du fournisseur d’identité pour confirmer qu’il possède l’attribut et qu’il le renvoie à Auth0.

Dans ce cas, l’utilisateur se connecte à l’IdP avec succès, un événement de connexion réussi s’affiche dans les journaux d’Auth0, et les attributs du profil de l’utilisateur sont corrects, mais l’utilisateur ne peut pas accéder à l’application.

1. Vérifiez si le profil Auth0 de l’utilisateur est correctement rempli :

   1. Allez à Dashboard (Tableau de bord) > User Management (Gestion des utilisateurs) > Users (Utilisateurs).

   2. Trouvez et cliquez sur l’utilisateur spécifique pour ouvrir son profil. Si plusieurs lignes existent pour un utilisateur précis, assurez-vous d’ouvrir l’enregistrement liée à la connexion SAML.

   3. Sur le profil de l’utilisateur, visualisez ses informations de deux manières. Vous pouvez utiliser l’onglet Details [Détails] ou l’onglet Raw JSON . Cela vous montre quels attributs Auth0 a reçus du fournisseur d’identité. Assurez-vous que le profil inclut tous les détails requis par l’application. Si un attribut d’utilisateur est manquant, vérifiez auprès du fournisseur d’identité pour confirmer qu’il possède l’attribut et qu’il le renvoie à Auth0.

2. Vérifiez les fichiers journaux de l’application pour voir s’il y a des messages d’erreur indiquant pourquoi l’utilisateur ne peut pas accéder à l’application. Les deux causes les plus courantes de ce problème sont des informations de profil utilisateur manquantes ou des informations d’autorisation incorrectes ou manquantes.

3. Vérifiez les informations qu’Auth0 envoie à l’application en capturant un suivi HTTP de la séquence de connexion et en analysant ce suivi HTTP. Vous pouvez visualiser le suivi HTTP dans un analyseur de fichiers HAR, tel que l’analyseur HAR de Google.

   Avant de partager un fichier HAR avec quiconque (y compris Auth0), assurez-vous de supprimer ou d’obscurcir toutes les données sensibles, telles que :

   • les informations confidentielles de l’utilisateur

   • les informations personnelles identifiables (PII)

   • les informations confidentielles relatives à l’application

   Pour en savoir plus, consultez les articles suivants sur Communauté Auth0 :

   • Assainissement des traces HTTP

   • Comment assainir automatiquement un fichier de trace HTTP

   • Comment caviarder manuellement des informations sensibles

   • Fichier HAR trop volumineux pour être téléversé dans le dossier d’assistance

   1. Examinez la séquence d’URL invoquées dans le suivi HTTP.

      1. Les premières seront des URL pour votre application.

      2. Il y aura ensuite une redirection vers une URL Auth0 (comme par exemple {yourDomain}).

   2. Après une ou plusieurs URL intermédiaires, il y aura un POST de retour vers Auth0 contenant l’assertion SAML ayant les informations de l’utilisateur. L’URL doit être destiné au Service consommateur d’assertions (ACS) d’Auth0, qui consomme l’assertion et extrait les informations nécessaires.

   3. Cliquez sur la ligne correspondant à l’appel POST dans l’analyseur HAR.

   4. Passez à l’onglet Données POST et recherchez l’assertion SAML.

   5. Copiez et collez la réponse SAML dans un débogueur SAML.

   6. Retirez la réponse SAML au début, ainsi que tout ce qui commence par &RelayState= à la fin.

4. Après avoir récupéré et décodé le message SAML, vérifiez les champs suivants :

   Champ	Description
   Destination	Vérifiez que la destination de l’assertion SAML est le bon locataire Auth0 et la bonne connexion (https://{TENANT}.auth0.com/login/callback?connection={CONNECTION}).
   Status Field (Champ d’état)	Ce champ doit indiquer la réussite. (<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>).
   Destinataire	Vérifiez que l’élément Méthode <saml:SubjectConfirmation contient le bon locataire et la bonne connexion dans le champ “Recipient” (https://{TENANT}.auth0.com/login/callback?connection={CONNECTION}).
   Public	Vérifiez que le champ de restriction de public SAML contient les bonnes informations sur le locataire et sur la connexion (<saml:AudienceRestriction><saml:Audience>urn:auth0:{TENANT}:{CONNECTION}</saml:audience>).
   Dénomination	L’attribut identifié par le champ NameIdentifier doit être connu de l’application. Si ce n’est pas le cas, l’identifiant doit être un autre attribut dans l’assertion (tel qu’un identifiant IdP interne pour l’utilisateur ou une adresse courriel).
   Clé de signature	Vérifiez que la valeur indiquée par l’élément X509Certificate correspond à la valeur fournie à votre connexion.
   Certificat	Comparez le certificat envoyé à celui que vous avez fourni à l’application.

5. Assurez-vous que l’assertion SAML contient toutes les informations supplémentaires requises par l’application et que ces informations sont présentes dans les attributs attendus par l’application.

   1. Si vous devez modifier l’assertion envoyée à partir d’Auth0 à votre application, vous pouvez ajouter ou mapper des attributs en utilisant des règles.

      1. Connectez-vous à Auth0 et accédez à Règles.

      2. Cliquez sur Create Rule (Créer des règles) et, sur la page suivante, choisissez le modèle Change your SAML configuration (Modifier votre configuration SAML) .

      3. Dans l’éditeur de règles, supprimez les commentaire des lignes que vous souhaitez utiliser. Utilisez les lignes 9 à 17 dans le modèle pour mapper les attributs selon vos besoins. Vous pouvez également ajouter des lignes pour mettre en œuvre des mappages. Le côté gauche de chaque ligne précise l’identifiant de l’attribut dans l’assertion. Le côté droit de chaque ligne fait référence à l’attribut du profil utilisateur Auth0 dont la valeur sera utilisée pour remplir l’assertion sortante envoyée à l’application.

         //context.samlConfiguration.mappings = {    
             // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier":      "user_id",    
             // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress":        "email",    
             // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name":                "name",    
             // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname":           "given_name",    
             // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname":             "family_name",    
             // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn":                 "upn",    
             // "http://schemas.xmlsoap.org/claims/Group":                                   "groups"    
             // };

         Was this helpful?

         Yes /No

Les valeurs SessionIndex et NameID dans la requête de déconnexion SAML doivent correspondre à celles reçues par le fournisseur de services dans l’assertion SAML d’origine.

Si les étapes de dépannage listées ci-dessus ne résolvent pas les problèmes, veuillez demander de l’aide auprès d’Auth0 en ouvrant un ticket dans le Centre d’assistance Assurez-vous d’inclure les informations suivantes :

1. Le nombre d’utilisateurs rencontrant ce problème. Un? Tous?

2. Si ce problème implique une nouvelle configuration ou s’il implique une intégration existante qui a soudainement cessé de fonctionner.

3. Le nombre de demandes affectées.

4. Quel est le comportement attendu, ainsi que le comportement actuel.

5. À quel niveau l’utilisateur arrive dans la séquence de connexion

6. Le nom de l’application enregistrée dans Auth0 et le protocole d’identité qu’elle utilise.

7. Le nom de la connexion impliquée

8. Si vous utilisez ou non l’élément d’interface Auth0 Lock (si oui, quelle version?)

9. Utilisez-vous une version personnalisée de Lock?

10. Un suivi HTTP de l’interaction SSO dans un fichier .har

    Avant de partager un fichier HAR avec quiconque (y compris Auth0), assurez-vous de supprimer ou d’obscurcir toutes les données sensibles, telles que :

    • les informations confidentielles de l’utilisateur

    • les informations personnelles identifiables (PII)

    • les informations confidentielles relatives à l’application

    Pour en savoir plus, consultez les articles suivants sur Communauté Auth0 :

    • Assainissement des traces HTTP

    • Comment assainir automatiquement un fichier de trace HTTP

    • Comment caviarder manuellement des informations sensibles

    • Fichier HAR trop volumineux pour être téléversé dans le dossier d’assistance

11. Une entrée de journal Auth0 pour l’authentification échouée.

12. Un fichier de journal d’authentification provenant de toute application tierce (comme SharePoint) impliquée

• Intégrations SAML d’authentification unique
• Tester SAML SSO avec Auth0 comme fournisseur de service et fournisseur d’identité