Configure SAML SSO on Zscaler with Microsoft Entra ID — ZIA & ZPA, step by step

Start here · understand the lesson before the detail

What you are learning

This lesson separates the sign-in path from the identity-lifecycle path. You will configure and troubleshoot SAML authentication without confusing it with SCIM provisioning.

In plain English

For SAML, Zscaler is the service provider and Microsoft Entra ID is the identity provider. Entra authenticates the user and sends a signed assertion; Zscaler validates it and applies identity policy. SCIM is separate: it keeps assigned users and groups created, updated, and disabled.

Real example

A user completes MFA but receives the wrong ZIA rule. Authentication may be healthy while the group claim or SCIM membership is wrong. Conversely, a correctly provisioned user can still fail SAML because the Reply URL, Entity ID, certificate, audience, or NameID does not match.

Follow this flow

• Select the correct Zscaler cloud-specific enterprise application.
• Exchange metadata and configure Entity ID, Reply URL, certificate, and claims.
• Assign a pilot group and test SAML with a break-glass admin available.
• Configure SCIM scope, token, mappings, and create/update/disable behaviour separately.
• Verify sign-in logs, provisioning logs, Zscaler user/group mapping, and policy result.

Evidence to collect

• Correct tenant cloud, Entity ID, Reply URL, and signing certificate
• SAML issuer, audience, NameID, attributes, and signature
• Entra assignment and Conditional Access result
• SCIM provisioning event plus Zscaler user/group state

Common mistake to avoid

Do not expose SCIM bearer tokens in screenshots or tickets. Do not assume SAML will deprovision a user after departure; SCIM or another lifecycle process must disable the account. For PAC/tunnel deployments, ensure the unauthenticated IdP path is reachable to avoid an authentication loop.

Current official source checkpoint

• Zscaler Entra SAML and SCIMcurrent official reference used for this beginner explanation
• Microsoft provisioning guidecurrent official reference used for this beginner explanation

Key terms before you continue

IdPMicrosoft Entra ID authenticates the user.

SPZscaler consumes and validates the SAML assertion.

SAMLSigned authentication exchange.

SCIMAutomated user and group lifecycle provisioning.

The four words this whole lesson rides on

Tap each card. If these four click, every screen later in the lesson will make sense.

① SAML in 90 seconds: the signed-badge model

Two systems that have never met still need to agree on one thing: "this is really Priya." SAML solves that with three artifacts they exchange once, then trust forever. The IdP (Entra) authenticates the user. The SP (Zscaler) trusts the IdP and lets the user in. The password never touches Zscaler.

Those three trust anchors are the only things you actually configure, on both sides:

• Entity ID / Audience — the SP's unique name. The assertion's Audience field must match it character-for-character.
• ACS / Reply URL — the SP endpoint that catches the assertion the browser POSTs back.
• Signing certificate — the IdP's public key. The SP verifies every assertion's signature against it. This is the single anchor that breaks the most logins.

Zscaler's ZIA and ZPA user apps are both SP-initiated: the user lands on Zscaler first, and Zscaler bounces them to Entra. Watch the healthy path, then press Break it to see the most common failure — a certificate mismatch.

② ZIA user SSO: the gallery flow, end to end

This is the most common job: let employees authenticate to the Zscaler internet-access proxy with their Entra accounts. ZIA SSO is SP-initiated and supports both JIT and SCIM provisioning. You configure two consoles: Entra first, then ZIA.

Step A — the Entra side (the IdP)

Sign in to the Microsoft Entra admin center as at least a Cloud Application Administrator, then:

1. Entra ID → Enterprise apps → New application. Add the gallery app that matches your Zscaler cloud — e.g. Zscaler Internet Access ZSTwo for the zscalertwo.net cloud, ZSThree for zscalerthree.net, and so on. Picking the wrong cloud's app means nothing will match.
2. Open Single sign-on → SAML. Edit Basic SAML Configuration. The Identifier (Entity ID) is a fixed string for this app, so only one instance can exist per tenant. Set the Sign-on URL to your cloud's portal (for ZSThree it is https://login.zscalerthree.net/sfc_sso).
3. Under Attributes & Claims, confirm the extra claim memberOf = user.assignedroles so group/role data rides along.
4. In SAML Signing Certificate, download Certificate (Base64) — this is the .pem file ZIA needs. Copy the Login URL too.
5. Users and groups → Add user/group — assign the people (or a group) who should get access. Skip this and Entra throws AADSTS50105 at every user.

Step B — the ZIA side (the SP)

In the ZIA Admin Portal go to Administration → Authentication → Authentication Settings, set Authentication Type = SAML, then click Configure SAML and fill the dialog:

Three fields decide whether this works. ① Login Name Attribute must be exactly NameID — it is case-sensitive. ② Public SSL Certificate accepts only the Base64 (.pem) file you downloaded — not the metadata XML, not a DER .cer. ③ Enable SAML Auto-Provisioning if you want ZIA to create users on first login (JIT); then the display-name, group, and department attribute fields tell ZIA which claims to read.

