Résoudre les problèmes de configuration SAML

Décrit le dépannage des problèmes de configuration SAML.

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

• Auth0 agit-il comme SAML Service Provider (SP), comme fournisseur d’identité (IdP) SAML, ou comme les deux ?

  Le SP redirige les utilisateurs ailleurs pour l’authentification. L’IdP authentifie l’utilisateur en l’invitant à se connecter et en validant les renseignements fournis. Si votre application redirige l’utilisateur vers Auth0 pour l’authentification au moyen de SAML, alors Auth0 est l’IdP. Si Auth0 redirige les utilisateurs au moyen d’une Connexion vers un IdP distant par SAML, alors Auth0 est le SP auprès de cet IdP distant. Auth0 peut agir comme SP, comme IdP, ou comme 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 commencent lorsque l’utilisateur accède à l’application SP et est redirigé vers l’IdP pour se connecter. Un flux initié par l’IdP signifie que l’utilisateur accède à l’IdP, se connecte, puis est redirigé vers l’application SP.

  En contexte d’entreprise, le flux initié par l’IdP est le plus courant.

• Quel attribut du profil utilisateur identifie l’utilisateur auprès de l’IdP (pendant la connexion) et dans chaque application ?

  Si l’attribut servant d’identifiant diffère entre l’IdP et la ou les applications, vous devrez configurer les mappages appropriés dans Auth0 afin qu’il envoie aux applications les bons attributs du profil utilisateur.

  • D’après notre expérience, utiliser l’adresse de courriel comme identifiant unique est l’option la plus simple, bien que cette option soulève des préoccupations en matière de confidentialité.
  • Les organisations d’entreprise utilisent souvent un identifiant interne quelconque avec l’IdP, qui doit être mappé à un autre attribut pertinent pour les applications SaaS externes.

• Vos requêtes d’authentification sont-elles signées ?

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

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

1. Combien d’utilisateurs rencontrent le problème ? Un seul utilisateur ? Tous les utilisateurs ?
2. S’agit-il d’un problème lié à une nouvelle configuration, ou d’une intégration existante qui a cessé de fonctionner ?
3. Combien d’applications sont touchées par le problème ?
4. Quel est le comportement attendu ? Quel comportement observez-vous ?
5. Jusqu’où l’utilisateur se rend-il dans la séquence de connexion ?

Vérifiez les utilisateurs concernés

• Vérifiez le profil, le navigateur ou l’appareil de l’utilisateur afin de déceler tout problème.
• Vérifiez si le problème se produit dans tous les navigateurs chez les utilisateurs concernés (ce qui indique un problème de données) ou seulement dans certains types de navigateurs (ce qui indique un problème propre au navigateur).
• Vérifiez que 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 un logiciel susceptible d’avoir une incidence sur l’authentification et/ou l’autorisation (par exemple, un logiciel requis qui ne serait pas en cours d’exécution).
• Vérifiez si l’utilisateur peut accéder à certaines URL clés de l’application, comme l’URL de l’IdP pour l’authentification unique (SSO) (ce qui indique un problème de connectivité réseau).

Résoudre les problèmes liés à Auth0 en tant que fournisseur de services

Erreurs courantes

Voici quelques erreurs courantes auxquelles vous pourriez être confronté lorsque Auth0 agit comme fournisseur de services, ainsi que les étapes à suivre pour les corriger.

Erreur : Connexion désactivée

Ce message indique que l’application n’est associée à aucune connexion active :

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

1. Accédez à Auth0 Dashboard > Authentication > Enterprise, puis sélectionnez un type de connexion.
2. Sélectionnez le nom de votre connexion.
3. Sélectionnez la vue Applications.
4. Activez au moins une application (si vous n’en voyez aucune dans la liste, vous devrez créer une application avant de continuer).

Erreur : ouverture de session initiée par l’IdP non activée

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

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

Si cette erreur s’affiche lorsque vous utilisez un flux initié par le SP, c’est qu’un des éléments suivants est manquant ou vide :

• paramètre RelayState
• attribut InResponseTo dans la réponse SAML

