Qu'est-ce que l'authentification SAML dans l'exploitation Zscaler ?
L'authentification SAML est une procédure d'authentification unique (SSO) fondée sur le navigateur : un fournisseur d'identité (IdP) confirme l'identité d'un utilisateur, et Zscaler reprend cette confirmation avec les attributs transmis. L'utilisateur se connecte une seule fois avec son identité d'entreprise ; ses policies s'appliquent ensuite, et des cookies maintiennent la session. Dans l'exploitation Zscaler, SAML est la voie standard pour les parcs d'appareils hétérogènes et les identités cloud, à l'inverse de Kerberos, fondé sur des tickets. Quand une connexion échoue, la cause se situe presque toujours dans la chaîne IdP, attributs, cookies et synchronisation de l'annuaire.
Authentification SAML en détail
La procédure en bref : le navigateur redirige vers l'IdP de l'organisation, l'utilisateur s'y connecte, puis l'IdP renvoie une réponse SAML signée. Zscaler reprend alors l'identité avec des attributs comme l'e-mail, le service ou les groupes. Ces attributs déterminent les policies qui s'appliquent et alimentent le rattachement dans les rapports et les logs.
Dans Zscaler Private Access, la configuration de l'IdP et les attributs SAML font partie du socle géré de façon centralisée ; pour les Microtenants, c'est le domaine par défaut qui s'en charge. Pour la connexion SAML aux applications cloud via l'Identity Proxy, Zscaler documente sa propre série de codes d'erreur, de 0x1388 à 0x13D2.
Pourquoi SAML compte-t-il dans l'exploitation Zscaler ?
SAML pèse deux fois sur le quotidien : sur l'expérience de connexion et sur la précision des policies. Quand la chaîne fonctionne, personne n'y prête attention. Quand elle coince, deux schémas de tickets reviennent : la boucle de connexion vers l'IdP, et le cas « connecté, mais mauvaises règles », le plus souvent dû à des attributs obsolètes. Les deux se ressemblent du point de vue de l'utilisateur mais demandent des corrections différentes. D'où la règle : rendre d'abord le statut d'authentification visible et vérifiable, puis agir sur l'IdP, l'annuaire ou les policies.
Sources d'erreur courantes
- Cookies bloqués ou supprimés : sans session enregistrée, la connexion recommence sans cesse depuis le début.
- Attributs incorrects : l'utilisateur est connecté, mais se retrouve dans les mauvaises policies à cause de valeurs de groupe ou de service erronées.
- Compte non synchronisé : les comptes nouveaux ou renommés sont absents de l'annuaire Zscaler et échouent malgré une connexion IdP correcte.
- Requêtes SAML expirées : des fenêtres de connexion restées ouvertes trop longtemps ou des écarts d'horloge produisent des erreurs 0x13 qui disparaissent avec une nouvelle tentative.
SAML en pratique : ce qu'apporte CentaurNexus
Si une connexion a vraiment abouti et quelles policies s'appliquent à l'instant T, la recherche 360° par utilisateur de CentaurNexus le montre sur une seule page : saisissez un nom ou un e-mail, consultez le statut ZIA, ZPA et ZDX avec l'état d'authentification, sans droits d'administration Zscaler et sans changer de portail. Le helpdesk distingue ainsi en quelques minutes une boucle de connexion d'un problème d'attributs, et remonte un constat plutôt qu'une simple description. Plus de détails dans l'article Support Zscaler sans droits d'administration.
Termes associés
Questions fréquentes sur l'authentification SAML
Dans le navigateur, l'utilisateur est redirigé vers le fournisseur d'identité de l'organisation, par exemple le service de connexion central où existe déjà son identité d'entreprise. Une fois la connexion réussie, l'IdP confirme l'identité à Zscaler par une réponse SAML. Le service retient la connexion via des cookies, si bien que les accès suivants se font sans nouvelle saisie.
SAML est fondé sur le navigateur et s'appuie sur un fournisseur d'identité ; il convient aux parcs d'appareils hétérogènes et aux identités cloud. Kerberos fonctionne avec des tickets issus du domaine Windows, en arrière-plan et discrètement, y compris pour le trafic hors navigateur. Beaucoup d'organisations combinent les deux procédures selon le site et le type d'appareil.
Avec la réponse SAML, le fournisseur d'identité transmet des attributs comme le nom, l'e-mail, le service ou les groupes. Zscaler s'en sert pour le rattachement de l'utilisateur et pour les policies qui s'appliquent par service ou par groupe. Si les attributs sont incorrects, de mauvaises policies s'appliquent bien que la connexion elle-même fonctionne ; un type d'erreur souvent négligé.
Pour l'Identity Proxy, c'est-à-dire la connexion SAML aux applications cloud via Zscaler, l'aide documente la série de codes hexadécimaux de 0x1388 à 0x13D2 : requêtes SAML expirées ou invalides, utilisateurs introuvables, applications désactivées et états cloud transitoires. Beaucoup se résolvent avec une nouvelle tentative après une courte attente.
Les boucles de connexion apparaissent le plus souvent quand la session ne peut pas être enregistrée ou que la chaîne coince : cookies bloqués ou supprimés, session IdP expirée, horloge système décalée, ou compte absent de l'annuaire ou pas encore synchronisé. Changer de navigateur, vérifier les cookies et consulter les logs du client permettent de cerner rapidement la cause.
- Portail d'aide Zscaler : Understanding SAML - help.zscaler.com
- Portail d'aide Zscaler : Understanding User Provisioning and Authentication - help.zscaler.com
Remarque : CentaurNexus est un produit indépendant de SourcingBlox GmbH et non une offre de Zscaler, Inc. Les noms de produits et de marques appartiennent à leurs détenteurs respectifs.