Dépannage SAML 2.0

  • Rversion finale: Yokohama
  • Mis à jour 30 janv. 2025
  • 2 minutes de lecture

    • Avant de contacter le support, essayez les solutions de dépannage disponibles dans la base de connaissances sur Hi.

    Remarque :
    L’instance ne prend pas en charge les solutions fournies par des sites externes.

    Consultez l’article de la base de connaissances suivant : KB0540617 '''Matrice d’erreurs SAML'''.

    Tableau 1. Autres problèmes courants
    Erreur ou symptôme Solution
    Message d’erreur : « n’est pas une fonction ».

    Ce problème peut se produire dans un environnement à plusieurs nœuds. Si le module d’extension n’est pas activé sur tous les nœuds, une erreur comme celle-ci s’affiche :

    org.mozilla.javascript.EcmaError : [JavaPackage org.opensaml.saml2.core.impl.AuthnRequestBuilder] n’est pas une fonction.

    		 Cette erreur se produit car le module d’extension n’était pas actif et n’a pas chargé le fichier .jar. Par conséquent, le code semble manquer. Contactez l’assistance technique pour redémarrer les nœuds auxquels le module d’extension est manquant.
    SAML n’authentifie pas les utilisateurs accédant aux pages CMS. Par défaut, les pages CMS sont publiques et ne nécessitent donc pas d’authentification. Si vous souhaitez que SAML authentifie les pages CMS, changez la page publique view_content.do de active=true à active=false.
    Impossible de rediriger un utilisateur vers une page CMS après l’authentification SAML. Par défaut, l’intégration SSO utilise un paramètre d’URL appelé URI pour contrôler où l’utilisateur est dirigé après l’authentification au niveau du fournisseur d’identités. L’authentification unique ignore les URL relatives. Par exemple, SSO ne peut pas rediriger les utilisateurs vers une URL relative /ess . Au lieu de cela, l’utilisateur doit naviguer vers une URL telle que /nav_to.do ?uri=/ess, qui utilise la syntaxe de lien profond.

    Cependant, cela place le portail ESS dans l’IFrame de contenu de navigation principal. En d’autres termes, le site n’occupe pas la page complète, mais se charge plutôt comme une page dans votre instance. Pour plus d’informations, consultez Sites CMS et Single Sign-On.

    Si vous modifiez la page d’entrée CMS pour la rendre privée en définissant view_content.do sur active=false, le comportement de lien profond nécessite alors une personnalisation du script de connexion de sortie d’installation . Créez un script qui recherche la partie URI de l’URL et construit un paramètre d’URL RelayState contenant le chemin de l’URL relative pour rediriger les utilisateurs après authentification auprès du fournisseur d’identités.
    SAML ne redirige pas les utilisateurs vers la page appropriée après l’authentification. Déterminez si l’état du relais est transmis à l’IdP, puis renvoyé pendant l’authentification. Vous pouvez le faire avec un navigateur capable d’enregistrer les en-têtes de requête HTTP et les informations POST, tel que Chrome avec ses outils de développement intégrés, ou Firefox avec le module complémentaire appelé HTTPfox. Pour Internet Explorer, utilisez une application tierce telle que Fiddler. L’objectif est de voir les requêtes passer du client (navigateur) à l’instance, et du client à l’IdP.