Si ces éléments sont manquants ou vides, Auth0 considère l’ouverture de session comme étant initiée par l’IdP. Vous pouvez corriger cette erreur en vérifiant votre configuration pour vous assurer que les deux champs sont bien remplis et renvoyés correctement.

Pour corriger le problème :

1. Accédez à Auth0 Dashboard > Authentication > Enterprise, puis sélectionnez un type de connexion.
2. Sélectionnez le nom de votre Connexion.
3. Sélectionnez la vue IdP-Initiated SSO.
4. Repérez IdP-Initiated SSO Behavior, puis sélectionnez Accept Requests pour activer les ouvertures de session initiées par l’IdP.
5. Sélectionnez l’application par défaut et le protocole de réponse utilisés par cette application et, au besoin, précisez les paramètres supplémentaires que vous souhaitez transmettre à l’application.

Erreur : l’attribut InResponseTo ne correspond pas à l’ID de l’AuthNRequest

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

• des témoins bloqués
• des ID qui ne correspondent pas à ceux de la requête SAML la plus récente
• une utilisation incohérente des domaines

Si votre locataire utilise un domaine personnalisé, il peut y 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é :

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

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

Si l’ID est renvoyé vers un autre domaine dans l’attribut InResponseTo d’une réponse SAML, votre locataire Auth0 n’en a aucune trace et renvoie l’erreur ci-dessus.

Pour corriger ce problème :

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

Erreur : application par défaut pour un flux initié par l’IdP non configurée

Cette erreur se produit généralement lorsque vous avez activé des flux initiés par l’IdP, mais que vous n’avez pas fourni les renseignements nécessaires pour exécuter ce 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’URL ACS doit utiliser le même domaine que la demande d’authentification initiale. Si vous utilisez des domaines personnalisés, elle doit correspondre à l’URL de rappel du domaine personnalisé.

Si cette erreur s’affiche lorsque vous utilisez un flux initié par le SP, l’un des éléments suivants est absent ou vide :

• paramètre RelayState
• attribut InResponseTo dans la réponse SAML

Si ces éléments sont absents ou vides, Auth0 traite la connexion comme étant initiée par l’IdP. Vous pouvez corriger cette erreur en vérifiant votre configuration pour vous assurer que les deux champs sont bien remplis et renvoyés correctement.

Pour corriger ce problème :

1. Accédez à Auth0 Dashboard > Authentication > Enterprise, puis sélectionnez un type de connexion.
2. Sélectionnez le nom de votre Connexion.
3. Sélectionnez la vue IdP-Initiated SSO.
4. Sélectionnez l’Default Application et le Response Protocol utilisés par cette application et, au besoin, indiquez tout paramètre supplémentaire que vous souhaitez transmettre à l’application.

Erreur : RelayState manquant

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

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

Erreur : Audience invalide

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

Pour trouver l’ID d’entité de votre connexion :

1. Accédez à Auth0 Dashboard > Authentication > Enterprise, puis sélectionnez un type de connexion.
2. Sélectionnez le nom de votre connexion.
3. Sélectionnez la vue Setup, puis repérez la section Common Settings; votre Entity ID est le deuxième paramètre affiché.

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

Protocole incorrect spécifié

Une erreur courante consiste à spécifier le mauvais protocole de réponse dans l’onglet IdP-Initiated. 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 OpenID Connect ou WS-Fed, des erreurs se produiront en raison d’une mauvaise configuration.

1. Accédez à Auth0 Dashboard > Authentication > Enterprise, puis sélectionnez un type de connexion.
2. Sélectionnez le nom de votre Connexion.
3. Sélectionnez la vue IdP-Initiated SSO, repérez Response Protocol et vérifiez sa valeur.

L’utilisateur n’est pas déconnecté de l’IdP

Lorsque ADFS est configuré comme IdP SAML, si l’attribut Name ID de l’approbation de partie de confiance 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 d’ADFS, mais plutôt directement vers l’URL de rappel de l’application. Par conséquent, dans ce cas, l’utilisateur n’est pas déconnecté de l’IdP.

