2.2 SAML 2.0 Authentication & User Enrollment

2.2 SAML 2.0 Authentication & User Enrollment

Quick Summary: Security Assertion Markup Language (SAML) 2.0 is the industry-standard XML framework used by Zscaler to federate authentication with external enterprise directories. In this architecture, Zscaler acts as the Service Provider (SP), while the enterprise directory (e.g., Microsoft Entra ID, Okta, PingFederate) acts as the Identity Provider (IdP). When users enroll through Zscaler Client Connector (ZCC), SAML 2.0 securely passes authentication assertions, group memberships, and department affiliations to Zscaler without exposing user passwords to the cloud security platform.

---

SAML 2.0 Protocol Deep Dive: SP vs. IdP Roles

SAML 2.0 establishes a cryptographic trust relationship between two primary entities through the exchange of public X.509 certificates and standardized XML metadata:

1. Identity Provider (IdP): The authoritative identity store that authenticates the user (via passwords, FIDO2 keys, biometrics, or MFA) and issues digitally signed XML assertions containing identity claims.
2. Service Provider (SP): The relying party (ZIA or ZPA) that consumes the SAML assertion, verifies its cryptographic signature against the IdP's public certificate, and grants access to protected resources.
3. User Agent: The client interface (embedded WebView in Zscaler Client Connector or a standard web browser) that relays messages between the SP and IdP.

                 ┌────────────────────────────────────────────────────────┐
                 │                   Identity Provider                    │
                 │             (Entra ID / Okta / PingFed)                │
                 └──────────────▲──────────────────────────┬──────────────┘
                                │                          │
              3. AuthnRequest   │                          │ 5. Signed SAMLResponse
                 (Redirect)     │                          │    (NameID, Groups)
                                │                          │
                 ┌──────────────┴──────────────────────────▼──────────────┐
                 │            User Agent / Zscaler Client Connector       │
                 └──────────────▲──────────────────────────┬──────────────┘
                                │                          │
              1. Access Attempt │                          │ 6. POST Assertion
                 (Unauth)       │                          │    to ACS URL
                                │                          │
                 ┌──────────────┴──────────────────────────▼──────────────┐
                 │               Zscaler Service Provider                 │
                 │                      (ZIA / ZPA)                       │
                 └────────────────────────────────────────────────────────┘

SP-Initiated vs. IdP-Initiated Authentication Flows

[!IMPORTANT] ZCC SP-Initiated Requirement: Zscaler Client Connector enrollment always relies on an SP-initiated flow. During enrollment, ZCC injects device parameters and query parameters into the SP-initiated authentication request to bind the device to the user's session.

---

Metadata Exchange & Cryptographic Verification

To establish federation between Zscaler and an IdP, administrators must exchange SAML metadata configuration parameters:

1. Zscaler Service Provider (SP) Metadata

