2.1 Identity in Zero Trust & Architecture

2.1 Identity in Zero Trust & Architecture

Architectural Premise: In legacy network architecture, physical or logical network location defines trust: connecting to an on-premises Ethernet jack or establishing a VPN tunnel places an endpoint on the corporate network with implicit Layer 3 IP routability. In the Zscaler Zero Trust Exchange (ZTE), identity is the immutable, primary perimeter. Zscaler never connects a user to a network; instead, it validates identity, verifies device posture, evaluates real-time risk, and brokers an isolated 1:1 application-layer micro-tunnel directly to authorized workloads.

---

The Identity-Centric Paradigm Shift in Zero Trust

Traditional enterprise security models relied upon static, perimeter-bound constructs:

• Source IP addresses and network subnets
• Ingress physical switch interfaces, VLANs, and VRFs
• Active Directory domain trust boundaries and Kerberos ticket passing across MPLS backbones

In modern hybrid and cloud-first enterprise environments, these network constructs fail completely. Source IP addresses are dynamically assigned by local DHCP servers, transformed by Carrier-Grade NAT (CGNAT) or cloud egress gateways, and shared among thousands of concurrent users across coffee shops, airports, home networks, and branch offices. A source IP address indicates where a packet emerged from, but reveals nothing about who generated it, what device was used, or whether the session is authorized.

Legacy Perimeter Model (Location-Based Implicit Trust):
[ User / Laptop ] ──( VPN Concentrator )──> [ Corporate Subnet 10.100.0.0/16 ] ──( Lateral Scan )──> [ All Servers Exposed ]

Zero Trust Exchange Model (Identity-Centric Microsegmentation):
[ User + Device Posture ] ──( Context Evaluation )──> [ Zscaler Zero Trust Exchange ] ──( 1:1 Broker )──> [ Explicit App Only ]

Core Tenets of Identity-First Security

1. Zero Implicit Network Trust: Network presence never confers access privileges. Connecting to a corporate headquarters LAN provides no greater implicit trust than connecting from an untrusted public Wi-Fi hotspot.
2. Context-Aware Policy Enforcement: User identity is evaluated in conjunction with real-time device posture (EDR status, disk encryption, OS patch level), client location, and threat intelligence before session authorization.
3. Decoupled Application Access: Users are connected directly to authorized applications via Layer 7 micro-tunnels, completely isolating the underlying corporate network and preventing lateral threat traversal.
4. Continuous Adaptive Verification: Identity is continuously re-assessed throughout active sessions rather than validated solely at initial login.

---

Zscaler Identity (ZIdentity) Architecture

Zscaler Identity (ZIdentity) operates as the centralized cloud identity fabric that unifies authentication, directory synchronization, and policy attribute mapping across the entire Zero Trust Exchange platform, including Zscaler Internet Access (ZIA), Zscaler Private Access (ZPA), and Zscaler Digital Experience (ZDX).

+-----------------------------------------------------------------------------------+
|                         ENTERPRISE IDENTITY PROVIDERS (IdPs)                      |
|  [ Microsoft Entra ID ]    [ Okta Universal Dir ]    [ PingFederate / PingOne ]   |
|  [ Google Workspace   ]    [ CyberArk Identity  ]    [ On-Prem Active Directory ] |
+-----------------------------------------+-----------------------------------------+
                                          | SAML 2.0 / SCIM 2.0 / OIDC / OAuth
                                          v
+-----------------------------------------------------------------------------------+
|                         ZSCALER IDENTITY (ZIdentity) FABRIC                       |
|    * Multi-IdP Domain Routing Table          * Unified Directory Mapping Engine   |
|    * Centralized SAML Token Validation       * User & Group Schema Normalization  |
+-----------------------------------------+-----------------------------------------+
                                          |
                 +------------------------+------------------------+
                 |                                                 |
                 v                                                 v
