2.4 Authentication Bridges, One-Time Tokens & Surrogate IP

2.4 Authentication Bridges, One-Time Tokens & Surrogate IP

Quick Summary: In modern enterprise environments, not all traffic originates from interactive browsers running on ZCC-managed endpoints. On-premises branch offices, explicit proxy legacy systems, background daemons, command-line developer tools, and external contractors require specialized authentication mechanisms. Zscaler incorporates Authentication Bridges, Kerberos / Integrated Windows Authentication (IWA), Surrogate IP, and One-Time Tokens (OTT) to guarantee transparent, secure, and policy-compliant authentication across every operational scenario.

---

Transparent Authentication on Corporate Networks: Kerberos & IWA

In corporate branch offices and headquarters where traffic is forwarded to ZIA via GRE or IPsec tunnels or Explicit PAC files, prompting users for web login credentials every time they launch an application creates friction.

To deliver zero-prompt transparent authentication for on-premises domain-joined machines:

[ Domain Client ] ──( 1. HTTP Request )──> [ ZIA Public Service Edge ]
        │                                            │
        │ <──( 2. HTTP 407 Proxy Auth Required )─────┘
        │     ( Negotiate / SPNEGO Header )
        │
        ├───( 3. Request Kerberos Ticket )──> [ On-Prem Active Directory KDC ]
        │ <──( 4. Issue Service Ticket )──────┘
        │
        └───( 5. Present Ticket with SPNEGO )──> [ ZIA Public Service Edge / Auth Bridge ]
                                                      ( Authenticated Session Established )

Authentication Bridge Deployment Architecture

When on-premises endpoints cannot directly communicate with external cloud IdPs or require Kerberos ticket validation without exposing internal Active Directory Key Distribution Centers (KDCs) to the public internet, enterprises deploy the Zscaler Authentication Bridge:

1. On-Premises Service: The Authentication Bridge runs as a lightweight virtual appliance inside the corporate DMZ.
2. SPNEGO / Kerberos Validation: It intercepts SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) tokens from corporate browsers, validates them against local domain controllers via Kerberos/NTLM, and returns signed identity assertions to the Zscaler Cloud.
3. Zero User Prompts: Users open their browsers and instantly access the web with their identity, department, and group policies fully enforced.

---

Surrogate IP Architecture & Mechanics in ZIA

While interactive web browsers can easily follow HTTP 302/407 authentication redirects and complete SAML/Kerberos handshakes, non-browser applications cannot:

• Background OS updates (Windows Update, macOS Software Update)
• Command-line utilities (curl, git, docker, pip, terraform)
• IoT devices, medical devices, and smart printers
• Legacy client-server business applications

To solve this challenge, ZIA provides Surrogate IP.

Surrogate IP Lifecycle on a Trusted Corporate Subnet:

1. Initial Browser Request ──( SAML / Kerberos Auth )──> ZIA Authenticates User (alex.rivera@corp.com)
                                                                 │
2. ZIA Maps Identity <───────────────────────────────────────────┘
   [ IP: 10.100.45.22 ] <=====> [ User: alex.rivera@corp.com | Dept: IT | Groups: Cloud-Admins ]

3. Non-Browser Traffic (CLI / git / curl / background daemons):
   [ 10.100.45.22 ] ──( Background Traffic )──> ZIA matches IP in Surrogate Table
                                                └──> Applies Alex's User/Dept/Group policies without prompting!

How Surrogate IP Operates:

1. Initial Authentication: A user at a corporate location (e.g., source IP 10.100.45.22) opens an interactive web browser. ZIA intercepts the request and executes SAML or Kerberos authentication.
2. Mapping Creation: Once authenticated, ZIA creates an internal Surrogate IP mapping in the Cloud Service Edge memory, binding 10.100.45.22 to the user's identity (alex.rivera@corp.com), department, and groups.
3. Transparent Proxying: For all subsequent requests originating from 10.100.45.22—including non-browser daemons and Cloud Firewall traffic—ZIA checks its Surrogate IP table. Because the IP is mapped, traffic is permitted and evaluated against Alex's user-level policies without triggering authentication prompts.
4. Surrogate Refresh & Expiration: The mapping persists until either the Idle Timeout or Maximum Lifetime expires.

Key Surrogate IP Configuration Parameters

The Multi-User Shared Host Warning (Terminal Services / RDS / Citrix)

[!CAUTION] Critical Architecture Rule: Surrogate IP MUST NEVER be enabled on multi-user shared IP systems such as Microsoft Remote Desktop Session Hosts (RDSH), Citrix XenApp, or shared terminal servers without the Zscaler Terminal Services (TS) Agent.

Why? On a terminal server, 50 different users share a single outbound IP address. If User A (an intern) logs in first, ZIA maps the server's IP to the Intern identity. When User B (the CFO) logs in 5 minutes later, all of the CFO's traffic will inherit the Intern's security policies and audit logs!