• SP Entity ID / Issuer URI: Unique identifier representing the Zscaler tenant. For ZIA, this is typically formatted as https://samlr.<zscaler_cloud>.net (e.g., https://samlr.zscalerthree.net or https://samlr.zscloud.net). For ZPA, this is a dedicated cloud tenant URI.
• Assertion Consumer Service (ACS) URL: The Zscaler endpoint that receives and processes the HTTP-POST containing the signed SAML assertion. (e.g., https://login.<zscaler_cloud>.net/sfc_aml for ZIA, or https://samlsp.private.zscaler.com/zpa/services/auth/saml/callback for ZPA).
• SP Signing Certificate (Optional): Used when the IdP requires digitally signed AuthnRequest messages from Zscaler.

2. Identity Provider (IdP) Metadata

• IdP Entity ID / Issuer: The IdP's unique identifier (e.g., https://sts.windows.net/<tenant-uuid>/).
• Single Sign-On (SSO) URL: The IdP HTTP endpoint where Zscaler redirects unauthenticated users (e.g., https://login.microsoftonline.com/<tenant-uuid>/saml2).
• X.509 Public Certificate: The cryptographic public key used by Zscaler to validate that the SAML assertion was signed by the legitimate IdP private key and has not been altered in transit.

SAML Attributes & Required Claims Mapping

When the IdP releases the SAML Assertion, it includes an <AttributeStatement> containing user metadata. Zscaler parses specific claim names:

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
  <saml:Issuer>https://sts.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47/</saml:Issuer>
  <saml:Subject>
    <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">alex.rivera@corp.com</saml:NameID>
  </saml:Subject>
  <saml:AttributeStatement>
    <saml:Attribute Name="displayName"><saml:AttributeValue>Alex Rivera</saml:AttributeValue></saml:Attribute>
    <saml:Attribute Name="department"><saml:AttributeValue>Information Technology</saml:AttributeValue></saml:Attribute>
    <saml:Attribute Name="memberOf">
      <saml:AttributeValue>CN=Cloud-Admins,OU=Groups,DC=corp,DC=com</saml:AttributeValue>
      <saml:AttributeValue>CN=DevOps,OU=Groups,DC=corp,DC=com</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

---

User Enrollment Workflow with Zscaler Client Connector (ZCC)

Zscaler Client Connector (ZCC) is the unified endpoint agent for Windows, macOS, iOS, Android, and Linux. The user enrollment process establishes mutual trust between the endpoint, ZCC, the IdP, and the Zscaler Cloud.

[ Step 1: User Enters Email ] ──> [ Step 2: Cloud Lookup ] ──> [ Step 3: IdP SSO & MFA ]
                                                                          │
[ Step 6: Tunnel Active ] <── [ Step 5: Profile Download ] <── [ Step 4: Token Exchange ]

Step-by-Step Enrollment Sequence:

1. User Initiation: The user launches ZCC and enters their corporate email address (or the deployment script passes the user domain via CLI arguments /userDomain or /cloudName).
2. Cloud Redirection: ZCC queries the Zscaler Central Authority, identifies the tenant's cloud instance (e.g., zscalerthree.net), and retrieves the assigned IdP SSO endpoint.
3. Embedded Web Authentication: ZCC opens an embedded secure browser WebView and directs the user to the IdP's SSO URL. The user performs interactive authentication, including Multi-Factor Authentication (MFA), passwordless authentication, or device posture verification (e.g., Windows Hello, Entra Conditional Access).
4. Assertion Evaluation & Token Issuance: The IdP issues the signed SAML assertion back to ZCC via the ACS URL. Zscaler validates the assertion signature against the IdP's uploaded X.509 certificate and issues a User Token and a Device Registration Record.
5. Policy Profile Download: ZCC connects to the Mobile Admin portal, downloads its assigned App Profile and Forwarding Profile, and receives cryptographic keys for tunnel establishment.
6. Tunnel Establishment: ZCC establishes secure micro-tunnels (Z-Tunnel 1.0 or Z-Tunnel 2.0 for ZIA, and on-demand TLS/DTLS micro-tunnels for ZPA).

Silent and Seamless Deployment Options

For enterprise mass-rollouts via MDM/UEM (Microsoft Intune, Jamf, SCCM), ZCC supports zero-touch silent enrollment:

• Integrated Windows Authentication (IWA) / Kerberos: Endpoints authenticate transparently using domain Kerberos tokens.
• Entra ID Seamless SSO: Domain-joined or Entra-hybrid-joined machines acquire SAML tokens without interactive credential prompts.
• Enrollment Device Token / Provisioning Keys: An administrator-generated deployment token is packaged into the installer MSI/PKG (HIDEAPPUI=1, USERDOMAIN=corp.com, STRICTENFORCEMENT=1), allowing ZCC to provision the device before user interactive login.

---

Re-Authentication Policies and Session Lifetimes

To balance zero-trust security compliance with end-user productivity, Zscaler provides granular session lifetime and re-authentication controls across both ZIA and ZPA.

ZIA Authentication Frequency

Administrators configure how frequently web users must re-authenticate against the IdP:

• Options: Never, Daily, Weekly, Monthly, or Custom Time Range (e.g., every 12 hours).
• Behavior: When the timer expires, ZIA intercepts the user's next HTTP/HTTPS web request and triggers an SP-initiated SAML re-authentication redirect. If the user possesses an active IdP session cookie in their browser, authentication completes transparently in the background without user prompts.

ZPA Re-Authentication Policies

In ZPA, re-authentication is evaluated per Application Segment within Access Policy rules:

• Granular Policy Control: Low-risk internal applications (e.g., intranet portals) can have a session timeout of 7 days, whereas critical production infrastructure (e.g., SSH jump boxes, AWS management consoles) can require re-authentication every 60 minutes or enforce Step-Up MFA.
• Session Invalidation: If a user fails posture re-assessment or exceeds the re-authentication interval, existing data micro-tunnels to that specific application segment are terminated immediately without affecting other active application streams.

ZPA Re-Authentication Model:
   User Session Active
     ├── Intranet App Segment ──────> Re-Auth Timeout: 7 Days (Low friction)
     ├── HR Portal App Segment ─────> Re-Auth Timeout: 24 Hours (Standard)
     └── Prod Database App Segment ─> Re-Auth Timeout: 1 Hour + Step-Up MFA (High Security)

---

Exam Traps & Real-World Best Practices

[!WARNING] Exam Trap (Certificate Expiration Outages): An expired IdP public X.509 certificate in the Zscaler admin portal will cause an immediate and catastrophic global authentication outage for all enrolling and re-authenticating users. Zscaler validates the signature of every incoming SAML assertion against this certificate. Administrators must monitor certificate expiration dates and perform certificate rotation in the Zscaler portal prior to switching the active signing certificate in the IdP.

[!IMPORTANT] Real-World Practice (Clock Skew Tolerance): SAML assertions contain NotBefore and NotOnOrAfter timestamps. If the clock on the enterprise IdP drifts by more than a few minutes from standard UTC time, Zscaler will reject the assertion as either expired or not yet valid. Ensure all IdPs synchronize with reliable NTP time sources.