Professional Cloud Security Engineer

Creating a Password and Session Management Policy for User Accounts

Administrators configure password policies within Cloud Identity or Google Workspace to enforce baseline credential security across an organization. These policies set minimum password lengths, require character complexity, and restrict password reuse to prevent brute-force attacks and credential recycling. When an administrator updates a password policy, the control plane checks all future credential changes against the new rules while leaving existing active passwords in place until their scheduled reset.

Session management policies govern how long a user's authenticated session remains valid before requiring re-authentication. Administrators configure session length controls for services like the Google Cloud console and the Cloud SDK, defining the maximum time a web or command-line session can stay active. When a session reaches its expiration limit, the platform revokes the active session token and prompts the user to verify their identity again, limiting the window of opportunity if a workstation is left unattended.

Setting up Security Assertion Markup Language (SAML) and OAuth

Federating authentication allows an organization to use an external identity provider (IdP) as the single source of truth for user access to Google Cloud through Security Assertion Markup Language (SAML 2.0). When a user navigates to the Google login page, Google Cloud redirects the authentication request to the external IdP. The IdP verifies the user's credentials and passes a cryptographically signed SAML assertion back to Google Cloud, which validates the response and creates the user session without storing external passwords.

While SAML handles federated single sign-on for interactive users, OAuth 2.0 manages delegated authorization for applications, tools, and programmatic API access. Applications request an authorization token by directing users to Google's authorization server with specific access scopes. Once the user approves the requested permissions, Google issues short-lived access tokens and long-lived refresh tokens to the client application, allowing it to act on the user's behalf without exposing the user's underlying credentials to third-party code.

Configuring and Enforcing 2-Step Verification

Configuring 2-Step Verification (2SV) introduces an obligatory secondary proof of identity during the login flow to mitigate the risk of compromised passwords. Administrators define 2SV policies at the organizational unit level, choosing between standard verification methods like push prompts, time-based one-time passwords (TOTP), or hardware security keys. Hardware security keys using the FIDO standard provide the strongest defense because they cryptographically validate the domain origin, effectively preventing real-time phishing and proxy attacks.

Enforcement follows a structured lifecycle to prevent administrative lockouts and ensure a smooth rollout across teams. Administrators usually configure an initial enrollment period with a grace window, giving users time to register their hardware keys or authenticator apps before enforcement takes effect. Once the grace period expires, the policy transitions to an enforced state, automatically blocking sign-in attempts for accounts lacking an active secondary verification method until an administrator assists with an account recovery code.