Chapter 8: Identity, Policy, and Unified Management

Learning Objectives

Pre-Reading Check — Identity Integration

1. What core question does SAML answer that SCIM does not?

Which users and groups exist ahead of any login Who is logging in right now, at runtime How much data a user has transferred Which SaaS apps are unsanctioned

2. In the Okta group-push pitfall, what silently breaks group sync into Secure Access?

Okta sends PUT while Secure Access requires PATCH Okta sends PATCH while Secure Access requires PUT The SAML certificate has expired The clock skew exceeds the allowed window

3. When Duo SSO acts as an IdP proxy, what does it insert into an existing SAML chain?

A new primary directory SCIM provisioning MFA before federating to the backend IdP A storage bucket for logs

4. How does a Cisco ISE Security Group Tag (SGT) reach the Secure Access policy engine?

Via SAML assertion attributes only Via pxGrid Cloud consumed by Secure Access By manual CSV import exclusively Through the Amazon S3 export path

5. What does Cisco Identity Intelligence (CII) add to the identity plane?

Static, one-time group memberships Dynamic trust/risk levels usable as adaptive policy conditions A replacement for the primary IdP Long-term log archival

1. Identity Integration

The foundational idea in Cisco Secure Access is that identity is not handled separately per service. Cisco maintains a shared identity plane in Cisco Security Cloud Control, enriched by Cisco Identity Intelligence (CII), and every enforcement surface — SWG, CASB, ZTNA, DNS security, VPNaaS — references that same identity context. Think of a company badge: one badge, and each door reads the same badge and applies its own rule.

Key Points

SAML vs. SCIM

SAML delivers attributes at sign-in; that is fine for authenticating a session but fragile as the sole basis for group-based policy (SAML group claims hit size limits, struggle with nested groups, and reflect only the moment of login). SCIM continuously provisions user lifecycle events (create, update, disable), group memberships, and attributes into Cloud Control — so access can be revoked the moment a user is disabled in Entra ID, not at their next login.

SCIM provisions ahead of time; SAML authenticates at runtime
Two protocols, two questions. SCIM keeps the directory current before anyone logs in; SAML resolves who is signing in at the moment.
IdP Cloud Control User Policy Engine PROVISION SCIM PATCH: create/update + groups directory synced AUTH sign-in request SAML assertion (UPN, groups) present assertion resolved identity + groups → decision

Figure 8.1: SAML runtime authentication versus SCIM ahead-of-time provisioning

sequenceDiagram participant IdP as "Identity Provider (Entra/Okta/Duo)" participant SCIM as "SCIM Provisioning" participant CC as "Cisco Security Cloud Control" participant User as "User Browser/Client" participant SA as "Secure Access Policy Engine" Note over IdP,CC: Provisioning (continuous, before login) IdP->>SCIM: Push create/update/disable + group membership (PATCH) SCIM->>CC: Sync users, groups, attributes Note over CC: Identity directory kept current independent of any login Note over User,SA: Authentication (at runtime) User->>IdP: Sign-in request IdP->>User: SAML assertion (UPN/email, groups, attributes) User->>CC: Present SAML assertion CC->>CC: Normalize into unified identity model CC->>SA: Resolved identity + groups + attributes SA->>User: Policy decision applied

Duo MFA and Device Trust

Duo SSO can authenticate against Duo's own database, on-prem Active Directory, or another SSO IdP. As a proxy, the flow is: Secure Access sends a SAML AuthnRequest to Duo → Duo performs MFA → Duo federates to the backend IdP for primary auth → Duo returns a SAML assertion to Secure Access. Risk-based conditions decide when a step-up is warranted (compliant/known → SSO; new device → MFA; non-compliant → deny). Device trust adds posture checks (OS version, EDR/AV presence, disk encryption, jailbreak/root) before ZTNA access — which is why "I passed MFA but still can't reach the app" is usually a posture problem, not an authentication one.

Figure 8.2: Duo SSO as an IdP proxy inserting MFA into an existing SAML chain

sequenceDiagram participant SA as "Secure Access" participant Duo as "Duo SSO (IdP proxy)" participant User as "User" participant Backend as "Backend IdP (ADFS/Entra/Okta)" SA->>Duo: SAML AuthnRequest Duo->>User: MFA challenge (push / passcode) User->>Duo: MFA response Duo->>Backend: Federate for primary authentication Backend->>Duo: Primary auth result + identity/groups Duo->>SA: SAML assertion (identity + group information)

