Topic 2 of 5
Cloud Identity and Workforce Identity Federation
IAM decides what each identity can do, but those identities have to come from somewhere. Google Cloud offers two paths: manage the accounts in Cloud Identity (by hand or synced from another directory) or federate the ones in an external IdP without creating Google accounts. The exam guide asks you to manage users and groups, manually and automated, and to configure Workforce Identity Federation.
Contents
- What is Cloud Identity?
- Cloud Identity Free and Premium
- Managing users manually
- Group types
- Automating: GCDS and provisioning
- Authoritative source and IdP
- Workforce Identity Federation
- Workforce identity pools and providers
- Attribute mappings and conditions
- Principal identifiers in IAM
- Exam scenarios
- Common exam traps
What is Cloud Identity?
An Identity as a Service (IDaaS) solution that centrally manages users and groups and can federate identities with other IdPs, such as Active Directory or Microsoft Entra ID.
The problem it solves: if developers use personal accounts, such as Gmail, those accounts sit outside the company's control. With Cloud Identity you create an account for each user and group in the domain, then use IAM to give them access to resources. A Cloud Identity or Google Workspace account is a private directory of users and groups; creating one automatically creates a Google Cloud organization with the same name.
Except for service accounts, the Google Cloud organization doesn't manage users or groups. That is the difference from an Entra ID tenant, which does act as a container for users.
Cloud Identity Free and Premium
You don't need Premium to use Google Cloud. Google Cloud customers can request additional Cloud Identity licenses at no cost.
| Free | Premium | |
|---|---|---|
| Who it is for | Core identity and endpoint management for users who don't need Gmail or Calendar | Enterprise security, application management, and advanced device management |
| Organizational units and groups | Unlimited | Unlimited |
| Google Cloud Directory Sync | Yes | Yes |
| 2-Step Verification | Yes | Yes |
| Secure LDAP, Context-Aware Access | No | Yes |
| Support and SLA | Community | 24x7 chat and email, 99.9% SLA |
Managing users manually
Users and groups are managed in the Google Admin console (Menu → Directory → Users), not in the Google Cloud console. You need the corresponding user management privilege.
One by one
Add new user: name, primary email, a recommended secondary email to receive account details, organizational unit, and password. The simplest option for a few users.
In bulk with CSV
Up to 150,000 users per file (200 if you assign licenses with the New Licenses column). Users created this way don't get a welcome email: you send them their credentials separately.
- Don't share one account among several people: each account should be used by only one user.
- To transfer a deleted user's data you must restore the user within 20 days. If you want to keep their data, suspend or archive them instead of deleting them.
Group types
Google recommends granting IAM roles to groups rather than to individual users. The Cloud Identity Groups API (Google Groups for Business only) supports these types:
| Type | What it is |
|---|---|
| Google Group | The default type. It has an email address and works as a mailing list, for sharing documents, or for access management in IAM. |
| Dynamic group | Membership managed automatically by an attribute query, such as job role or building. Only in Workspace Enterprise and Cloud Identity Premium; up to 500 per customer. |
| Security group | A Google Group converted to control access to resources. It can't be changed back to a regular Google Group. |
| Locked group | Attributes and membership can only be changed by certain administrators. Prevents drift from an external IdP. |
| POSIX group (deprecated) | Used with OS Login on VMs. Since September 26, 2024, new ones can't be created. |
Automating: GCDS and provisioning
Maintaining a Google identity per employee by hand is unnecessary work when they already exist in another directory. Federation with Cloud Identity has two pieces:
1. Provisioning
Users and groups are synced periodically from the external directory. That way they exist in Google Cloud before their first sign-in, and deletions propagate too. It is one-way and doesn't include passwords.
2. Single sign-on (SSO)
Google delegates authentication to the external IdP through SAML. No passwords are synced, and the policies and MFA configured in the IdP still apply.
Google Cloud Directory Sync (GCDS)
- A free Google tool that syncs users, aliases, groups, and shared contacts from Active Directory or an LDAP server.
- One-way sync: it never changes data on the LDAP server, which stays the source of truth.
- It runs in your environment (on-premises or on Google Cloud). It doesn't migrate content such as email or files.
- It supports mapping rules and exclusions, has a simulation stage, and emails a report after each sync.
- Because the APIs it uses are public, no hybrid connectivity is needed.
With Entra ID, provisioning is done by the "Google Cloud/G Suite Connector by Microsoft" gallery app, which is a Microsoft product. With an HR system (HRIS) as the source, it uses the Cloud Identity or Workspace APIs to onboard and offboard users.
Authoritative source and IdP
Google's reference architectures separate two decisions: which system is the authoritative source (the only one where identities are created and deleted) and which is the IdP (the only one that authenticates).
| Architecture | How it works | When |
|---|---|---|
| Google as IdP and source | Cloud Identity Premium or Workspace manage and authenticate | You already use Workspace and have no on-premises IdP |
| Google as IdP, HRIS as source | The HRIS provisions through the API | HR controls onboarding and offboarding |
| Active Directory as IdP and source | GCDS provisions and AD FS handles SSO. Cloud Identity Free is enough | Existing AD infrastructure |
| Entra ID as IdP, AD as source | Entra ID provisions and authenticates with SAML | You already use Microsoft 365 or Azure |
Best practice: sync groups as well as users, so you can control IAM access with directory group membership.
Workforce Identity Federation
It lets you authenticate your workforce (employees, partners, contractors) with an external IdP so they can access Google Cloud with SSO. Access is authorized with IAM allow policies.
Federation, not synchronization
It doesn't store user accounts in Google Cloud. You don't need GCDS or any tool that copies identities.
Protocols
Any IdP that supports OpenID Connect (OIDC) or SAML 2.0: Microsoft Entra ID, AD FS, Okta, and others.
Workforce versus Workload
Workforce Identity Federation federates people. Workload Identity Federation federates workloads (applications outside Google Cloud) and is covered in domain D4.
Federated users sign in to the Google Cloud console (federated). It works as an OAuth 2.0 token exchange (RFC 8693): the IdP credentials are presented to the Security Token Service, which returns a short-lived Google Cloud access token.
Workforce identity pools and providers
Workforce identity pool
- Groups identities, for example
employeesorpartners. - Configured at the organization level; its ID must be unique across all of Google Cloud.
- Lets you grant IAM access to the whole pool or a subset.
- Logs access to Cloud Audit Logs together with the pool ID.
- You can create several, for example one for employees and one per partner.
Workforce identity pool provider
- Describes the relationship between the organization and an IdP.
- OIDC and SAML types. OIDC supports the authorization code flow (the most secure) and the implicit flow.
- Holds the attribute mappings and conditions.
gcloud iam workforce-pools create WORKFORCE_POOL_ID \ --organization=ORGANIZATION_ID --location=global \ --session-duration=3600s gcloud iam workforce-pools providers create-oidc WORKFORCE_PROVIDER_ID \ --workforce-pool=WORKFORCE_POOL_ID --location=global \ --issuer-uri="ISSUER_URI" --client-id="OIDC_CLIENT_ID" ...
Session duration controls how long access tokens and federated console and gcloud sessions stay valid. The default is 1 hour, with a minimum of 15 minutes and a maximum of 12 hours.
Attribute mappings and conditions
The IdP sends attributes (also called claims) that are mapped with CEL (Common Expression Language):
| Attribute | Use |
|---|---|
google.subject (required) | Unique user ID. Shown as the principal in audit logs. Use a value that doesn't change or the user loses access. Max 127 bytes. |
google.groups | The user's groups, usable in IAM. A user in more than 400 groups can't sign in. |
google.display_name, google.profile_photo | Name and photo in the console. Not usable in IAM policies. |
google.posix_username | For SSH in the browser and OS Login with federation (preview). |
attribute.KEY | Custom attributes, e.g. cost center. Up to 50 rules. Google recommends stable values such as attribute.role. |
An attribute condition is an optional CEL expression that limits which identities can authenticate, for example only the accounting team. It is mandatory with multi-tenant IdPs such as GitHub or Terraform Cloud, which use a single issuer for all tenants: without a condition, any tenant could get in.
Principal identifiers in IAM
| Identity | Format |
|---|---|
| A single user | principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT |
| Everyone in a group | principalSet://…/workforcePools/POOL_ID/group/GROUP_ID |
| Everyone with an attribute value | principalSet://…/workforcePools/POOL_ID/attribute.NAME/VALUE |
| The whole pool | principalSet://…/workforcePools/POOL_ID/* |
- Workforce pool principals can't directly access resources outside their organization, unless they impersonate a service account.
- When you create the configuration you specify a workforce pool user project, which acts as the quota project for client-based APIs. It requires
serviceusage.services.use(the Service Usage Consumer role). - Federated users have no Cloud Identity email: configure Essential Contacts (Legal and Suspension categories) to receive notices.
Exam scenarios
| Situation | Answer | Why |
|---|---|---|
| Developers use personal Gmail accounts and the company wants control over them | Adopt Cloud Identity | Manages every account in the domain centrally. |
| Give Google Cloud access to 40,000 employees who already exist in Active Directory | GCDS + SSO with AD FS | One-way sync and delegated authentication. |
| Give console access with Okta SSO without creating Google accounts | Workforce Identity Federation | Federates without syncing or storing accounts. |
| Onboard 5,000 new users at once | Upload a CSV in the Admin console | Up to 150,000 users per file. |
| A group whose members update themselves based on job title | Dynamic group | Membership based on an attribute query. |
| Let a partner company manage its own users | A separate workforce pool for the partner | Distributed administration per pool. |
| Federate with a multi-tenant IdP such as GitHub | Mandatory attribute condition | A single issuer serves every tenant. |
Common exam traps
❓ Does GCDS write changes back to Active Directory?
No. Sync is one-way: AD stays the source of truth and is never changed.
❓ Does GCDS sync passwords?
The recommended practice is not to: authentication is delegated to the IdP with SAML (for example, AD FS), so passwords don't need to be copied.
❓ Does Workforce Identity Federation need GCDS?
No. It federates without syncing and doesn't store user accounts in Google Cloud.
❓ Do you need Cloud Identity Premium to use Google Cloud?
No. Free is enough, GCDS included. Premium adds security, advanced device management, Secure LDAP, and an SLA.
❓ Where do you create a Cloud Identity user?
In the Google Admin console, not on the IAM page of the Google Cloud console.
❓ Can a security group be changed back to a regular Google Group?
No. The conversion is irreversible.
❓ Which Workforce Identity Federation attribute is required?
google.subject. The others, such as google.groups or google.display_name, are optional.
Did you get this topic?
Test what you just learned
A company manages its identities in Okta and doesn't want to create or sync Google accounts for its 3,000 employees. It wants them to sign in to the Google Cloud console with SSO and to control access by Okta groups. What should it configure?
Ready to test "Cloud Identity and Workforce Identity Federation"?
Original questions, each with a full explanation.
Start a mock exam