What is SAML authentication in Zscaler operations?
SAML authentication is a browser-based single sign-on method. An identity provider (IdP) confirms a user's identity, and Zscaler accepts that confirmation along with the attributes it carries. The user signs in once with their corporate identity, and their policies then apply for the rest of the session, kept alive by cookies. In Zscaler operations, SAML is the standard route for mixed device fleets and cloud identities, and the counterpart to ticket-based Kerberos. When sign-in fails, the cause almost always sits somewhere in the chain of IdP, attributes, cookies and directory synchronisation.
SAML authentication in detail
The flow in brief: the browser redirects to the organisation's IdP, the user signs in, and the IdP sends back a signed SAML response. Zscaler uses it to take on the identity together with attributes such as email, department or groups. These attributes determine which policies apply and feed the mapping used in reports and logs.
In Zscaler Private Access, the IdP configuration together with its SAML attributes belongs to the centrally managed base configuration; for microtenants, the default microtenant maintains it. For SAML sign-in to cloud applications through the identity proxy, Zscaler documents its own error code range from 0x1388 to 0x13D2.
Why SAML matters in Zscaler operations
SAML shapes daily operations twice over: the sign-in experience and policy accuracy. When the chain works, nobody notices it. When it breaks, two familiar ticket patterns appear: the sign-in loop back to the IdP, and the case of “signed in, but wrong rules”, usually caused by stale attributes. Both look identical to the user but need different fixes. The rule of thumb: make the authentication status visible and provable first, then adjust IdP, directory or policy.
Common sources of error
- Cookies blocked or deleted: without a stored session, sign-in starts over every time.
- Attributes are wrong: signed in, but placed under the wrong policies because of incorrect group or department values.
- Account not synchronised: new or renamed accounts are missing from the Zscaler directory and fail sign-in despite a correct IdP login.
- Stale SAML requests: sign-in windows left open too long, or clock drift, produce 0x13 errors that clear on a fresh attempt.
SAML in practice: what CentaurNexus contributes
Whether a sign-in genuinely went through and which policies currently apply shows up on one screen in CentaurNexus's 360° user search: enter a name or email, see status across ZIA, ZPA and ZDX together with the authentication status, without Zscaler admin rights and without switching portals. That lets the helpdesk separate the sign-in loop from the attribute problem in minutes and escalate with a finding instead of a description. More on this in the article Zscaler support without admin rights.
Related terms
Frequently asked questions about SAML authentication
The browser redirects the user to the organisation's identity provider, typically the central sign-in service tied to their existing corporate identity. Once sign-in succeeds, the IdP confirms the identity to Zscaler with a SAML response. The service then remembers the sign-in through cookies, so later access does not require entering credentials again.
SAML is browser-based and relies on an identity provider, which suits mixed device fleets and cloud identities. Kerberos works with tickets issued by the Windows domain, quietly in the background and for non-browser traffic too. Many organisations combine both methods depending on location and device type.
Along with the SAML response, the identity provider sends attributes such as name, email, department or groups. Zscaler uses them to map the user and to apply policies that depend on department or group. When the attributes are wrong, the wrong policies apply even though sign-in itself works, a failure mode that often gets overlooked.
For the identity proxy, meaning SAML sign-in to cloud applications through Zscaler, the help documentation covers the hexadecimal code range from 0x1388 to 0x13D2: stale or invalid SAML requests, users not found, disabled apps and transient cloud states. Many of these clear after a short wait and a fresh attempt.
Sign-in loops usually happen when the session cannot be stored or the chain breaks down somewhere: blocked or deleted cookies, an expired IdP session, clock drift, or an account missing from the directory or not yet synchronised. Switching browsers, checking cookies and a look at the client logs narrow down the cause quickly.
- Zscaler Help Portal: Understanding SAML - help.zscaler.com
- Zscaler Help Portal: Understanding User Provisioning and Authentication - help.zscaler.com
Note: CentaurNexus is an independent product of SourcingBlox GmbH and not an offering of Zscaler, Inc. Product and brand names belong to their respective owners.