Back
Lesson 3 of 6

SAML Authentication for ZTA

Objective

Integrate a SAML Identity Provider (IdP) — such as Duo, Azure AD, or Okta — with a Secure Firewall Zero Trust Access (ZTA) deployment so web applications protected by ZTA use SAML-based single sign-on (SSO) and MFA. You will configure the necessary DNS behavior, pre-authentication flow, and validate the ZTA cookie and NAT/redirection to the high port used by ZTA.

Introduction

In this lesson we configure SAML authentication for Secure Firewall ZTA so that end users are redirected to a SAML IdP for pre-authentication and then receive a ZTA cookie allowing access to protected HTTPS applications. This matters in production because SAML + ZTA enables enterprise SSO and strong authentication (MFA) without exposing backend application servers directly to the internet. A common real-world scenario: corporate users access an internal web management console (hosted at 192.168.1.10:443) via the public hostname app.lab.nhprep.com; the firewall performs the SAML pre-auth redirect, issues a ZTA cookie, and then proxies the session while the backend remains private.

Quick Recap

Topology from Lesson 1 still applies; this lesson adds the SAML IdP and focuses on the HTTP(S) redirect/pre-auth flow. The only explicit backend IP from the reference material used in this lesson is 192.168.1.10 (the protected application). We will use the following FQDNs in examples for SAML and ZTA configuration: fmc.lab.nhprep.com, ise01.lab.nhprep.com, csdac.lab.nhprep.com, and app.lab.nhprep.com.

ASCII topology (simplified) — exact IP shown where available:

Client (User browser)

  • IP: 198.51.100.50

Public Internet

Secure Firewall (ZTA)

  • Public interface IP: 203.0.113.10
  • ZTA protected app external FQDN: app.lab.nhprep.com -> points to 203.0.113.10 (DNS)
  • Backend NAT target: 192.168.1.10:443 (application server)

SAML IdP (Azure/Okta/Duo)

  • IdP endpoint (example): idp.lab.nhprep.com -> 198.51.100.20

Protected App (backend)

  • IP: 192.168.1.10:443

Tip: DNS for app.lab.nhprep.com must resolve to the firewall's public interface so the ZTA pre-auth flow reaches the firewall first.

Device Table

DeviceRoleNotable IP / FQDN
ClientEnd user browser198.51.100.50
Secure Firewall (ZTA)Enforcement point, performs SAML redirect, cookie issuance, NAT to backend203.0.113.10 (public)
SAML IdPAzure AD / Okta / Duoidp.lab.nhprep.com (198.51.100.20)
Protected AppBackend HTTPS web server192.168.1.10:443 (app.lab.nhprep.com NAT target)

Key Concepts (theory + packet flow)

  • SAML Pre-auth Redirect: When a user requests the protected FQDN (app.lab.nhprep.com), the firewall intercepts the request and issues an HTTP redirect to the configured SAML IdP. This redirect is necessary to present an SAML login page for user authentication; the firewall uses the SAML assertion returned to decide whether to issue a ZTA cookie.
    • Production note: This allows enforcement of enterprise SSO and MFA without changing backend servers.
  • Zero Trust Cookie (cscozt_token): After successful SAML authentication the firewall sets a cookie (example name: cscozt_token) in the browser. Future requests present this cookie; the firewall verifies it and then performs a NAT proxy to the backend application. The cookie contains the authenticated session metadata and a lifetime (e.g., 1 day).
    • Protocol detail: The firewall will set HttpOnly and Secure attributes in the Set-Cookie header; Snort/inspection requires TLS decryption to validate the cookie.
  • High-Port NAT Redirect (20000+): To separate user-facing FQDNs from internal backend endpoints and to perform proxying, the firewall redirects valid cookie-bearing requests to a high TCP port (e.g., 20000+) on the firewall; the firewall then NATs/forwards to the backend IP/port (192.168.1.10:443).
  • TLS Decryption Requirement: ZTA requires TLS decryption to inspect the SAML response and validate the cookie. Without TLS decryption enabled for the application traffic, the firewall cannot verify the cookie and ZTA will fail.
    • Real-world impact: You must manage certificates and decryption policies in production; ensure legal and privacy implications are addressed.

Step-by-step configuration

We break the integration into logical steps: DNS, IdP registration metadata, ZTA application construct, TLS/decryption check, and verification. Each step shows commands/configuration snippets and verification commands/output.

Step 1: Configure DNS so the application FQDN points to the firewall

