# Identity Federation and Advanced Authentication

> Chapter 4 of the Courseiva GOOGLE-PCSE curriculum — https://courseiva.com/learn/google-pcse/identity-federation-and-authentication

**Official objective:** 2.3 — Configure identity federation, SSO, and MFA for workforce and customer identities.

## Introduction

Identity federation and advanced authentication. This is the system that lets a user log in once with their corporate email and seamlessly access dozens of cloud services — Google Cloud, Salesforce, Slack — without creating a separate account for each one. For the PCSE exam, you need to understand how to set up this trust between organisations so that security policies (like requiring a hardware token) are enforced everywhere, not just in one app.

## The Single Passport Analogy

41 countries in Europe are part of the Schengen Area. If you live in France, you carry one passport from the French government. When you fly to Italy, you show that same passport at the Italian border. The Italian officer doesn't call your mother to confirm your story — they trust the French government's digital stamp on your passport. You don't need to apply for a separate Italian ID card or memorise a dozen new passwords. You authenticate once with your home country, and every other country in the area accepts that proof.

That passport is your single identity. The French government is your identity provider (IdP) — the authority that verifies who you are and issues the credential. Italy is the service provider (SP) — the system that wants to let you in but doesn't want to manage its own identity database for every visitor. The agreement between all 41 countries to recognise each other's passports is the federation trust. The moment the Italian officer scans your passport and says "welcome" without asking for another password — that's single sign-on (SSO). If France also requires a fingerprint scan to issue the passport, and Italy respects that higher security level for sensitive buildings inside the country, that's multi-factor authentication (MFA) flowing across the trust boundary. The entire arrangement — multiple countries, one passport, no repeated registration — is identity federation.

## Core explanation

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:

- SAML assertion: an XML document signed by the IdP that contains the user's identity, attributes, and authentication timestamp.
- OIDC ID token: a JSON web token (JWT) that includes claims like 'sub' (subject identifier), 'email', and 'iss' (issuer).
- Service account: a special Google Cloud IAM identity used by applications (not humans) to authenticate to Google APIs. Federation can also apply to service accounts using workload identity federation, which lets an application running in AWS or Azure authenticate to Google Cloud without storing a service account key file.
- Federation trust: the mutual agreement between IdP and SP, established by exchanging metadata (endpoint URLs, signing certificates) out of band.

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.

## Real-world context

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.

## Exam focus

The PCSE exam tests identity federation and advanced authentication heavily in domain 2 (Identity and Access Management). Expect at least 8-12 questions on this topic across scenario-based multiple choice and case study sections. The exam writers love to test your understanding of the flow — who redirects to whom, what format the token is in, and where the trust is established.

Concepts you must memorise cold:

- SAML vs. OIDC: SAML uses XML, OIDC uses JSON. SAML is browser-redirect based, OIDC is API-friendly. Google Cloud supports both, but OIDC is recommended for new deployments.
- Federation trust types: direct trust (IdP and SP exchange certificates) vs. brokered trust (a third-party identity broker mediates). The exam will ask which trust model is appropriate for a specific scenario (e.g., a company acquiring another company and wanting to merge identities quickly — brokered trust is easier).
- Identity federation vs. identity synchronisation: federation does not copy user passwords to the SP; synchronisation (like Google Cloud Directory Sync) copies user objects but not passwords. The exam traps you by asking which approach is more secure for a scenario where the SP cannot be fully trusted — federation is safer because the password never leaves the IdP.
- Workload identity federation: this allows non-Google workloads (AWS, Azure, on-prem) to impersonate a Google Cloud service account without storing a service account key. The exam expects you to know that this eliminates the risk of leaked key files.
- BeyondCorp and zero trust: Google Cloud's BeyondCorp Enterprise enforces access based on user identity, device posture, and context — not on network location. The exam will ask you to choose a BeyondCorp configuration when the requirement is "no VPN, no bastion host, access based on user and device health".

Common traps set by exam questions:

- Trap: they present a scenario where a mobile app needs to authenticate using SAML. Answer: OIDC is better for mobile apps because SAML relies on browser redirects that are clunky on mobile.
- Trap: they give a scenario where a user logs in via federation but the SP still shows 'access denied'. Possible causes: attribute mapping mismatch (the IdP sent department=engineering but the SP expects group=engineering), or the user is not assigned to the application in the IdP.
- Trap: they ask about session length. If a user closes the browser and reopens it, does the SSO session persist? Answer: it depends on the session cookie set by the IdP. The SP has no control over the IdP session. The exam tests your understanding of session management scope.
- Trap: they ask about MFA enforcement when the IdP and SP are in different domains. The correct answer is that MFA is enforced at the IdP level for the authentication event, but the SP can also request re-authentication with MFA by including an 'AuthnContextClassRef' in the SAML request.