Ajoutez l’attribut Name ID en tant que règle dans l’approbation de partie de confiance SAML.

Problèmes de connexion SAML

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

• Étape 1 : l’utilisateur est redirigé correctement vers un fournisseur d’identité (IdP) et peut se connecter.
• Étape 2 : après la connexion auprès de l’IdP, l’utilisateur revient à Auth0 et un événement de connexion réussi est consigné.
• É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é correctement vers l’application et peut y accéder.

Les sections suivantes décrivent comment vérifier chaque étape et déterminer s’il y a des problèmes à une étape donnée.

La page de connexion de l’IdP ne s’affiche pas

1. Accédez à Auth0 Dashboard > Authentication > Enterprise, puis sélectionnez SAML.

2. Repérez votre connexion, puis sélectionnez son icône Try (triangle/lecture) pour tester l’interaction entre Auth0 et l’IdP distant. Si la Connexion ne fonctionne pas, poursuivez avec les étapes décrites dans cette section. Si elle fonctionne, passez à la section suivante.

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

   

4. Vérifiez et confirmez les éléments suivants avec l’administrateur de l’IdP :

   1. Que le Sign In URL correspond bien à l’URL d’authentification unique (SSO). Il s’agit de l’URL vers laquelle Auth0 redirigera l’utilisateur pour l’authentification.
   2. Si l’IdP s’attend à une liaison HTTP-POST ou HTTP-Redirect. Vous pouvez modifier la liaison par défaut dans l’onglet Settings.
   3. Si vos requêtes d’authentification doivent être signées. Si oui, quel algorithme de signature l’IdP s’attend-il à ce que vous utilisiez ? (Notez que les requêtes d’authentification ne sont généralement pas signées.) Si vous envoyez des requêtes signées, activez le bouton Sign Request dans les paramètres de la Connexion et assurez-vous que la valeur de Signing Algorithm correspond à ce que l’IdP attend.
   4. Demandez à l’administrateur de l’IdP de vérifier les journaux qui pourraient fournir des renseignements sur le problème.

Les journaux n’affichent pas d’événement de connexion réussi

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

1. Vérifiez les pages Logs et Users dans l’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 ne parvient pas à traiter l’assertion.

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

   Avant de partager un fichier HAR avec qui que ce soit (y compris Auth0), assurez-vous de supprimer ou de masquer toutes les données sensibles, telles que :

   • Des renseignements confidentiels sur l’utilisateur
   • Des renseignements personnels identifiables (PII)
   • Des renseignements confidentiels sur l’application

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

   • Sanitizing HTTP Traces
   • How to Sanitize an HTTP Trace File Automatically
   • How to Manually Redact Sensitive Information
   • HAR File is Too Large to Upload to the Support Case

3. Vous pouvez afficher la trace HTTP dans un analyseur HAR, comme l’analyseur HAR de Google.

   1. Parcourez la séquence des URL dans la trace HTTP.

      1. Les premières seront des URL de votre application.
      2. Il y aura ensuite une redirection vers une URL d’Auth0 (comme {yourDomain}).

   2. Après une ou plusieurs URL intermédiaires, il y aura une requête POST renvoyée à Auth0 contenant l’assertion SAML et les renseignements sur l’utilisateur. L’URL devrait être celle du service Assertion Consumer Service (ACS) d’Auth0, qui traite l’assertion et en extrait les renseignements nécessaires.

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

   4. Passez à l’onglet POST Data, puis cherchez la réponse SAML.

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

   6. Supprimez le texte “SAML response” 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

Les attributs du profil utilisateur sont incorrects

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

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

1. Accédez à Auth0 Dashboard > User Management > Users.

2. Recherchez l’utilisateur concerné et cliquez dessus pour ouvrir son profil. S’il y a plusieurs entrées pour un utilisateur donné, assurez-vous d’ouvrir l’enregistrement associé à la Connexion SAML.

