SSO

5 minute read

SAML vs OIDC

The two federation protocols behind SSO:

  SAML OIDC
Era / format XML assertions (2005) JWT over OAuth 2.0 (2014)
Transport Browser redirects + POST Browser redirects + REST/JSON
Strength Mature enterprise ecosystem Mobile/SPA-friendly, simpler
Typical use Workforce SSO (PingFederate, ADFS, Entra) “Login with X”, new apps

“Federated” simply means outsourcing your login to a trusted central authority — the Identity Provider (IdP). Instead of every application (Google Cloud, Jira, ServiceNow, Workday) holding its own password, they trust one central login. Both SAML and OIDC deliver the same user experience; the difference is wire format and ecosystem.

Active Directory

Active Directory (AD)—developed by Microsoft—is a centralized directory service that stores, manages, and organizes information about network resources and identities across an enterprise.

It serves as the central “phonebook” and security backbone for an organization’s IT infrastructure, handling identity management, authentication, and access control.

Authentication: Verifies that users and systems are who they claim to be (primarily using protocols like Kerberos and NTLM)

Active Directory (DAVITA.Corp) functions as the primary authoritative source of identity

Single Source of Truth: On-premises and domain-joined workstations, network file drives, and internal tools authenticate directly against AD

Identity Aware Proxy IAP-based corporate authentication refers to using Google Cloud Identity-Aware Proxy (IAP) as a centralized, Zero-Trust authentication and authorization gateway to control access to corporate web applications, APIs, virtual machines, and databases without requiring a traditional VPN

Google Cloud Directory Sync (GCDS) is an enterprise utility provided by Google that enables one-way synchronization of identity data—such as users, security groups, and group memberships—from on-premises Microsoft Active Directory (AD) to Google Cloud Platform (GCP) and Google Workspace

GCDS executes under the svc_gcds service account, with privileged sync credentials secured in CyberArk

Once approved, membership is updated in AD and synchronized to Google Cloud on the next sync interval

User / Browser / Client 
       │
       ▼
 [ HTTPS / TCP Request ]
       │
       ▼
┌────────────────────────────────────────────────────────┐
│             Google Identity-Aware Proxy (IAP)          │
│                                                        │
│  1. Authentication: Redirects to Corporate IdP / SSO    │
│     (PingFederate / Google Account + MFA)              │
│                                                        │
│  2. Authorization: Evaluates Google Cloud IAM roles    │
│     (e.g., IAP-secured Web App User / Group checks)    │
└────────────────────────────────────────────────────────┘
       │ (Request permitted only if IAM checks pass)
       ▼
┌────────────────────────────────────────────────────────┐
│ Internal Application / Backend Service / VM            │
│ (Cloud Run, GKE, Compute Engine VM, Cloud SQL)         │
│                                                        │
│ Receives request with verified identity headers:       │
│ • X-Goog-Authenticated-User-Email                      │
│ • X-Goog-Authenticated-User-Id                         │
└────────────────────────────────────────────────────────┘

Request Interception: When a user accesses an internal service (e.g., an internal web application), the request hits the Google Cloud load balancer / IAP layer before reaching the backend
. Corporate SSO & MFA Challenge: If the user is unauthenticated, IAP redirects them to authenticate through the enterprise Identity Provider (e.g., corporate Google identity federated with PingFederate single sign-on and Multi-Factor Authentication)
. Context & Policy Verification: Once authenticated, IAP checks whether the user (or their synchronized Active Directory group) holds the required Google Cloud IAM permissions (such as roles/iap.httpsResourceAccessor or roles/iap.tunnelResourceAccessor)
. Header Injection: When access is granted, IAP injects cryptographically signed HTTP request headers (such as X-Goog-Authenticated-User-Email and X-Goog-Authenticated-User-Id) into the request forwarded to the backend
. The backend application can read these headers directly to identify the user without implementing separate login or session management code

No Public IPs Required Backend servers, databases, and containers remain entirely on private subnets with no public ingress
. VPN-Free Access Authorized teammates can securely access internal tools from managed devices without establishing a full-tunnel VPN
. Centralized Governance Permissions are managed centrally via IAM roles and synchronized AD groups rather than individual application user tables
.

Corporate User Google Cloud HTTPS LB Google Cloud IAP Corporate IdP (Ping / Entra) Backend Pod (GKE / Cloud Run) (Browser) (Edge Ingress) (Auth & Token Engine) (SSO & MFA) (Private VPC) │ │ │ │ │ │ 1. GET /dashboard │ │ │ │ ├───────────────────────────────>│ │ │ │ │ │ 2. Inspect session / cookies │ │ │ │ ├───────────────────────────────>│ │ │ │ │ │ │ │ │ │ 3. Unauthenticated (302 Redirect to IdP Auth URL) │ │ │<───────────────────────────────┴────────────────────────────────┤ │ │ │ │ │ │ 4. Authenticate via Corporate SSO & MFA (PingFederate / PingOne) │ │ ├───────────────────────────────────────────────────────────────────────────────────────────────────>│ │ │ │ │ │ 5. Valid Credentials & MFA -> Issue SAML/OIDC Token Callback │ │ │<───────────────────────────────────────────────────────────────────────────────────────────────────┤ │ │ │ │ │ │ 6. Exchange Token with IAP Callback URL │ │ │ ├────────────────────────────────────────────────────────────────>│ │ │ │ │ 7. Validate with Cloud IAM │ │ │ │ • Check AD Sync Groups │ │ │ │ • Check TPE Elevation │ │ │ 8. Set Encrypted Session Cookie │ │ │ │<────────────────────────────────────────────────────────────────┤ │ │ │ │ │ │ │ │ 9. GET /dashboard (with IAP session cookie: GCP_IAAP_AUTH_TOKEN)│ │ │ ├───────────────────────────────>│ │ │ │ │ │ 10. Verify Cookie & Sign JWT │ │ │ │ ├───────────────────────────────>│ │ │ │ │ │ │ │ │ │ │ 11. Forward Request with Injected Authenticated Headers: │ │ │ │ • X-Goog-Authenticated-User-Email │ │ │ │ • X-Goog-Authenticated-User-Id │ │ │ │ • X-Goog-IAP-JWT-Assertion │ │ │ ├─────────────────────────────────────────────────────────────────────>│ │ │ │ │ │ │ │ │ │ 12. Parse Headers & Apply Roles │ │ 13. HTTP 200 OK (Render Dashboard) │ │ (e.g., Viewer, Admin) │ │<────────────────────────────────────────────────────────────────┴──────────────────────────────────┴───────────────────────────────────┤

You open an app: You go to Google Cloud or an internal dashboard
. The app doesn’t ask for a password: It redirects (302 redirect) you to DaVita’s central login screen (PingFederate / SSO)
. You prove who you are once: You type your corporate password and approve your MFA prompt on your phone
. A digital “stamp of approval” is issued: The central login system confirms, “Yes, this is Nitin, and his login is valid,” and hands you a secure digital badge (a token)
. The app lets you in: The app checks the badge, sees that it came from the trusted central system, and lets you straight in—without ever needing or seeing your actual password

You may also enjoy