You must also be able to read a SAML assertion and identify the signer, the audience (the entity the token is intended for), and the conditions (validity timeframe). The exam will show you a truncated SAML XML snippet and ask what is wrong with it — often the audience does not match the SP's entity ID.

Key definitions to memorise:

- Entity ID: the unique identifier of the IdP or SP, usually a URL.
- Single logout (SLO): when you log out of one application, the IdP broadcasts a logout request to all SPs the user has active sessions with.
- Just-in-time (JIT) provisioning: the IdP creates a user account in the SP on first login, so you don't need to pre-create accounts.
- Claim mapping: the process of translating IdP attributes (e.g., 'mail') into SP attributes (e.g., 'email').

## Step by step

1. **Choose an Identity Provider (IdP)** — Select which system will be the authoritative source for user identities. This could be Microsoft Entra ID, Okta, Ping, or Google Cloud itself if you are using Cloud Identity. The IdP must support SAML 2.0 or OIDC. This decision determines where users will enter their passwords and where MFA policies will be defined.
2. **Configure the IdP with Google Cloud as a Service Provider (SP)** — In your IdP (e.g., Microsoft Entra ID), add Google Cloud as an enterprise application. Enter the Google Cloud SAML or OIDC endpoint URL (the 'Entity ID' and 'Assertion Consumer Service URL'). Upload Google Cloud's metadata or manually enter the endpoints. This tells the IdP 'when a user tries to access Google Cloud, send authentication requests to this specific URL'.
3. **Configure Google Cloud (SP) with IdP Metadata** — In the Google Cloud Console, navigate to Security > Identity Platform or IAM > Identity Federation. Create a new SAML or OIDC provider. Upload the IdP's metadata file (which contains the IdP's login URL, logout URL, and public signing certificate). This establishes the reverse trust: Google Cloud now knows which IdP to trust and how to verify the signature on incoming authentication tokens.
4. **Map Attributes and Define Access Policies** — Define how attributes from the IdP (e.g., user email, department, group membership) map to Google Cloud identities. For example, map the SAML 'NameID' to the user's email address. Then assign IAM roles based on these mapped attributes or on groups. For example, all users with the 'finance' attribute get the 'roles/finance.viewer' role. Also configure session timeout and whether to accept authentication tokens without MFA.
5. **Test the Federation Flow and Enable Applications** — Use a test user account to verify the end-to-end flow: the user attempts to access a Google Cloud application, gets redirected to the IdP login page, authenticates, and lands back on the application. Check Cloud Audit Logs to confirm the authentication event was recorded. Once verified, enable the federation configuration for all intended Google Cloud services (e.g., via IAP, Cloud Run, or Compute Engine).
6. **Configure Advanced Authentication and Monitoring** — Implement adaptive MFA policies on the IdP (e.g., require MFA for high-risk sign-ins). Set up session revocation (if a user leaves the company, disable them in the IdP and configure automatic session termination). Enable detailed logging with Cloud Audit Logs and set up alerts for failed federation attempts. Schedule certificate rotation for the signing certificates exchanged between IdP and SP.

## Comparisons

### SAML 2.0 vs OpenID Connect (OIDC)

**SAML 2.0:**
- Uses XML format for tokens and metadata
- Primarily uses browser redirect for authentication flow
- Older, more widely used in legacy enterprise applications

**OpenID Connect (OIDC):**
- Uses JSON format for tokens (JWT)
- Supports direct API calls and mobile app flows
- Newer, recommended for modern and mobile applications

### Federation (IdP-to-SP trust) vs Identity Synchronisation (e.g., GCDS)

**Federation (IdP-to-SP trust):**
- No passwords are shared with the SP
- User authenticates at the IdP each time
- SP never stores or manages user credentials

**Identity Synchronisation (e.g., GCDS):**
- User objects are copied to the Google Cloud directory
- Passwords are not replicated unless using password sync
- Google Cloud becomes a copy of the user database, not just relying on the IdP