+---------------------------------+               +---------------------------------+
|   ZSCALER INTERNET ACCESS (ZIA) |               |   ZSCALER PRIVATE ACCESS (ZPA)  |
|  * User / Group / Dept Model    |               |  * Dynamic SAML Attribute Rules |
|  * URL Filtering & Cloud Apps   |               |  * Application Segments         |
|  * DLP & Cloud Sandbox Rules    |               |  * Microsegmentation Policies   |
+---------------------------------+               +---------------------------------+

Multi-IdP Support and Domain Routing Mechanics

Enterprises operating across multiple subsidiaries, executing Mergers & Acquisitions (M&A), or collaborating with third-party vendors frequently maintain heterogeneous identity directories. Rather than forcing costly directory consolidations or establishing fragile two-way Active Directory forest trusts, ZIdentity provides native multi-IdP federation.

When a user initiates authentication via Zscaler Client Connector (ZCC) or an explicit browser session:

1. Domain Extraction: Zscaler parses the domain suffix from the user's User Principal Name (UPN) or email address (e.g., extracting subsidiary-a.com from alex.rivera@subsidiary-a.com).
2. Routing Table Matching: The Central Authority queries the configured IdP routing table to match the extracted domain suffix against mapped Identity Providers.
3. IdP Redirection: The authentication request is dispatched to the corresponding IdP (e.g., Okta for Subsidiary A, Microsoft Entra ID for Corporate HQ).
4. Assertion Validation: Upon successful authentication, the specific IdP issues a signed SAML assertion. Zscaler validates the cryptographic signature using that specific IdP's uploaded public X.509 certificate.
5. Default IdP Fallback: If a user logs in with an unmapped or generic domain, Zscaler routes the request to the designated Default IdP to prevent unhandled authentication failures.

---

Data Modeling: Users, Groups, and Departments

Zscaler processes identity objects across two distinct administrative engines: ZIA (Secure Web Gateway/CASB) and ZPA (Zero Trust Network Access). While both leverage the same federated identity source, their internal data handling exhibits critical architectural distinctions.

ZIA Identity Modeling: Flat Namespace & Department Constraints

In ZIA, identity objects are strictly categorized into Users, Groups, and Departments:

• User: The unique principal, identified by their login name (UPN/email address).
• Groups: A user can belong to multiple groups simultaneously (e.g., All-Employees, Engineering, Cloud-Admins). Groups form the foundation for URL Filtering, Cloud App Control, DLP, and Bandwidth Management rules.
• Department: A user belongs to exactly one primary Department (e.g., Information Technology, Finance, Sales). In ZIA, Department is strictly single-valued. If an IdP sends an array of multiple department values, ZIA assigns the first recognized department or falls back to a default department.

ZIA Data Model Structure:
   Tenant (Company Cloud Instance)
     ├── Department: Engineering (Single-Valued per User)
     │     └── User: alex.rivera@corp.com
     └── Groups: [ "Engineers", "DevOps", "PCI-Operators", "US-West" ] (Multi-Valued)

ZPA Identity Modeling: Dynamic SAML Attribute Evaluation

In contrast to ZIA, ZPA does not enforce a rigid internal database schema of Users, Groups, and Departments. Instead, ZPA evaluates dynamic SAML and SCIM assertion attributes in real time:

• SAML Attributes: Any attribute released by the IdP (such as memberOf, jobTitle, costCenter, securityClearance, or country) can be directly referenced within ZPA Access Policies.
• Multi-Valued Attributes: ZPA natively evaluates multiple department strings or arbitrary organizational arrays without single-value restrictions.
• Boolean Logic Combinations: ZPA Access Policies support complex boolean conditions combining identity attributes, group memberships, and endpoint device posture profiles (e.g., User in Group DevOps AND SAML Attribute clearance == High AND Device Posture == CrowdStrike Falcon Running).

Comparison: ZIA vs. ZPA Identity Processing

---

Supported Enterprise Directory Integrations

Zscaler integrates with all standard-compliant identity platforms using open protocols (SAML 2.0, SCIM 2.0, and OIDC):

