Prepare and test your skills
Prepare and test your skills
Creating a password and session management policy for user accounts means combining strong sign-in defaults in Identity Platform (opens in a new tab) with short-lived sessions and boundary checks that limit stolen credentials. Cloud Identity issues cached credentials after login, session policies force periodic re-authentication, and per-request and perimeter controls limit where a valid token can be used. Together these controls govern the full user session lifecycle from enrollment to expiry.
Time-bound Google Cloud sessions control how long cached Google Cloud credentials remain valid before the user must re-authenticate with a password or security key. New organizations receive a default session length of 16 hours for Google Cloud services, while organizations created before 2023 may still be set to never require re-authentication and must be reviewed. Administrators should enforce a session length between 1 and 24 hours, which bounds how long an attacker can reuse a compromised gcloud CLI token.
Session length for Google Cloud services is distinct from session length for Google services. Session length for Google Cloud services governs API and gcloud CLI access to Google Cloud and forces re-authentication when it expires. Session length for Google services governs web sign-in across Google Workspace services and does not control Google Cloud re-authentication, so organizations that use Workspace must set both values.
Exam tip: Session length for Google Cloud services expires gcloud CLI and API credentials on a 1 to 24 hour policy with a 16 hour default for new customers, while session length for Google services controls only Workspace web sessions.
Per-request checks and resource perimeters limit what a stolen token can still do while it remains valid. Chrome Enterprise Premium evaluates an access level on every user API request, using enforced attributes such as source IP and client mutual TLS (mTLS) certificate, and rejects traffic that fails those conditions. VPC Service Controls defines a service perimeter around supported resources and blocks API traffic to restricted services when the request originates from outside that perimeter.
The two controls sit on opposite sides of the trust boundary and cover different identities:
| Control | Boundary enforced | Identities covered |
|---|---|---|
| Chrome Enterprise Premium | User-to-Google check on every API call | Only user identities in the organization |
| VPC Service Controls | Resource perimeter around services | All user and service account identities |
When used together, Chrome Enterprise Premium stops the user request because device, IP, or certificate does not match, while VPC Service Controls stops the request at the resource because its source sits outside the perimeter. Administrators should not assume every signal collected by Endpoint Verification is enforced per request and should design access levels around IP and mTLS certificate.
Federated session alignment means the Google Cloud session lifetime and the external single sign-on (SSO) identity provider (IdP) session lifetime expire in a coordinated way. The flow starts when the user authenticates to the external IdP, then Cloud Identity or Google Workspace caches Google credentials for the configured Google Cloud session length. When that Google session expires, the cached credentials are invalidated and the next access requires re-authentication through the external IdP.
Alignment requires configuration on both sides of the federation boundary. Cloud Identity must limit the Google Cloud session length so expiry forces fresh federated authentication, and the external IdP must require multi-factor authentication (MFA) and limit its own session so MFA recurs each time. If the external IdP session is longer than the Google session, the user could re-authenticate to Google without a fresh MFA challenge.
Continuous authentication for SSH adds a separate human checkpoint for Compute Engine logins. OS Login with 2-Step Verification (2SV) requires password or security-key re-authentication on each SSH connection, so an attacker with only stolen OAuth tokens is blocked. Traffic routed through Identity-Aware Proxy (IAP) for SSH also requires users to periodically refresh Google credentials with MFA. OS Login 2SV is effective only when MFA is also enforced in Cloud Identity or the external IdP, because users with the Compute Instance Admin role or equivalent can disable OS Login 2FA by changing instance metadata. Remote Desktop Protocol (RDP) to Windows does not support OS Login, so RDP relies on coarse controls such as Google services session length, 2SV settings, and disabling Allow user to trust the device.
Password defaults, 2SV enforcement, and idle timeouts define secure baselines and force fresh proof of identity. Administrators enforce 2SV for all organizational units in the Google Admin console, and Security Command Center (opens in a new tab) audits missing enforcement as a HIGH severity finding. Secure passwordless authentication with security keys is preferred when feasible, with strong passwords plus MFA as the required fallback. Dedicated super-admin accounts must be kept small in number, used only for elevated tasks, protected with 2SV, and given backup codes for recovery.
Default settings inherit through three levels with increasing priority. A global setting applies to all users with the lowest priority, an organizational unit (OU) setting applies to users in that OU and its descendants and overrides the global setting, and a group setting applies to group members and overrides both OU and global settings. Supported defaults include enforcing 2-step verification, controlling access to Workspace and Google services, allowing or blocking less secure apps, assigning Cloud Identity Premium or Workspace licenses, and choosing data location.
Idle sessions are locked or disconnected even before maximum lifetime expires. Workforce identity pools enforce a session lock after 15 minutes of inactivity with --session-duration=900s, and remote HTTP access enforces disconnection by setting httpKeepAliveTimeoutSec to 900 seconds or less on target HTTP proxies. A compliant lock conceals the screen, cannot be disabled by the user, can be triggered on demand, and requires re-authentication to unlock.
Continue with this study guide: Creating a password and session management policy for user accounts.
Setting up Security Assertion Markup Language (SAML) and OAuth means using SAML to prove who the workforce user is and OAuth 2.0 to authorize what an application can do. Authentication (opens in a new tab) in this model divides work so the external identity provider (IdP) authenticates the user once, Google acts as the service provider that accepts that proof, and Google sessions and OAuth tokens then grant access to consoles and APIs. Authorization remains controlled separately by Google IAM roles and application roles.
How SAML federation divides authentication work describes three cooperating roles that enable single sign-on without a separate Google password. The principal requests access to the service provider, the service provider redirects that request to the external IdP for authentication, and the IdP returns a signed assertion that the service provider uses to create the session or OAuth 2.0 token required for access. The user is then redirected to the target application or console.
SAML federation divides work among three entities:
SAML in this exchange performs authentication only, while authorization is controlled by IAM grants, Cloud Identity or Google Workspace account state, or application roles such as Apigee user roles.
Establishing trust between Google and the external IdP means each side stores verifiable identifiers so requests and responses are accepted only from the expected partner. On the Google side, Identity Platform, Cloud Identity, or Google Workspace stores the IdP entity ID, the IdP SAML single sign-on (SSO) URL plus sign-in, sign-out, and password URLs, and the IdP token-signing certificate including its -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines. On the IdP side, the administrator registers Google as the relying party with the service-provider entity ID that acts as the audience and the Assertion Consumer Service (ACS) URL where the IdP must post the response. If any of these values differ between sides, Google rejects the request or the IdP posts to the wrong destination.
Mapping SAML assertions converts the IdP NameID and attribute statements into the Google subject and attributes used for access decisions. Google expects a stable subject, commonly expressed in a workforce pool as google.subject = assertion.subject, with explicit mappings such as attribute.user_email, attribute.first_name, attribute.last_name, and google.groups from assertion attributes including array forms like assertion.attributes.user_email[0]. To minimize assertion size, the IdP should send only attributes required by Google Sign-In. NameID sourcing is a frequent mismatch: one pattern maps NameID directly from user.mail, while another builds it by applying ExtractMailPrefix() to user.userPrincipalName then Join() with @ and a substitute verified domain that must match provisioning. A custom SAML provider ID in Identity Platform must begin with saml.
Issuer and audience alignment controls whether the IdP recognizes Google requests and whether Google accepts IdP responses. By default Google uses google.com as the Issuer in SAML requests and expects google.com as the Audience in SAML responses, which reflects that one Google Sign-In session is valid across accessible services. The alternative is a domain-specific issuer google.com/a/DOMAIN, where DOMAIN is the primary Cloud Identity or Google Workspace domain, used only when multiple Cloud Identity or Workspace accounts force the IdP to distinguish which account initiated sign-on.
Troubleshooting follows the ordered data flow from Google to the IdP and back, decoding the outbound request and inbound response to isolate the wrong value:
saml, copy SAMLRequest from the Payload tab, decode it, then confirm Request Destination exactly matches the SSO configuration in the IdP.signin-callback, copy SAMLResponse from the Payload tab, decode it, then confirm groups, first name, last name, and email match the workforce pool mapping and expected user.A destination mismatch points to a wrong SSO or ACS URL, a signature failure points to a missing or expired certificate on the Google side, and a valid signature with denied access points to a NameID or attribute-name mismatch.
Exam tip: Keep the default google.com issuer and audience unless multiple Cloud Identity or Google Workspace accounts require separation; SAML login alone grants no permissions because Apigee roles and IAM still control authorization.
OAuth 2.0 for workforce access issues scoped tokens that let an application act on a federated user's behalf without sharing credentials. In Workforce Identity Federation (opens in a new tab) the application depends on a workforce identity pool and provider in the same organization, and registration creates a workforce OAuth client with a client secret. Data flows from the IdP-authenticated user to the application and then to Google Cloud as the application uses the access token. OAuth integration for Workforce Identity Federation works only with Identity-Aware Proxy (IAP), not as a general replacement for standard OAuth clients managed under APIs and Services and Credentials.
Securing client IDs and secrets restricts who can view or manage them because anyone holding them can impersonate the application, access its entitled user data, perform actions on the user's behalf, or run phishing with a fake login page. When a breach is suspected, rotation follows an ordered lifecycle where the replacement is established before the old credential is removed:
Choosing between protocols means matching the goal to central lifecycle control versus limited resource access:
| Protocol | Primary unit exchanged | Choose when |
|---|---|---|
| SAML | Signed identity assertion from IdP to service provider | The need is workforce single sign-on, federation of Cloud Identity or Workspace, and central provisioning, suspension, and deprovisioning |
| OAuth 2.0 | Access token for delegated access | The need is to authorize calls to Apigee UI, web apps, or Google Cloud console, CLI, and APIs without sharing passwords |
Best practice is to minimize SAML attributes, keep the default issuer, and align IdP and Google session lengths so expiry triggers fresh authentication rather than silent re-authentication.
Continue with this study guide: Setting up Security Assertion Markup Language (SAML) and OAuth.
Configuring and enforcing 2-step verification means requiring a password plus a second factor before an account can manage Google Cloud. 2-Step Verification (2SV), also called multi-factor authentication (MFA), ensures theft of a password alone does not grant access. Enterprise Cloud Identity and Google Workspace provide the policy boundary, enrollment controls, and session controls that apply enforcement without locking users out during onboarding.
Enforcement scope separates the Google Cloud control plane that is gated by 2SV from the workload data plane that is not. Accounts subject to enforcement must have 2SV enabled to access the Google Cloud console and the Firebase console and are prompted to enroll before they can proceed. Traffic to applications and workloads running on Google Cloud continues to flow, including traffic to applications secured by Identity-Aware Proxy (IAP), but developers without 2SV cannot use the consoles to manage those applications.
Several paths sit outside the Google Cloud 2SV requirement:
Accounts with passkeys must still enable 2SV and add a factor, because sign-in from an untrusted device without a configured passkey still triggers a second-factor challenge. Accounts federated through a third-party IdP for SSO can satisfy the requirement with the IdP's 2SV.
Monitoring links eligibility to enforcement state. The userEmail field identifies the principal and mfaEligibility explains whether the account can enroll, with MFA_ELIGIBILITY_ELIGIBLE meaning it can enroll, MFA_ELIGIBILITY_INELIGIBLE meaning Workspace organization policy blocks enrollment, and MFA_ELIGIBILITY_UNSPECIFIED meaning eligibility is unknown, returned for third-party SSO users. The enforcementState field tracks the rollout lifecycle in order from upcoming enforcement in the reminder window, to enforced where console access triggers enrollment, to compliant where the requirement is satisfied, plus no enforcement when the organization opted out or when the user authenticates through third-party SSO.
Organization extension, opt-out, and sensitive-action checks adjust when console access is blocked without removing 2SV from enrolled users. These controls apply only to organizations that use Enterprise Cloud Identity without SSO and are managed by principals with the Organization Administrator role (roles/resourcemanager.organizationAdmin) on the Organizations page, with changes taking a few minutes to take effect. Organizations created before August 3, 2026 can receive a one-time 90-day extension by opening Organizations, selecting the organization, and confirming Extend by 90 days, after which the requirement is automatically reenabled.
Organizations using Enterprise Cloud Identity without SSO can also opt out by disabling Enforce 2SV, which only bypasses the requirement and does not disable 2SV for already-enrolled users. If the organization later opts back in, a minimum 30-day grace period applies before 2SV is required again to prevent immediate lockout. Session controls complement enforcement: a Workspace administrator configures maximum Workspace session length and re-authentication, local Application Default Credentials (ADC) files expire with the session and must be refreshed with gcloud auth application-default login, and sensitive use cases use a 15-minute idle timeout.
Google Cloud also requires re-authentication before sensitive console actions to protect against cookie theft. Billing assignment changes and IAM allow policy changes at the organization, folder, or project level require re-authentication when the action starts in the Google Cloud console, the user has not re-authenticated in the last 15 minutes by password or MFA, and the account is managed by Google. Accounts federated through Workforce Identity Federation are not required to re-authenticate, and the control is enabled by default with exceptions through support.
Exam tip: Opting out bypasses console enforcement but does not turn off 2SV for already-enrolled users, while the control plane remains gated and the workload data plane continues to serve traffic.
Phishing-resistant factors and recovery monitoring choose second factors that cannot be harvested and detect when verification is weakened. Hardware security keys provide phishing-resistant protection because the physical key must be present during console sign-in, so a remote attacker with a harvested password or intercepted one-time code cannot complete authentication. Google identifies hardware security keys as the strongest defense against takeover, with Titan Security Keys recommended for super admins and another security key as the alternative when Titan keys are not possible. Phone-based factors remain vulnerable to Signaling System 7 (SS7) interception, SIM swap, compromised phones and email, and social engineering, so they are a baseline for general users but not sufficient alone for super admins.
Blocked self-recovery removes a harvestable reset path for super admins. Cloud Identity disables super-admin self-recovery by default for new customers, while existing organizations may still need to turn it off in the Admin console so a locked-out super admin contacts another super admin with support-assisted recovery. Post-SSO verification applies Google risk analysis after external SSO and adds challenges for suspicious sign-ins, while Context-Aware Access creates granular policies for the Cloud and Admin consoles based on identity, location, device security status, and IP address.
Recovery and compliance are managed through policy settings and signals. The Policy API distinguishes security.super_admin_account_recovery for super admins and security.user_account_recovery for users and non-super admins, both using boolean enableAccountRecovery, with mutate not supported so control is through the Admin console. Enrollment uses allowEnrollment for whether users can turn on 2SV, enforcedFrom timestamp for when enforcement begins, enrollmentGracePeriod duration for new-user onboarding, allowTrustingDevice for device trust, and allowedSignInFactorSet with ALL, PASSKEY_ONLY, PASSKEY_PLUS_SECURITY_CODE, PASSKEY_PLUS_IP_BOUND_SECURITY_CODE, and NO_TELEPHONY. Access Context Manager (opens in a new tab) enforces credential strength with Common Expression Language (CEL) on request.auth.claims.crd_str, where pwd means password, hwk means hardware key such as Titan Key, otp means Google Authenticator and Backup Codes, and mfa means any method except pwd. When users can mark a device as trusted, a later sign-in without a fresh challenge correctly reports password-only strength, so disabling trust and requiring sign-out and sign-in restores MFA assertions. Security Command Center (opens in a new tab) flags Persistence: Two Step Verification Disabled and Persistence: Strong Authentication Disabled, plus Persistence: SSO Enablement Toggle and Persistence: SSO Settings Changed for SSO changes that can bypass verification.
Continue with this study guide: Configuring and enforcing 2-step verification.
google.com as the default SAML issuer and expected audience and uses google.com/a/DOMAIN only when multiple Cloud Identity or Google Workspace accounts require the identity provider to distinguish sign-ons.Session length for Google Cloud services governs API and gcloud CLI access to Google Cloud and forces re-authentication when it expires, with a 16 hour default for new organizations and an allowed range of 1 to 24 hours. Session length for Google services governs web sign-in across Google Workspace services and does not control Google Cloud re-authentication, so organizations that use Workspace must set both values.
Chrome Enterprise Premium evaluates an access level on every user API request using enforced attributes such as source IP and client mutual TLS certificate and covers only user identities in the organization. VPC Service Controls defines a service perimeter around supported resources, blocks API traffic to restricted services when the request originates from outside that perimeter, and covers all user and service account identities.
Rotation requires creating a new client credential for the OAuth client so the legitimate application has a working secret, then disabling the old client credential so the leaked secret can no longer obtain access. The old client credential is deleted only after the replacement is in use.
Last updated