examlab .net The most efficient path to the most valuable certifications.
Support
In this note ≈ 18 min

Cloud Identity and SSO Federation

3,500 words · ≈ 18 min read ·

Master identity management and federation in Google Cloud. Learn to integrate external identity providers, manage GCDS, and implement Workforce Identity Federation for PSE-level security.

Do 20 practice questions → Free · No signup · PSE

Introduction to Cloud Identity and Federation

In the realm of the GCP Professional Cloud Security Engineer (PSE), identity is not just a username and password; it is the primary security perimeter. As organizations move away from traditional network-based security to a Zero Trust model, Cloud Identity and SSO Federation become the cornerstones of a robust security posture.

Managing thousands of users, ensuring seamless access through Single Sign-On (SSO), and synchronizing on-premises identities with the cloud are complex tasks that require a deep understanding of protocols like SAML 2.0 and OIDC. This topic explores how to build a unified identity management system that bridges the gap between your existing infrastructure and Google Cloud.

白話文解釋（Plain English Explanation）

To grasp the complexities of identity federation, let's use three analogies.

1. The Global Passport System (Identity Federation)

Imagine you are traveling between different countries (Services). Instead of getting a new local ID for every country you visit, you use your national Passport (External IdP). The country you visit trusts your home country's verification process. This is SAML/OIDC Federation. Google Cloud (the destination) trusts your Azure AD or Okta (the home country) to verify who you are.

2. The Master Key and Sub-Keys (Super Admin vs. Admin Roles)

Think of a large hotel. The Super Admin holds the "Grand Master Key" that can open every door and change the locks. Most staff members only have "Floor Master Keys" or "Room Keys" (Admin Roles). If the Grand Master Key is lost, the entire hotel is at risk. This highlights the importance of protecting Super Admin accounts with MFA and limiting their daily use.

3. The Synchronized Watch (Directory Sync)

Imagine a team of spies who need to coordinate their actions across different time zones. They all synchronize their watches to a central atomic clock. Google Cloud Directory Sync (GCDS) acts as that central clock, ensuring that your on-premises Active Directory and your Cloud Identity domain are always in sync regarding user status, group memberships, and credentials.

Managing Users and Groups in Cloud Identity

Cloud Identity is an Identity as a Service (IDaaS) solution that provides a centralized console for managing users, groups, and security settings.

User Lifecycle Management

For the PSE, understanding the lifecycle is critical:

  • Provisioning: Creating the user account and assigning initial roles.
  • Maintenance: Updating group memberships as roles change.
  • De-provisioning: Disabling access immediately when an employee leaves.

Cloud Identity is a standalone IDaaS solution that allows you to manage users and groups independently of Google Workspace. It provides the identity foundation for Google Cloud.

Group-Based Access Control

Assigning roles to individuals is a security anti-pattern at scale. Instead, the PSE should always use Google Groups.

  • Security Groups: Use the security label on groups to distinguish them from mailing lists.
  • Dynamic Groups: Automatically manage memberships based on user attributes (e.g., all users with department=security).

Configuring Google Cloud Directory Sync (GCDS)

GCDS is a one-way synchronization tool that replicates users, groups, and non-sensitive data from LDAP/Active Directory to Cloud Identity.

Architectural Considerations

GCDS does not "push" data; it reads from LDAP and "pushed" to Google via APIs.

  • Sync Direction: Always LDAP → Google Cloud.
  • Exclusion Rules: Critical for preventing GCDS from deleting cloud-only users (like Super Admins).
  • Rule-Based Mapping: Map LDAP attributes (e.g., mail) to Google usernames.

GCDS does not sync passwords. To enable seamless login with local passwords, you must implement SAML SSO or use Password Hash Sync (if using Azure AD).

SAML 2.0 and OIDC Federation

Federation allows users to authenticate with an external Identity Provider (IdP) like Okta, Azure AD, or Ping Identity.

The SAML Flow

  1. User attempts to access Google Cloud.
  2. Google redirects the user to the External IdP.
  3. IdP authenticates the user (MFA, password).
  4. IdP sends a signed SAML Assertion back to Google.
  5. Google validates the signature and grants access.

OIDC (OpenID Connect)

OIDC is a modern identity layer built on top of OAuth 2.0. It is increasingly used for modern applications and provides a more developer-friendly approach to federation.

Super Admin Management and MFA Best Practices

Super Admins have unrestricted access to the Cloud Identity/Workspace tenant.

Hardening Super Admin Accounts

  1. Minimum of Two: Always have at least two Super Admins for redundancy.
  2. Maximum of Three: Don't exceed three to five Super Admins to minimize risk.
  3. Dedicated Accounts: Super Admins should not have a daily-use email or "Editor" roles in projects.
  4. Physical Security Keys: FIDO2/U2F keys are the "Gold Standard" for Super Admin MFA.