Before you upload, sanity-check the certificate from a shell — a bad or expired cert is the number-one reason ZIA later rejects assertions:

openssl x509 -in ZscalerInternetAccess.cer -noout -subject -issuer -enddate

subject=CN = Microsoft Azure Federated SSO Certificate
issuer=CN = Microsoft Azure Federated SSO Certificate
notAfter=Jun  4 09:15:22 2029 GMT

If openssl errors with "unable to load certificate," you grabbed the wrong format — re-download Certificate (Base64). Note the notAfter date: that is the day this login silently dies unless you re-upload a fresh cert (more on that in Section 4).

③ ZPA user SSO + SCIM: metadata XML and group sync

ZPA (private/ZTNA access) uses the same SAML protocol but a different artifact. Instead of a Base64 cert, ZPA imports the Federation Metadata XML, which bundles the entity ID, endpoints, and the signing cert into one file. On the Entra side the ZPA app's Identifier is https://samlsp.private.zscaler.com/auth/metadata and the Sign-on URL follows https://samlsp.private.zscaler.com/auth/login?domain=<your-domain>.

On the Zscaler side you work in the ZPA Admin Console (admin.private.zscaler.com): Administration → IdP Configuration → Add IdP Configuration. Upload the metadata XML, leave Single Sign-On = User, pick your Domains, and Save. ZPA reads the metadata and fills the rest automatically.

Why SAML alone isn't enough for ZPA: SCIM

ZPA access policies are almost always written against groups ("SOC-Analysts get the jump-box"). SAML proves who the user is at login, but it doesn't reliably pre-load group membership. That's SCIM's job. In the same ZPA IdP wizard, scroll to Enable SCIM Sync, click Generate New Token, and copy the Bearer Token plus the SCIM Service Provider Endpoint. Paste both into Entra's Provisioning tab (Tenant URL + Secret Token) and hit Test Connection.

Want to prove the assertion carries the right identity and audience, instead of trusting the GUI? Capture the SAMLResponse with a SAML-tracer add-on, then decode it:

echo "$SAML_RESPONSE_B64" | base64 -d | xmllint --format - | grep -E "Audience|NameID"

<saml:Audience>https://samlsp.private.zscaler.com/auth/metadata</saml:Audience>
<saml:NameID Format="...emailAddress">karthik.r@wipro.com</saml:NameID>

If Audience doesn't match the SP's Entity ID exactly, the SP rejects the assertion — that's an audience mismatch. If NameID is blank or carries the wrong attribute, the SP can't map the user. Reading the assertion beats guessing at the config screen every time.

④ Admin SSO + the five failures that break logins

Letting admins log into the Zscaler portal with Entra is a separate integration — a different gallery app (…Administrator), a different Reply URL, and one critical difference: no Just-in-Time provisioning.

For ZIA admin SSO the Entra app Zscaler Internet Access Administrator uses Identifier https://admin.zscalertwo.net and Reply URL (ACS) https://admin.zscalertwo.net/adminsso.do, with the claim memberOf = user.assignedroles. On the ZIA side you enable it at Administration → Administrator Management → Enable SAML Authentication, upload the Public SSL Certificate, optionally set an Issuer, Save, and Activate. ZPA admin SSO can run IdP-initiated, using Relay State idpadminsso.

The five failures, with the symptom you'll actually see

• 1 · AADSTS50105 — symptom: "not assigned to a role for the application." Fix: assign the user/group to the enterprise app in Entra (per-app assignment is on by default).
• 2 · Wrong cert format — symptom: ZIA upload fails, or every login throws "SAML Authentication Failed." Fix: ZIA needs Base64 .pem; ZPA needs metadata XML. Don't cross them.
• 3 · NameID misread — symptom: users log in but show as the wrong identity, or auto-provisioning creates junk accounts. Fix: ZIA "Login Name Attribute" must be exactly NameID.
• 4 · Audience mismatch — symptom: SP rejects the assertion outright. Fix: the assertion's Audience must equal the SP Entity ID character-for-character.
• 5 · Cert rotation — symptom: logins that worked for years all fail on the same morning. Fix: the Entra signing cert rolled (3-year default); re-upload the new .pem to ZIA (ZPA's metadata bundles it, so re-importing one file is simpler).

Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgAuditLogSignIn -Filter "appDisplayName eq 'Zscaler Internet Access ZSTwo'" -Top 3 |
  Select-Object userPrincipalName, @{n='result';e={$_.Status.ErrorCode}}, ipAddress, createdDateTime

userPrincipalName        result  ipAddress       createdDateTime
priya.sharma@infosys.com      0  203.0.113.24    2026-06-04T08:41:10Z
karthik.r@wipro.com           0  203.0.113.51    2026-06-04T08:39:02Z

A result of 0 means success. A non-zero code such as 50105 tells you exactly which failure you hit — assignment, in that case. The log is the truth; the config screen is only your intent.