3. Dans le profil de l’utilisateur, vous pouvez afficher ses détails de deux façons. Vous pouvez utiliser l’onglet Details ou l’onglet Raw JSON. 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. Pour ce faire, vous pouvez décoder l’assertion SAML ou activer le débogage pour la connexion.

   1. Pour activer le débogage pour la connexion, accédez à Authentication > Enterprise.

   2. Ouvrez la liste des connexions IdP SAML, cliquez sur Settings, puis activez Debug Mode.

      

   3. Lorsque Debug Mode est activé, les entrées de journal Warning During Login dans Auth0 Dashboard comportent une propriété original_profile qui répertorie 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 vous aider à créer les mappages. Si l’attribut manquant ne figure pas du tout dans l’assertion, collaborez 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 à l’aide de la fonctionnalité de mappage de la connexion.

   1. Pour ce faire, accédez à Authentication > Enterprise.

   2. Ouvrez la liste des connexions IdP SAML et accédez à l’onglet Mappings.

      

   3. Dans l’éditeur fourni, vous pouvez modifier un extrait JSON pour configurer vos mappages. Le nom à gauche correspond à l’attribut du profil utilisateur Auth0 auquel la valeur de l’assertion sera mappée. La valeur à droite correspond à 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 des deux-points :. Pendant la configuration de vos mappages, assurez-vous que les identifiants fournis correspondent à ceux de l’assertion SAML.

L’utilisateur ne peut pas accéder à l’application

Dans ce cas, l’utilisateur se connecte avec succès auprès de l’IdP, les journaux d’Auth0 indiquent un événement de connexion réussi et les attributs du profil 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’ils contiennent 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 les suivantes :

   1. Des informations du profil utilisateur sont manquantes.
   2. Les informations d’autorisation sont incorrectes ou manquantes.

2. Vérifiez les informations qu’Auth0 envoie à l’application en capturant une trace HTTP de la séquence de connexion et en l’analysant. Vous pouvez consulter la trace HTTP dans un analyseur de fichiers HAR, comme Google’s HAR Analyzer.

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

   • Des renseignements confidentiels sur l’utilisateur
   • Des renseignements personnels identifiables (PII)
   • Des renseignements confidentiels sur l’application

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

   • Nettoyer les traces HTTP
   • Comment nettoyer automatiquement un fichier de trace HTTP
   • Comment caviarder manuellement les renseignements sensibles
   • Le fichier HAR est trop volumineux pour être téléversé dans le dossier de soutien

   1. Parcourez la séquence des URL appelées dans la trace HTTP.

      1. Les premières seront des URL de votre application.
      2. Il y aura ensuite une redirection vers une URL d’Auth0 (comme {yourDomain}).

   2. Après une ou plusieurs URL intermédiaires, il y aura un retour vers Auth0 par POST contenant l’assertion SAML avec les informations de l’utilisateur. L’URL doit être celle du service Assertion Consumer Service (ACS) d’Auth0, qui consomme l’assertion et en extrait les informations nécessaires.

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

   4. Passez à l’onglet POST Data et recherchez la réponse SAML.

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

   6. Supprimez 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

4. Si votre flux d’autorisation utilise un protocole conforme à OIDC, vous pouvez capturer une trace HAR et la consulter à l’aide du HAR Analyzer de Google.

   1. Parcourez la séquence d’URL dans la trace et recherchez les éléments suivants :

      1. Les premières URL correspondront à votre application.
      2. Vous verrez ensuite une redirection vers une URL Auth0 (comme {yourDomain}).

   2. Plus loin se trouve l’URL de rappel de votre application. Assurez-vous qu’elle est correcte.

   3. Récupérez l’ID Token à partir de cet appel, puis collez-le dans un décodeur JWT. Vérifiez que les claims du jeton contiennent les renseignements dont l’application a besoin.