If a Super Admin account is compromised, the attacker can bypass all IAM roles and project-level security. Never use "[email protected]" as a regular user account.

Workforce Identity Federation (2025/2026 Trend)

Traditional federation requires "Identity Mapping" (creating a user object in Cloud Identity for every external user). Workforce Identity Federation eliminates this requirement.

Key Benefits

  • No Sync Required: Users authenticate directly against your IdP.
  • Attribute Mapping: Map external attributes (e.g., groups: admin) directly to Google IAM roles.
  • Short-lived Credentials: Security is improved by using STS (Security Token Service) to exchange external tokens for Google access tokens.

Use Workforce Identity Federation when you have thousands of users in an external IdP and don't want the overhead of managing user objects in Cloud Identity.

Managing Administrative Roles and Privileges

Beyond Super Admin, Google Cloud provides granular administrative roles within the Admin Console.

  • User Management Admin: Can reset passwords and create users.
  • Groups Admin: Can manage group memberships.
  • Security Admin: Can manage MFA settings and security keys.

User Provisioning and De-provisioning Workflows

Automation is key to security.

  • SCIM (System for Cross-domain Identity Management): Use SCIM for real-time provisioning from IdPs like Okta or Azure AD.
  • Automated Suspension: Ensure that when a user is disabled in Active Directory, they are immediately suspended in Cloud Identity.

SSO for Hybrid Environments

In hybrid environments, users may need to access both on-premises resources and cloud services.

  • Shared Identity: Use the same email address as the primary identifier across both environments.
  • Seamless Transition: Implement Kerberos or Integrated Windows Authentication (IWA) so users don't have to re-enter passwords when on-net.

Domain-Wide Delegation

Domain-wide delegation allows a service account to "impersonate" any user in the domain to access their data (e.g., reading emails or calendar events).

Domain-wide delegation is extremely powerful and should be restricted to specific OAuth scopes. It is a frequent target for privilege escalation.

Troubleshooting Identity Synchronization

  1. GCDS Logs: Check for "Rule failed" or "API limit reached" errors.
  2. SAML Tracer: Use browser extensions to inspect SAML Assertions for missing attributes or incorrect signatures.
  3. Audit Logs: Monitor admin.google.com audit logs for unauthorized role changes.

CLI Commands for Identity Management

While much of Cloud Identity is managed via the UI, the gcloud and gam (third-party) tools are essential for PSEs.

Listing Users via gcloud

gcloud identity users list --customer-id="C12345"

Checking Group Memberships

gcloud identity groups memberships list --group-email="[email protected]"

The security label on a Google Group is used to signal that the group is intended for security/access control purposes, allowing for stricter auditing.

Security Best Practices for PSE

  1. Enforce MFA: Use "Security Key Only" for high-privilege accounts.
  2. Audit GCDS: Run GCDS in "Simulate Mode" before every live sync.
  3. Minimize Super Admins: Use granular admin roles whenever possible.
  4. Regular Access Reviews: Use the "Access Review" feature in Cloud Identity Premium to verify that users still need their privileges.

Troubleshooting Scenarios

Scenario: SAML Login Fails with "Invalid Signature"

Diagnosis: The public certificate uploaded to Google Cloud does not match the private key used by the IdP to sign the assertion. Fix: Re-export the certificate from the IdP and update the SSO settings in the Google Admin Console.

Scenario: GCDS is Deleting Valid Users

Diagnosis: The exclusion rules are not correctly configured to protect cloud-only users. Fix: Add a "Google User Exclusion Rule" based on an organization unit (OU) or a specific email prefix.

PSE Exam Scenarios

Scenario 1: Multi-IdP Strategy

"A company has acquired another firm using Okta, while the parent company uses Azure AD. How should you configure Google Cloud?" Answer: Configure both as External IdPs or use Workforce Identity Federation to bridge multiple providers.

Scenario 2: Super Admin Security

"Your organization's Super Admin was compromised. What is the first step?" Answer: Use a secondary Super Admin to reset the password, revoke all sessions, and rotate the MFA keys.

FAQ

Q1: Can I use Cloud Identity Free for the PSE exam requirements? A1: Yes, for many features, but some advanced security reporting and "Access Reviews" require Cloud Identity Premium.

Q2: What is the difference between Google Cloud Directory Sync (GCDS) and Password Hash Sync? A2: GCDS syncs the user object; Password Hash Sync (available via Azure AD Connect) syncs the password itself so Google can authenticate the user without a redirect.

Q3: Is Workforce Identity Federation the same as Workload Identity? A3: No. Workforce Identity is for human employees; Workload Identity is for applications and machines.

Summary Checklist

  • Understand the SAML 2.0 flow and how to troubleshoot it.
  • Know the limits and best practices for Super Admin accounts.
  • Be able to configure GCDS exclusion rules.
  • Explain the benefits of Workforce Identity Federation over traditional sync.
  • Distinguish between different Admin Console roles.

Official sources

More PSE topics