User and Group-Based Policy

Once identity is integrated, its attributes become the raw material for policy: User ID (UPN/email), Groups (via SCIM and SAML), Roles/labels, ISE-derived SGTs, and CII trust/risk levels. Because every service references the same identity objects, one group definition drives coherent behavior everywhere.

ServiceRule for "Finance-Users"
SWGAllow financial-category sites; block gambling/social; log high-risk categories
CASBFull access to approved finance SaaS; block shadow-IT finance apps; enforce DLP
ZTNAAllow internal ERP; deny HR systems; reauth if CII trust drops below medium
DNSBlock newly registered / known-malicious domains; allow finance domains
IdPSAMLSCIMNotes
Microsoft Entra IDYesYesTwo-step: Entra SCIM (token + URL) and Entra SAML (SSO)
OktaYesYesMust use a template that sends PATCH for group membership
Ping (PingOne/PingFederate)Yes—SAMLv2-compliant
Active DirectoryIndirectIndirectReaches Secure Access via ADFS, Duo SSO, or Cisco ISE
Post-Reading Check — Identity Integration

1. What core question does SAML answer that SCIM does not?

Which users and groups exist ahead of any login Who is logging in right now, at runtime How much data a user has transferred Which SaaS apps are unsanctioned

2. In the Okta group-push pitfall, what silently breaks group sync into Secure Access?

Okta sends PUT while Secure Access requires PATCH Okta sends PATCH while Secure Access requires PUT The SAML certificate has expired The clock skew exceeds the allowed window

3. When Duo SSO acts as an IdP proxy, what does it insert into an existing SAML chain?

A new primary directory SCIM provisioning MFA before federating to the backend IdP A storage bucket for logs

4. How does a Cisco ISE Security Group Tag (SGT) reach the Secure Access policy engine?

Via SAML assertion attributes only Via pxGrid Cloud consumed by Secure Access By manual CSV import exclusively Through the Amazon S3 export path

5. What does Cisco Identity Intelligence (CII) add to the identity plane?

Static, one-time group memberships Dynamic trust/risk levels usable as adaptive policy conditions A replacement for the primary IdP Long-term log archival
Pre-Reading Check — Unified Policy Engine

1. What is the architectural heart of the unified policy engine?

Each service maintains its own separate identity configuration The same identity objects are referenced across every enforcement surface Rules are evaluated in random order Policy is enforced only at the DNS layer

2. A policy rule pairs conditions with an action. Which four dimensions do conditions span?

Identity, Device, Application, Network Latency, Jitter, Loss, Throughput Overview, Insights, Search, Export SAML, SCIM, RADIUS, pxGrid

3. What is the correct order of the six-step policy-evaluation flow?

Enforce → evaluate → classify → enrich → resolve → authenticate Authenticate → resolve → enrich → classify → evaluate → enforce Classify → authenticate → enforce → resolve → enrich → evaluate Resolve → authenticate → classify → enforce → enrich → evaluate

4. A user authenticates successfully but matches no group-based rule. What is the most common cause?

The Overview dashboard is disabled Inconsistent user identifier (email vs. UPN) across IdP/ISE/Secure Access ThousandEyes synthetic tests are failing The S3 bucket policy is too restrictive

5. In the worked contractor example, what makes the SGT so powerful?

It only applies to the DNS surface A network-layer tag becomes a unified identity attribute used across all surfaces It replaces the need for any IdP It is generated fresh at each login by SAML

2. Unified Policy Engine

Cisco Secure Access exposes a centralized policy creation process that applies across its SSE and ZTNA services. Think of it as one policy engine with several enforcement surfaces bolted onto it, rather than several independent policy systems: SWG (web), CASB (SaaS), ZTNA (private apps), DNS security (queries), and VPNaaS (tunnels).

Key Points

Figure 8.3: One unified policy engine driving five enforcement surfaces from shared identity