1. Microsoft Entra ID (formerly Azure Active Directory)

• Federation: SAML 2.0 Single Sign-On with direct integration into Microsoft Entra Conditional Access Policies.
• Provisioning: SCIM 2.0 enterprise application push synchronization.
• Advanced Capabilities: Windows Integrated Authentication / Seamless SSO, FIDO2 WebAuthn passwordless authentication, and Entra Hybrid Join device trust signals.

2. Okta Universal Directory

• Federation: SAML 2.0 / OIDC federation via official Zscaler Okta Application catalog integrations.
• Provisioning: Okta SCIM 2.0 automated lifecycle management (Joiners, Movers, Leavers).
• Advanced Capabilities: Okta FastPass, Okta Verify device posture signals, and dynamic contextual authorization.

3. PingFederate / PingOne

• Federation: Enterprise hybrid architectures bridging on-premises Active Directory Kerberos tokens to cloud SAML 2.0 assertions.
• Provisioning: Outbound SCIM connector for automated group synchronization.
• Use Case: High-security financial and government institutions utilizing on-premises Hardware Security Modules (HSMs) for token signing.

4. Google Workspace / Cloud Identity

• Federation: SAML 2.0 SSO utilizing Google Cloud Identity credentials.
• Provisioning: Automated user synchronization via Google Admin SCIM integrations.
• Use Case: Cloud-native organizations managing Chromebook and macOS device fleets.

5. On-Premises Active Directory (Hybrid Models)

• Federation: Active Directory Federation Services (ADFS) or identity bridge agents (Entra Cloud Sync, Okta AD Agent).
• Local Auth: Zscaler Authentication Bridge / Kerberos / IWA for transparent on-premises branch office traffic.

---

Practical Configuration Scenario: Multi-IdP M&A Integration

Scenario: GlobalTech Enterprises (globaltech.com) acquires BioHealth Corp (biohealth.org). GlobalTech utilizes Microsoft Entra ID, while BioHealth utilizes Okta Universal Directory. The CIO mandates immediate Zero Trust security enforcement across all BioHealth personnel without consolidating Active Directory forests or migrating mailboxes.

Implementation Steps in ZIdentity:

1. Configure IdP 1 (Corporate HQ):
   • Name: Entra-HQ-IdP
   • Entity ID: https://sts.windows.net/aaaabbbb-cccc-dddd-eeee-ffff00001111/
   • Mapped Domain Suffixes: globaltech.com, globaltech-eu.com
   • Flag: Default IdP = Checked
2. Configure IdP 2 (Acquired Subsidiary):
   • Name: Okta-BioHealth-IdP
   • Entity ID: http://www.okta.com/exk1234567890abcdef
   • Mapped Domain Suffixes: biohealth.org
   • Flag: Default IdP = Unchecked
3. Certificate Upload: Upload the independent public X.509 signing certificates for both Entra ID and Okta into their respective ZIdentity profiles.
4. ZCC Deployment: Deploy Zscaler Client Connector to BioHealth endpoints configured with the deployment parameter USERDOMAIN=biohealth.org.
5. Verification: When BioHealth users open ZCC, ZIdentity extracts biohealth.org, routes them to Okta for MFA authentication, validates the Okta assertion, and applies BioHealth-specific ZPA and ZIA policies.

---

Exam Traps & Real-World Best Practices

[!WARNING] Exam Trap (ZIA Department Single-Value Rule): In ZIA, a user cannot belong to multiple Departments. If an administrator configures an IdP attribute mapping sending an array ["Engineering", "DevOps", "Security"], ZIA will assign only the first department in the list (Engineering). Groups must be utilized whenever multi-category classification is required for policy enforcement.

[!IMPORTANT] Real-World Practice (Default IdP Routing): Always designate a reliable, primary Identity Provider as the Default IdP. If a contractor or acquired employee attempts to authenticate with an unmapped domain suffix (e.g., user@external-consulting.com), ZIdentity routes the request to the Default IdP rather than dropping the session with an unroutable domain error.