### Workload Identity Federation vs Service Account Key Authentication

**Workload Identity Federation:**
- No storage of long-lived secret keys
- Uses token exchange with external IdP (AWS, Azure)
- Reduces risk of key leakage and manual key rotation

**Service Account Key Authentication:**
- Requires storing a private key file
- Key can be compromised if stored insecurely
- Requires manual key rotation and lifecycle management

### MFA enforced at IdP vs MFA enforced at Google Cloud (IAP/BeyondCorp)

**MFA enforced at IdP:**
- User must pass MFA to get a valid federation token
- MFA policy is controlled by the organisation's IdP administrator
- Does not by itself force MFA for each app unless the app requests a specific auth context

**MFA enforced at Google Cloud (IAP/BeyondCorp):**
- Google Cloud can request additional authentication from the user
- Enforced at the application or API gateway layer
- Can be independent of the IdP's MFA policy for extra security

## Diagram

_The flow of identity federation: a user requests access to a Google Cloud application, which redirects them to the identity provider for authentication, then the identity provider returns a signed token that Google Cloud verifies before granting access._

```mermaid
flowchart TD
    User[User's Browser] -->|Access request| SP[Service Provider e.g. Google Cloud App]
    SP -->|SAML/OIDC AuthnRequest redirect| IdP[Identity Provider e.g. Microsoft Entra ID]
    IdP -->|User enters password + MFA| IdP
    IdP -->|Signed SAML assertion / ID token| SP
    SP -->|Verify signature & extract attributes| SP
    SP -->|Grant access based on IAM roles| User
    User -->|Access granted| SP
    IdP -.->|Certificate exchange & metadata| SP
```

## Common misconceptions