graph TD ID["Normalized Identity Plane
(user, groups, SGT, CII trust, roles)"] --> ENGINE["Unified Policy Engine
(centralized rulesets)"] ENGINE --> SWG["SWG
HTTP/HTTPS web traffic"] ENGINE --> CASB["CASB
SaaS app APIs and sessions"] ENGINE --> ZTNA["ZTNA
private app segments"] ENGINE --> DNS["DNS Security
queries, domains, categories"] ENGINE --> VPN["VPNaaS
tunnel access and authorization"]
One identity, enforced five ways
A single normalized identity object radiates the same attributes to every enforcement surface — one group definition drives coherent behavior across SWG, CASB, ZTNA, DNS, and VPNaaS.
Identity user + groups + SGT + CII trust SWG CASB ZTNA DNS VPNaaS

Context and Posture in Policy Decisions

Identity by itself is often not enough. When ISE is integrated, Secure Access associates SGTs, posture compliance, and RADIUS attributes with a session (via pxGrid/RADIUS), enabling conditions like "SGT = HR" or "ISE posture = non-compliant." CII trust can be a first-class condition too: "if CII trust = low, require reauth or block ZTNA." In the contractor example, an AD group "Contractors" → ISE SGT "Contractor-SGT" → consumed by Secure Access via pxGrid drives every surface at once.

Policy Ordering and the Six-Step Flow

Rules are evaluated in order, top-down. For a typical request the engine proceeds through six stages: (1) authenticate at the IdP, (2) resolve identity in Cloud Control against the SCIM record, (3) enrich with ISE SGTs/posture, (4) classify the request (web/SaaS/private/DNS), (5) evaluate the ruleset (global → identity → trust-based), and (6) enforce at the corresponding surface and log with full context.

The six-step policy-evaluation pipeline, lighting up in sequence
Authenticate → Resolve → Enrich → Classify → Evaluate → Enforce. This same flow is also your troubleshooting map — most policy surprises trace to steps 1–3.
1. AuthenticateIdP + SAML/OIDC + MFA 2. Resolve Identitymatch SCIM, attach groups 3. Enrich ContextISE SGTs, posture, RADIUS 4. Classify Requestweb / SaaS / private / DNS 5. Evaluate Rulesetglobal → identity → trust 6. Enforceaction at surface + logs

Figure 8.4: The six-step policy-evaluation flow

flowchart TD A["1. User Authentication
redirect to IdP, SAML/OIDC + MFA"] --> B["2. Identity Resolution in Cloud Control
match SCIM record, attach groups, CII trust"] B --> C["3. Context Enrichment
ISE SGTs, posture, RADIUS attributes"] C --> D["4. Request Classification
web / SaaS / private app / DNS + destination"] D --> E["5. Ruleset Evaluation
global then identity then trust-based rules, top-down"] E --> F["6. Enforcement
action applied at surface + logs to SIEM/XDR"]

Because identity and policy are unified, logs from every surface carry consistent identity attributes (user, group, SGT, trust level) — precisely what makes troubleshooting and SIEM/XDR correlation tractable. Common failure modes: attribute-mapping mismatches (email vs. UPN), SAML cert/clock-skew errors, SCIM group-sync failures (PATCH vs. PUT), MFA not actually required by policy, and posture unexpectedly blocking access.

Post-Reading Check — Unified Policy Engine

1. What is the architectural heart of the unified policy engine?

Each service maintains its own separate identity configuration The same identity objects are referenced across every enforcement surface Rules are evaluated in random order Policy is enforced only at the DNS layer

2. A policy rule pairs conditions with an action. Which four dimensions do conditions span?

Identity, Device, Application, Network Latency, Jitter, Loss, Throughput Overview, Insights, Search, Export SAML, SCIM, RADIUS, pxGrid

3. What is the correct order of the six-step policy-evaluation flow?

Enforce → evaluate → classify → enrich → resolve → authenticate Authenticate → resolve → enrich → classify → evaluate → enforce Classify → authenticate → enforce → resolve → enrich → evaluate Resolve → authenticate → classify → enforce → enrich → evaluate

4. A user authenticates successfully but matches no group-based rule. What is the most common cause?

The Overview dashboard is disabled Inconsistent user identifier (email vs. UPN) across IdP/ISE/Secure Access ThousandEyes synthetic tests are failing The S3 bucket policy is too restrictive

5. In the worked contractor example, what makes the SGT so powerful?

It only applies to the DNS surface A network-layer tag becomes a unified identity attribute used across all surfaces It replaces the need for any IdP It is generated fresh at each login by SAML
Pre-Reading Check — Visibility and Operations

1. Which dashboard operates at the security-posture altitude, pulling from SWG/ZTNA, CII, DLP, and App Discovery?

Overview dashboard Security Insights dashboard Experience Insights Activity Search

2. Which tool is designed for event-by-event investigation (per-event log search)?

Overview dashboard Security Insights dashboard Activity Search ThousandEyes topology map

3. Which log-export path is best for near-real-time detection?

REST API polling Amazon S3 storage-bucket batch files Manual CSV import SAML assertions

4. A user complains that "secure access is slow." Which tool localizes the problem?

Activity Search Security Insights dashboard Experience Insights (ThousandEyes DEM) SCIM provisioning logs

5. Why does unified identity make cross-tool SIEM correlation tractable?

Logs from every surface carry consistent identity attributes All logs are stored only on the endpoint Each surface uses a different user identifier Retention is unlimited by default

3. Visibility and Operations

A policy engine you cannot observe is a policy engine you cannot trust. Secure Access is delivered through a single, cloud-managed console (Cisco Security Cloud Control) that unifies policy, client management, and aggregated reporting — so you correlate traffic, threats, policy decisions, and user activity in one place instead of stitching together separate consoles.

Key Points

Dashboards and Activity Search

The Overview dashboard shows high-level traffic and the amount of data transferred, surfacing top identities, destinations, and locations for quick anomaly spotting. The Security Insights dashboard operates at the posture altitude — policy effectiveness, identity risk (risky OAuth grants), and DLP posture — for review, not per-incident troubleshooting. For event-by-event work you move to Activity Search, which supports filtering by user/group/IP/app/destination/category/policy/action/time, pivoting from a dashboard widget, and CSV/JSON export. Its online logs have a finite retention window, so anything longer-term needs SIEM/S3 export.

Reporting and Log Export / SIEM

In-console dashboards are operational windows; for long-term retention, compliance, and cross-tool correlation you export logs externally. API-based SIEM integration exposes REST APIs that SIEMs (Splunk, QRadar, Elastic) poll and normalize — near-real-time with fine field control. Storage-bucket / S3 export streams JSON/CSV files (written every few minutes) for cheap long-term retention and data-lake analytics. A common split: push only security-critical events via API for live correlation, and send full logs to S3 for archival.

NeedBetter fit
Near-real-time detectionAPI (continuous polling)
Large-volume, long-term storageS3 / storage bucket
Minimal custom integrationVendor-provided SIEM app using the API
Flexible data-lake analyticsS3 + ETL stack

Figure 8.5: Two complementary log-export paths — REST API versus S3 storage bucket

graph TD SA["Secure Access Logs
web / DNS / ZTNA / DLP events"] --> API["REST API
near-real-time, polled"] SA --> S3["Storage Bucket / Amazon S3
batch files every few minutes"] API --> SIEM["SIEM (Splunk/QRadar/Elastic)
live correlation with EDR/NDR"] S3 --> LAKE["Data Lake / ETL
Spark, Databricks, BigQuery"] S3 --> ARCHIVE["Long-term Retention
compliance and audit"]

Experience Insights Monitoring

Security visibility answers "was this allowed or blocked?" — but users complain just as often about performance. Cisco ThousandEyes Experience Insights is embedded in the dashboard for end-to-end digital experience monitoring (DEM): endpoint performance (CPU, memory, Wi-Fi), network performance (segment-by-segment latency/jitter/packet-loss with remediations), cloud/app performance (synthetic tests when licensed), and a global endpoint topology map. Instead of chasing network, endpoint, and SaaS status pages separately, an admin selects the affected user/location and pinpoints whether the problem is the endpoint, local network, WAN, Secure Access, or the application — reducing MTTR and reclassifying many "security" tickets. Heuristic: "slow" → Experience Insights, "blocked" → Activity Search.

Post-Reading Check — Visibility and Operations

1. Which dashboard operates at the security-posture altitude, pulling from SWG/ZTNA, CII, DLP, and App Discovery?

Overview dashboard Security Insights dashboard Experience Insights Activity Search

2. Which tool is designed for event-by-event investigation (per-event log search)?

Overview dashboard Security Insights dashboard Activity Search ThousandEyes topology map

3. Which log-export path is best for near-real-time detection?

REST API polling Amazon S3 storage-bucket batch files Manual CSV import SAML assertions

4. A user complains that "secure access is slow." Which tool localizes the problem?

Activity Search Security Insights dashboard Experience Insights (ThousandEyes DEM) SCIM provisioning logs

5. Why does unified identity make cross-tool SIEM correlation tractable?

Logs from every surface carry consistent identity attributes All logs are stored only on the endpoint Each surface uses a different user identifier Retention is unlimited by default

Your Progress

Answer Explanations