What we are doing: Ensure app.lab.nhprep.com resolves to the Secure Firewall public interface so web requests reach the firewall for pre-authentication. This is essential because ZTA relies on the firewall being the first-hop for the protected hostname.

! On your DNS server (example commands shown as generic host record creation)
! Create an A record: app.lab.nhprep.com -> 203.0.113.10
nsupdate -k /etc/rndc.key << EOF
update add app.lab.nhprep.com. 3600 A 203.0.113.10
send
EOF

What just happened: The DNS A record for app.lab.nhprep.com now points to the firewall's public IP (203.0.113.10). User browsers resolving app.lab.nhprep.com will contact the firewall, allowing the firewall to perform the SAML pre-auth redirect.

Real-world note: In production, DNS changes may take time to propagate due to TTL. Use a low TTL during testing.

Verify:

! From a client or test workstation:
nslookup app.lab.nhprep.com
Server:         198.51.100.2
Address:        198.51.100.2#53

Name:   app.lab.nhprep.com
Address: 203.0.113.10

Step 2: Register the SAML IdP and provide SP metadata to the IdP

What we are doing: Configure the SAML IdP (Azure AD, Okta, or Duo) settings so it recognizes the Secure Firewall as a Service Provider (SP). Exchange metadata so the IdP and firewall trust one another. This is required so the firewall accepts SAML assertions and the IdP accepts relay/ACS URLs.

! Example conceptual commands to export SP metadata from the firewall (GUI/REST typically)
! The actual firewall metadata file contains the ACS URL and entityID like:
! https://app.lab.nhprep.com/+CSCOE+/saml/sp/acs?tgname=DefaultZeroTrustGroup
show saml sp-metadata

What just happened: The Service Provider metadata includes the Assertion Consumer Service (ACS) URL and the entityID that you provide to the IdP. The IdP will use this information to POST the SAML assertion back to the firewall after the user authenticates.

Real-world note: Only SAML IdPs are supported. You must paste the firewall's SP metadata into the IdP configuration console and configure the correct ACS and Audience restriction values.

Verify:

! Verify IdP metadata was accepted (example show output)
show saml idp detail
IdP Entity ID: https://idp.lab.nhprep.com
Single Sign-On URL: https://idp.lab.nhprep.com/sso
Single Logout URL: https://idp.lab.nhprep.com/slo
Certificate Fingerprint: SHA256: ABCD...1234
Status: Enabled

Step 3: Configure the ZTA protected application and pre-auth settings

What we are doing: Create the ZTA application entry that maps the external FQDN to the internal backend (192.168.1.10:443). Configure pre-authentication so the firewall redirects unauthenticated requests to the IdP and issues the cscozt_token after successful SAML assertion.

! Conceptual firewall configuration commands for a ZTA application construct
configure terminal
 zta application app.lab.nhprep.com
  backend 192.168.1.10:443
  pre-auth saml idp idp.lab.nhprep.com
  cookie name cscozt_token lifetime 1d path / secure httponly
  redirect-high-port enable port-range 20000-20099
 exit
end

What just happened: The firewall now knows that requests for app.lab.nhprep.com should undergo SAML pre-auth. After successful authentication, the firewall will set the cscozt_token cookie (1 day) and redirect subsequent requests to a high port (20000-20099) for proxying to the backend 192.168.1.10:443.

Real-world note: TLS decryption must be enabled for this protected app; otherwise the firewall cannot validate the cookie in HTTPS traffic.

Verify:

! Confirm the application mapping and cookie settings
show zta application app.lab.nhprep.com
Application: app.lab.nhprep.com
 Backend: 192.168.1.10:443
 Pre-auth method: SAML (IdP: idp.lab.nhprep.com)
 Cookie: cscozt_token; lifetime 1 day; path=/; secure; HttpOnly
 Redirect high-port: enabled; range 20000-20099
Status: Active

Step 4: Ensure TLS decryption is enabled for the protected FQDN

What we are doing: Enable TLS decryption (man-in-the-middle) for the app so the firewall can inspect the SAML assertion and the cookie. This is mandatory for ZTA to validate the cscozt_token and ensure policy enforcement.

! Conceptual commands to enable decryption for the app FQDN
configure terminal
 decryption policy
  rule 10 match host app.lab.nhprep.com
  action decrypt
 exit
end

What just happened: The firewall will perform TLS interception for app.lab.nhprep.com traffic; this allows inspection of SAML assertions and cookie validation. Certificates presented to clients will be generated from the firewall's decryption certificate (ensure proper trust).

Warning: TLS decryption has legal and privacy implications. In production, ensure you have approvals and properly distribute your decryption CA certificate to clients.