- **Misconception:** Federation and SSO are the same thing. **Reality:** Federation is the infrastructure that allows trust between organisations; SSO is the user experience that results from that trust. You can have SSO without federation (e.g., logging into multiple Google services with one Google password, which is just SSO inside one domain). Federation always involves separate security domains (e.g., your company and Google Cloud). (Many beginners see the single-login outcome and assume the whole mechanism is the same. They don't distinguish between a single IdP managing multiple apps in the same organisation (SSO) vs. multiple organisations agreeing to trust a shared IdP (federation).)
- **Misconception:** If I set up SAML federation, all users automatically appear in Google Cloud IAM. **Reality:** SAML federation authenticates users but does not provision accounts. Users are authenticated on-the-fly, but you must still assign IAM roles to the user's identity (usually their email or a group). Google Cloud does not automatically create user entries in Cloud Identity just because a SAML assertion arrives; you typically use user provisioning or JIT provisioning with attribute mapping to assign roles. (The term 'federation' sounds like it handles everything. Beginners assume authentication and authorisation are bundled together. They forget that IAM roles are separate from identity verification.)
- **Misconception:** Once I enable MFA on the IdP, all apps get MFA automatically. **Reality:** MFA enforced at the IdP level applies only to the act of authenticating to the IdP. However, some SPs can request a specific authentication context (e.g., 'require MFA for this application') by sending an AuthnContextClassRef in the SAML request. If the SP does not request it, the IdP may honour its own policies or skip MFA depending on the IdP configuration. Also, MFA at the IdP does not protect the SP if the SP uses a separate login flow (e.g., API key authentication). (People assume MFA is one switch that protects everything. They don't understand that federation tokens can carry varying levels of assurance, and each SP can have its own policy.)
- **Misconception:** OpenID Connect is just a newer version of SAML. **Reality:** They are fundamentally different protocols with different architectures. SAML is a standalone authentication protocol that uses XML and is designed for enterprise web SSO. OIDC is an authentication layer built on top of OAuth 2.0, which is an authorisation framework. OIDC uses JSON and is designed for modern web and mobile apps. They are not interchangeable drop-in replacements. (Both solve similar problems (federated authentication), so people assume one evolved from the other. They miss that OIDC's roots in OAuth 2.0 mean it handles delegated authorisation (e.g., letting an app access your Google Drive) in addition to authentication.)
- **Misconception:** Workload identity federation requires storing a service account key in the external system. **Reality:** The entire point of workload identity federation is to eliminate service account keys. Instead, the external workload (e.g., a VM in AWS) presents a token from its own identity provider (e.g., AWS IAM role), and Google Cloud's federation endpoint exchanges that token for a Google Cloud access token. No long-lived keys are stored or transmitted. (Beginners are so used to service account keys as the default authentication method for non-Google workloads that they assume federation still requires those keys. They don't grasp the federated token exchange concept.)

## Key takeaways

- Identity federation enables a user to authenticate once with their organisation's identity provider and access multiple cloud services without creating separate accounts. 
- SAML 2.0 uses XML-based assertions for enterprise SSO, while OpenID Connect uses JSON web tokens and is preferred for modern and mobile applications. 
- MFA enforced at the identity provider does not automatically protect all service providers unless the federation protocol explicitly signals the required authentication strength. 
- Federation does not provision user accounts or assign IAM roles; you must separately configure attribute mapping and role assignment in Google Cloud IAM. 
- Workload identity federation lets non-Google workloads authenticate to Google Cloud without storing service account keys, reducing the risk of key leakage. 
- The core security principle of federation is that passwords never leave the identity provider, so a compromised service provider cannot steal user credentials. 
- Google Cloud supports both SAML and OIDC for workforce federation, and also provides Identity Platform for customer identity and access management (CIAM) with social login. 
- Session management (single logout, session duration) must be explicitly configured on the IdP and SP because tokens carry their own validity period. 

## FAQ

**What is the difference between SAML and OIDC?**

SAML is an older XML-based protocol used mainly for enterprise web applications, while OIDC is a newer JSON-based protocol built on OAuth 2.0, commonly used for modern web and mobile apps. Google Cloud supports both, but OIDC is preferred for new integrations because it is simpler and more flexible.

**Does federation mean my users don't need passwords in Google Cloud?**

Yes, for federated users. They authenticate to the identity provider (e.g., Microsoft Entra ID) and never type a password into Google Cloud. Google Cloud receives a signed token and trusts that the IdP already verified the password. However, service accounts and break-glass admin accounts in Google Cloud still have passwords or keys.

**How do I force MFA for a specific Google Cloud application via federation?**

Configure the IdP to require MFA based on the application. In Google Cloud, you can also use IAP with BeyondCorp to enforce MFA at the Google Cloud side by setting a session duration and requiring reauthentication for sensitive endpoints, but the primary MFA enforcement happens on the IdP.

**Can I use federation to let customers log in with their own Google accounts?**

Yes, that is called customer identity and access management (CIAM). Google Cloud Identity Platform supports social login (Google, Facebook, Apple) and enterprise federation via SAML/OIDC. You configure the external IdP in Identity Platform, and users authenticate with their own credentials.

**What happens to a user's sessions if the IdP goes down?**

Existing sessions (tokens) remain valid until they expire because they were already issued and signed. However, no new authentications can occur. Users already logged in continue to access Google Cloud until their token expires. This is why you should configure a reasonable token lifetime and have a backup IdP for failover.

**Is it possible to federate with more than one IdP?**

Yes. Google Cloud supports multiple SAML and OIDC providers in Identity Platform. Different groups of users (employees, contractors, partners) can authenticate with different IdPs. You can configure separate trust relationships and attribute mappings for each IdP.

## Check your understanding

1. **What is the primary security benefit of identity federation compared to storing user credentials in each cloud service?**

   Answer: The user's password never leaves the identity provider, so even if a service provider is compromised, attackers cannot steal the master credentials.

2. **Which protocol is better suited for a mobile app that needs to authenticate users via federation: SAML or OIDC?**

   Answer: OIDC is better suited because it works natively with mobile app authentication flows (e.g., authorisation code flow with PKCE) and does not rely on browser redirects as heavily as SAML.

3. **If a user logs into a federated application and the application still refuses access, what is the first thing to check?**

   Answer: Check the attribute mapping — the IdP may be sending a claim (e.g., 'department') that does not match the attribute the SP expects (e.g., 'role'), or the user may not be assigned to the application in the IdP.

4. **When using workload identity federation, what replaces the need to store a service account key?**

   Answer: The external workload authenticates to its own identity provider (e.g., AWS IAM) and exchanges that token for a Google Cloud access token via a token exchange endpoint, eliminating the need for a stored service account key.

5. **Is it possible to require MFA for some applications but not others when using the same federated identity provider?**

   Answer: Yes, the IdP can enforce conditional access policies based on the application or other context (e.g., risky sign-in), or the SP (Google Cloud) can request a specific authentication context that requires MFA.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/google-pcse/identity-federation-and-authentication