Cloud Identity, SSO and Workforce Identity Federation

What it is

Every person who uses Google Cloud needs an identity that Google trusts. That identity is either a Google account in Cloud Identity or Google Workspace, or an identity in an external identity provider (IdP) that Google trusts through Workforce Identity Federation. The engineer decides where the source of truth lives, how accounts are created, removed and signed in, and how admin accounts are protected.

How it works

Cloud Identity and Google Workspace

Cloud Identity (Free or Premium) is the identity service behind a Google Cloud organization; Google Workspace includes the same features plus apps such as Gmail. The users and groups held here are what you grant IAM roles to. Groups are the unit of access: people join and leave groups while the IAM policy stays the same.

Google Cloud Directory Sync

Google Cloud Directory Sync (GCDS) copies users, groups and group memberships from Active Directory or another LDAP server into Cloud Identity. It runs on a server you manage inside your own network.

Microsoft Entra ID and Okta can instead provision users and groups into Cloud Identity directly, with no GCDS server.

Single sign-on with a third-party IdP

With SSO, Google is the service provider and your IdP authenticates users, usually with SAML 2.0. You create an SSO profile in the Admin console and assign it to organizational units or groups.

Password rules and MFA then live in the IdP. GCDS and SSO usually work together: GCDS creates accounts, SSO signs them in.

Protecting the super administrator

A Cloud Identity super admin can do anything in the account, including changing SSO and resetting other admins. A super admin can also grant itself Organization Administrator in Google Cloud, so it belongs inside your security boundary.

• Use dedicated super admin accounts that are never used for daily work.
• Keep more than one, so one lost account does not lock you out, but keep the number small.
• Enforce security keys for 2-Step Verification and keep recovery details current.
• Delegate routine work with narrower admin roles, such as Groups Admin.
• Super admins sign in to the Admin console with their Google credentials, which lets them repair a broken SSO setup.

Automating the user lifecycle

Suspend first and delete later: suspension blocks sign-in at once but keeps data for transfer.

Administering accounts programmatically

Use the Admin SDK Directory API for users, groups and organizational units, and the Cloud Identity Groups API for groups. Assign the calling service account a narrow admin role, such as Groups Admin, instead of domain-wide delegation, which lets an app act as any user.

gcloud identity groups memberships add \
  --group-email=gcp-network-admins@example.com \
  --member-email=ana@example.com

Workforce Identity Federation

Workforce Identity Federation lets users of an external IdP use Google Cloud without copying their accounts into Cloud Identity. You create a workforce identity pool at organization level, add an OIDC or SAML 2.0 provider, and map IdP claims to Google attributes such as google.subject and google.groups.

gcloud iam workforce-pools create partner-pool \
  --organization=123456789012 --location=global \
  --display-name="Partner staff"

An attribute condition on the provider can reject tokens, for example from users outside an allowed group. Federated users sign in through a separate federated console, and not every product supports them, so check support before choosing it.

A worked example

A bank keeps staff in on-premises Active Directory and contractors in a partner's Okta tenant. Staff need the console, Google Workspace and every Google Cloud service.

Staff get GCDS plus a SAML SSO profile pointing to AD FS. Contractors get a workforce pool with the partner's OIDC provider, limited to one group, with roles on a single project.

How the exam asks about this

• "Synchronize on-premises Active Directory users and groups to Google Cloud without modifying Active Directory." GCDS, which is one way from LDAP to Google.
• "Users must sign in with corporate credentials, and MFA must be enforced by the existing IdP." A SAML SSO profile in Cloud Identity pointing to that IdP.
• "Give a partner's employees access to a project without creating Google accounts for them." Workforce Identity Federation with a pool and provider for the partner IdP.