Verify:

! Verify decryption rule is present
show decryption policy
Rule 10:
 Match: Host = app.lab.nhprep.com
 Action: Decrypt
 Status: Enabled

Step 5: Test the end-to-end SAML pre-auth flow and validate cookie/redirect

What we are doing: From a user browser, access https://app.lab.nhprep.com and observe the redirect to the IdP, the SAML assertion POST back to the firewall, the Set-Cookie response (cscozt_token), and the subsequent redirect to the high port (e.g., :20000). This demonstrates the full SAML/ZTA interaction.

! Use curl to simulate the browser behavior and show response headers
curl -I -L -k https://app.lab.nhprep.com
HTTP/1.1 302 Found
Location: https://idp.lab.nhprep.com/sso?SAMLRequest=...
Set-Cookie: (none yet, pre-auth)
! After user authenticates at IdP and IdP POSTs assertion to ACS, firewall responds:
HTTP/1.1 200 OK
Set-Cookie: cscozt_token=FB89EB2D4DF4C3BF5C0E8121F35166DE; expires=Fri, 15 Sep 2023 11:20:46 GMT; path=/; secure; HttpOnly
! Next request with cookie should be allowed and redirected to high port
curl -I -k --cookie "cscozt_token=FB89EB2D4DF4C3BF5C0E8121F35166DE" https://app.lab.nhprep.com
HTTP/1.1 307 Temporary Redirect
Location: https://app.lab.nhprep.com:20000/

What just happened: The initial GET triggered a 302 redirect to the IdP for SAML login. After successful SAML authentication the firewall returned a Set-Cookie header (cscozt_token). When the cookie-bearing request is made the firewall returns a 307 redirect to the high port (20000), which the client follows; the firewall then proxies/NATs to 192.168.1.10:443.

Real-world note: The cscozt_token value is a session token; protect it with secure and HttpOnly flags. Browser caching and cookie scoping (domain/path) are important for correct behavior.

Verify:

! Confirm NAT mapping and ZTA NAT construct
show nat detail
NAT Rules:
 Application: app.lab.nhprep.com
 Source - Origin: 0.0.0.0/0, Translated: 0.0.0.0/0
 Backend mapping: firewall:20000 -> 192.168.1.10:443
Status: Active

Verification Checklist

  • Check 1: DNS resolves the protected name to the firewall — verify with nslookup returning the firewall IP.
  • Check 2: SAML IdP accepts the SP metadata and posts assertions to the firewall’s ACS URL — verify with show saml idp detail and observe successful assertion POST in logs or via curl redirects.
  • Check 3: After SAML login the firewall issues the cscozt_token cookie and redirects cookie-bearing requests to a high port (20000+) — verify with HTTP header inspection (curl -I) showing Set-Cookie and 307 Location to :20000 and show nat detail showing backend mapping to 192.168.1.10:443.

Common Mistakes

SymptomCauseFix
No redirect to IdP; user sees backend directlyDNS for app.lab.nhprep.com points to backend or incorrect recordFix DNS so app.lab.nhprep.com A record points to firewall public IP (203.0.113.10)
After IdP login no cookie is setSP metadata mismatch or ACS URL incorrect on IdPRe-export firewall SP metadata and update IdP ACS/EntityID to the firewall values
Cookie present but access denied / no high-port redirectTLS decryption not enabled or cookie validation failsEnable TLS decryption for app.lab.nhprep.com and ensure firewall's decryption cert is trusted by clients
ZTA works intermittently across browsersCookie path/domain or SameSite issues, or clock skewVerify cookie domain/path scope (app.lab.nhprep.com /) and ensure system clocks are synchronized between firewall and IdP

Key Takeaways

  • SAML is required for ZTA pre-auth: the firewall redirects unauthenticated requests to a SAML IdP for user authentication, then issues a ZTA cookie (cscozt_token) for subsequent access.
  • DNS must point the protected FQDN to the firewall so the pre-auth flow occurs; without this, the firewall cannot enforce ZTA.
  • TLS decryption is mandatory for ZTA because the firewall needs to decrypt HTTPS to validate SAML assertions and the ZTA cookie — this has operational and privacy implications in production.
  • ZTA uses a high-port redirect (20000+) and internal NAT mapping (e.g., firewall high port -> 192.168.1.10:443) to proxy traffic without rewriting backend application headers.

Important: Always test SAML integration in a controlled environment and ensure your IdP configuration (ACS URL, entityID, certificate) exactly matches the firewall SP metadata.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security