Identity Federation and Advanced Authentication

Let's start with the core problem every organisation faces. Before federation, if a company used five different cloud services, employees had to create five different usernames and passwords. The IT team had to manage five separate user directories. When someone left the company, the IT team had to delete them in five different places. Each service also had its own password policy — one might require 8 characters, another might require 12 with a special symbol. Users got frustrated, wrote passwords on sticky notes, and security suffered.

Identity federation solves this by creating a single source of truth for user identities. The organisation runs one identity provider (IdP) — Google Cloud's IAM, Microsoft Entra ID, or a third-party service like Okta or Ping. That IdP is the authoritative database of all employees, their roles, and their authentication methods (password, fingerprint, hardware key). Every cloud service the company uses becomes a service provider (SP). The SP doesn't store its own copy of the user database. Instead, when a user tries to access the SP, the SP redirects them to the IdP. The IdP authenticates the user, then sends a digitally signed token (a SAML assertion or an OpenID Connect ID token) back to the SP. The SP verifies the signature using a pre-shared public key or a certificate, trusts the token, and grants access.

The technical standards that make this work are SAML 2.0 (Security Assertion Markup Language) and OpenID Connect (OIDC). SAML is older, XML-based, and commonly used in enterprise web applications. OIDC is newer, built on the OAuth 2.0 authorisation framework, and uses JSON web tokens (JWTs). Both standards define how the authentication request and response are formatted, how tokens are signed, and how the IdP and SP discover each other's metadata. Google Cloud supports both, but OIDC is preferred for modern applications because it is simpler and works natively with mobile and single-page apps.

Now add advanced authentication. Federation handles who can authenticate — the IdP decides that. But how they authenticate — the strength of the proof — is controlled by authentication policies. Multi-factor authentication (MFA) requires at least two different types of evidence: something you know (password), something you have (phone, hardware security key), and something you are (fingerprint, face). Advanced authentication extends this with adaptive (or contextual) access: if the user is logging in from a recognised office network on a company-managed device, they may only need a password. If they are logging in from a coffee shop in a different country at 3 AM, the system requires MFA or blocks the request entirely. Google Cloud's Identity-Aware Proxy (IAP) and BeyondCorp Enterprise enforce these adaptive policies at the application layer.

The exam covers three main deployment scenarios: workforce federation (employees accessing corporate apps), customer identity and access management (CIAM) (external users like customers or partners logging into your app with their own Google or Facebook accounts), and hybrid federation (on-premises Active Directory synchronised with Google Cloud via Google Cloud Directory Sync or Microsoft Entra ID federation). Each scenario requires different configuration steps: certificate exchange, attribute mapping (which fields in the token represent the user's role, department, or group membership), and session timeout settings.

Key components you must understand include the following:

Finally, you must understand the security implications. Federation reduces password fatigue but creates a single point of compromise: if the IdP is breached, an attacker can impersonate any user to any trusted SP. This is why MFA is critical, why IdP administrators must be protected with strong authentication and separation of duties, and why organisations should implement session revocation and real-time logging via Google Cloud's Cloud Audit Logs. The exam will test your ability to design a federation architecture that balances user convenience with security controls.

Imagine you are a security engineer at a mid-sized retail company called ShopNow. ShopNow uses Google Cloud for its e-commerce platform, Salesforce for customer relationship management, and Slack for internal communication. The company has 500 employees and 10,000 external partner accounts (suppliers who need to check inventory). Your task is to implement identity federation so that employees log in once with their corporate email and gain access to all three services without separate passwords.

Step one: you choose an identity provider. Since the company already uses Microsoft Entra ID for on-premises Active Directory, you decide to use Microsoft Entra ID as the primary IdP. You configure Google Cloud as a service provider using SAML 2.0. In the Google Cloud console, you go to Security > Identity Platform, enable SAML, and upload the Microsoft Entra ID metadata file (which contains the Microsoft Entra ID login URL and the signing certificate). On the Microsoft Entra ID side, you add Google Cloud as an enterprise application and assign the user groups that should have access (e.g., all employees). You map the SAML attributes: the 'NameID' becomes the user's email address, and you add a custom attribute 'department' that Google Cloud will use to assign IAM roles.

Step two: test single sign-on. You log out of all services, open an incognito window, navigate to the ShopNow e-commerce application hosted on Google Cloud. The app redirects you to Google Cloud's IAP, which sees you are not authenticated. IAP redirects you to Microsoft Entra ID's login page. You enter your corporate credentials. Microsoft Entra ID authenticates you, generates a SAML assertion, and sends you back to Google Cloud. Google Cloud verifies the assertion signature, extracts your email and department, and grants you access. You never created a Google-specific account — your identity flowed from Microsoft Entra ID into Google Cloud.

Step three: configure advanced authentication. The company's security policy requires MFA for anyone accessing financial data or logging in from an unrecognised device. In Microsoft Entra ID, you set up a conditional access policy: if the application is 'Finance Portal' or if the sign-in risk is 'medium or higher', require MFA. You also integrate Google Cloud's reCAPTCHA Enterprise to detect automated login attempts. For external partners, you use Google Cloud's Identity Platform with social login (they can authenticate using their own Google or LinkedIn accounts), but you enforce MFA for all partner logins because they handle sensitive inventory data.

Step four: monitor and audit. You enable Cloud Audit Logs in Google Cloud to record every federation login event: who accessed what service, from which IP address, and whether MFA was used. You set up alerts for failed authentication attempts that exceed a threshold. You also configure session duration: employee sessions expire after 8 hours, partner sessions expire after 2 hours, and all sessions are invalidated immediately if the user is disabled in Microsoft Entra ID (via provisioning).

Step five: handle disaster recovery. You configure a second IdP (e.g., Okta) as a backup. If Microsoft Entra ID is unavailable, the SAML metadata in Google Cloud points to an alternative endpoint. You test failover quarterly. You also store the signing certificates securely in Google Cloud Secret Manager and rotate them every 12 months.

What do you actually do in the Google Cloud console? - Create a SAML integration in Identity Platform and upload the IdP metadata. - Configure attribute mapping to match IdP claims to Google Cloud user attributes. - Enable IAP for each application and associate it with the federation configuration. - Set up Cloud Identity groups for role-based access control (RBAC) — e.g., the 'finance' group gets the 'roles/finance.viewer' IAM role. - Test the flow with a non-production user before deploying to all employees.