In multi-user environments, administrators must either deploy Zscaler Client Connector in Virtual Desktop mode or install the Zscaler TS Agent, which inserts unique source port ranges per user session to distinguish concurrent users sharing a single IP.

---

One-Time Tokens (OTT) & Contractor / Vendor Onboarding

Third-party contractors, external auditors, and supply chain vendors frequently need temporary access to specific private enterprise applications without receiving managed corporate laptops or permanent Active Directory accounts.

ZPA addresses this through One-Time Tokens (OTT) and Browser Access (Clientless):

                               One-Time Token (OTT) Workflow
┌─────────────────┐       ┌─────────────────┐       ┌─────────────────┐       ┌─────────────────┐
│ 1. Admin Issues │ ────> │ 2. Contractor   │ ────> │ 3. ZPA Validates│ ────> │ 4. Secure 1:1   │
│    OTT Invite   │       │    Redeems Link │       │    Token & Auth │       │    Access Open  │
│ (ZPA Console)   │       │ (Browser Access)│       │ (Time-Bound)    │       │ (App Segment)   │
└─────────────────┘       └─────────────────┘       └─────────────────┘       └─────────────────┘

1. Token Generation: An administrator generates a time-limited One-Time Provisioning Key or invitation token within the ZPA admin portal, bounded by strict start/end timestamps and restricted to specific Application Segments (e.g., SAP ERP Web only).
2. Token Redemption: The contractor receives a secure invitation link via email or enterprise ticketing. Access is mediated through ZPA Browser Access, rendering the internal application securely inside standard HTML5 browsers over HTTPS without requiring ZCC installation.
3. Cryptographic Binding: Once redeemed, the token is invalidated or bound to the contractor's specific IdP session. When the contract period expires, access is revoked automatically without requiring manual Active Directory clean-up.

---

Machine Authentication & Headless IoT Devices

Enterprise zero trust architectures must accommodate non-interactive endpoints and pre-boot states:

1. Machine Authentication in ZCC (Machine Tunnels)

• Pre-Logon Connectivity: Before a user logs into Windows at the Ctrl+Alt+Del lock screen, ZCC establishes a Machine Tunnel using machine certificates (PKI/SCEP).
• Capabilities: Allows line-of-sight domain controller communication for password changes, Group Policy Object (GPO) updates, BitLocker key escrow, and remote management before user SAML authentication takes place.

2. Headless IoT and Operational Technology (OT)

• Devices such as badge readers, security cameras, HVAC controllers, and network printers cannot execute SAML handshakes or run ZCC agents.
• Architecture: Forwarded via GRE/IPsec tunnels mapped to dedicated Sublocations in ZIA where authentication is explicitly disabled (Enable Authentication = Unchecked).
• Security: Governed strictly by Cloud Firewall, Cloud IPS, and DNS filtering rules scoped to the IoT sublocation IP ranges.

---

Multi-Factor Authentication (MFA) Step-Up & Conditional Access

Zero Trust assumes that initial authentication at morning login does not guarantee continuous trust throughout the day. Zscaler integrates with enterprise IdP Conditional Access and Adaptive MFA engines to enforce dynamic Step-Up Authentication.

Step-Up MFA Workflow in ZPA:

1. Standard Context: A developer uses ZCC to access routine developer wikis and ticketing systems authenticated via standard primary credentials.
2. High-Value Trigger: The developer attempts to open an SSH session to a production payment-processing server defined in a high-security Application Segment.
3. Policy Interception: ZPA evaluates the Access Policy rule: Target Segment == Production-PCI -> Action == Require Step-Up Re-Authentication.
4. MFA Challenge: ZPA signals ZCC to launch an interactive IdP challenge. The user must approve a FIDO2 WebAuthn biometric prompt or push notification on their mobile authenticator.
5. Micro-Tunnel Authorization: Upon receiving the refreshed SAML assertion with the elevated Authentication Context Class Reference (authnContextClassRef), ZPA establishes the private micro-tunnel to the payment server.

Step-Up MFA Logic:
   User -> Low-Risk App (Jira / Wiki)      ──> Allowed (Base Session Token)
   User -> High-Risk App (PCI Production) ──> Intercepted by ZPA -> Step-Up MFA Challenge -> Micro-Tunnel Created

---

Authentication Architecture Comparison Matrix

---

Exam Traps & Real-World Best Practices

[!WARNING] Exam Trap (Surrogate IP on Guest Wi-Fi): Never enable Surrogate IP on a guest Wi-Fi network or dynamic public subnet where multiple transient users may rapidly receive the same recycled DHCP IP address. If User A leaves the office and User B receives User A's old IP address before the Idle Timeout expires, User B will browse under User A's identity and permissions.

[!IMPORTANT] Real-World Practice (CLI / Automation Tools): Developers using automated build agents, CI/CD runners, or CLI tools (curl, terraform) on corporate networks often fail authentication if explicit proxy authentication is enforced without Surrogate IP. Enabling Surrogate IP on build subnets or deploying ZCC with machine tunnel profiles eliminates 407 Proxy Authentication Required errors in developer workflows.