5. Si vous utilisez un flux initié par l’IdP (par exemple, si l’utilisateur commence auprès du fournisseur d’identité dans une application portail), assurez-vous de ce qui suit :

   1. L’URL Assertion Consumer Service (ACS) du fournisseur d’identité inclut le nom de la connexion (par exemple https://{yourDomain}/login/callback?connection=CONNECTION_NAME)

   2. L’onglet de configuration initiée par l’IdP de la Connexion est correctement rempli, notamment :

      1. Le comportement SSO initié par l’IdP est défini sur Accept Requests;
      2. l’application vers laquelle l’utilisateur doit être redirigé;
      3. le protocole entre l’application et Auth0 (qui n’est pas nécessairement SAML comme la connexion, et est très probablement OpenID Connect);
      4. toutes les valeurs propres 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 Rules pour vous assurer que rien n’interfère avec le processus de connexion.

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

   5. Vérifiez que la connexion SAML fonctionne dans un flux initié par le SP en utilisant Try pour exécuter un test de Connexion.

La requête n’a pas pu être exécutée en raison d’une erreur du répondant SAML ou de l’autorité SAML

L’erreur peut s’afficher 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 de votre connexion Auth0 correspond à celui configuré du côté d’ADFS : soit rsa-sha256, soit rsa-sha1.
2. Vous pouvez aussi communiquer avec votre administrateur ADFS pour connaître la méthode de signature attendue ou vérifier si ses journaux contiennent plus d’information sur la cause de l’erreur.

Dépanner Auth0 en tant que fournisseur d’identité

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 l’IdP et peut se connecter.
• Étape 2 : Après s’être connecté auprès de l’IdP, l’utilisateur revient à Auth0 et un événement de connexion réussie est enregistré.
• Étape 3 : Après un événement de connexion réussie 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.

L’événement de connexion réussie n’apparaît pas dans les journaux

Dans ce cas, l’utilisateur se connecte avec succès auprès de l’IdP, mais aucun événement de connexion réussie n’apparaît dans les journaux Auth0.

1. Si vous utilisez une connexion de 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 Rules pour vous assurer que rien n’interfère avec le processus de connexion.
   3. Si vous avez activé l’authentification multifactorielle (MFA), désactivez-la temporairement pour vous assurer qu’elle n’interfère pas avec le processus de connexion.

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

Les attributs du profil utilisateur sont incorrects

Dans ce cas, l’utilisateur se connecte avec succès auprès de l’IdP, un événement de connexion réussie apparaît dans les journaux Auth0, mais les attributs du profil utilisateur sont incorrects. Si l’utilisateur :

• Semble se connecter avec succès.
• Les pages Logs et Users dans le Auth0 Dashboard devraient afficher des événements de connexion réussie

L’étape suivante consiste à vérifier que le profil utilisateur contient les attributs de profil utilisateur nécessaires.

1. Accédez à Auth0 Dashboard > User Management > Users.
2. Recherchez l’utilisateur en question et cliquez dessus pour ouvrir son profil. S’il y a plusieurs lignes pour un utilisateur donné, assurez-vous d’ouvrir l’enregistrement associé à la Connexion SAML.
3. Dans le profil de l’utilisateur, vous pouvez consulter ses détails de deux façons. Vous pouvez utiliser l’onglet Details ou l’onglet Raw JSON. Cela vous montre quels attributs Auth0 a reçus du fournisseur d’identité. S’il manque un attribut, vérifiez auprès du fournisseur d’identité pour confirmer qu’il possède cet attribut et qu’il le renvoie à Auth0.

L’utilisateur ne peut pas accéder à l’application

Dans ce cas, l’utilisateur ouvre une session avec succès auprès de l’IdP, un événement de connexion réussie apparaît dans les journaux Auth0 et les attributs du profil utilisateur sont corrects, mais l’utilisateur ne peut toujours pas accéder à l’application.

1. Vérifiez si le profil Auth0 de l’utilisateur a été correctement renseigné :

   1. Accédez à Auth0 Dashboard > User Management > Users.
   2. Recherchez l’utilisateur en question et cliquez dessus pour ouvrir son profil. S’il existe plusieurs entrées pour un même utilisateur, assurez-vous d’ouvrir l’enregistrement associé à la Connexion SAML.
   3. Dans le profil de l’utilisateur, consultez les détails de l’une des deux façons suivantes : utilisez l’onglet Details ou l’onglet Raw JSON. Vous verrez ainsi quels attributs Auth0 a reçus du fournisseur d’identité. Assurez-vous que le profil contient tous les détails requis par l’application. S’il manque un attribut utilisateur, vérifiez auprès du fournisseur d’identité qu’il dispose bien de cet attribut et qu’il le renvoie à Auth0.

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

3. Vérifiez les informations qu’Auth0 envoie à l’application en capturant une trace HTTP de la séquence de connexion et en l’analysant. Vous pouvez consulter la trace HTTP dans un analyseur de fichiers HAR, comme Google’s HAR Analyzer.

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

   • des informations utilisateur confidentielles
   • des renseignements personnels identifiables (PII)
   • des informations confidentielles sur l’application

   Pour en savoir plus, consultez les articles suivants dans Auth0 Community :

   • Nettoyer les traces HTTP
   • Comment nettoyer automatiquement un fichier de trace HTTP
   • Comment caviarder manuellement les renseignements sensibles
   • Le fichier HAR est trop volumineux pour être téléversé dans le dossier d’assistance

   1. Parcourez la séquence des URL appelées dans la trace HTTP.

      1. Les premières seront des URL de votre application.
      2. Il y aura ensuite une redirection vers une URL Auth0 (comme {yourDomain}).

   2. Après une ou plusieurs URL intermédiaires, il y aura une requête POST de retour vers Auth0 contenant l’assertion SAML avec les informations utilisateur. L’URL devrait être celle du service Assertion Consumer Service (ACS) d’Auth0, qui traite l’assertion et en extrait les informations nécessaires.

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

   4. Passez à l’onglet POST Data, puis recherchez la réponse SAML.

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

   6. Supprimez SAMLResponse= 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

5. Assurez-vous que l’assertion SAML contient tous les renseignements supplémentaires requis par l’application et que ces renseignements figurent dans les attributs attendus par l’application.

   1. Si vous devez modifier l’assertion envoyée par Auth0 à votre application, vous pouvez ajouter des attributs ou faire le mappage des attributs à l’aide de Rules.

      1. Connectez-vous à Auth0 et accédez à Rules.

      2. Cliquez sur Create Rule et, à la page suivante, choisissez le modèle Change your SAML configuration.

      3. Dans l’éditeur de règles, décommentez les lignes que vous voulez utiliser. Utilisez les lignes 9 à 17 du modèle pour faire le mappage des attributs au besoin. Vous pouvez également ajouter des lignes pour définir d’autres mappages. Le côté gauche de chaque ligne indique l’identifiant de l’attribut dans l’assertion. Le côté droit de chaque ligne renvoie à 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"    
             // };
         

Erreur « Aucune session active trouvée qui correspond à LogoutRequest »

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

Contacter le soutien

Si les étapes de dépannage ci-dessus ne résolvent pas le problème, veuillez demander de l’aide à Auth0 en ouvrant un ticket dans le Centre de soutien. Assurez-vous d’inclure les renseignements suivants :

1. Le nombre d’utilisateurs touchés par ce problème. Un seul ? Tous ?

2. S’il s’agit d’une nouvelle configuration ou d’une intégration existante qui a soudainement cessé de fonctionner

3. Le nombre d’applications touchées

4. Le comportement attendu ainsi que le comportement observé actuellement

5. Jusqu’où l’utilisateur se rend 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 concernée

8. Si vous utilisez le widget Auth0 Lock (si oui, quelle version ?)

9. Si une version personnalisée de Lock est utilisée

10. Une trace HTTP de l’interaction SSO dans un fichier .har

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

    • Des renseignements confidentiels sur l’utilisateur
    • Des renseignements personnels identifiables (PII)
    • Des renseignements confidentiels sur l’application

    Pour en savoir plus, consultez les articles suivants dans Auth0 Community :

    • Assainir les traces HTTP
    • Comment assainir automatiquement un fichier de trace HTTP
    • Comment caviarder manuellement les renseignements sensibles
    • Le fichier HAR est trop volumineux pour être téléversé dans le dossier de soutien

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

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

En savoir plus

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