Federated Identity Management

Federated identity management (FIM) is a system that allows users to use the same digital identity across multiple organizations or domains. Instead of maintaining separate user accounts for each service, a user authenticates once with their home Identity Provider (IdP), and then accesses Service Providers (SPs) or Relying Parties (RPs) without re-entering credentials. The trust is established through a federation agreement between organizations, often governed by standards like SAML (Security Assertion Markup Language), OAuth 2.0, and OpenID Connect (OIDC).

The core process involves three parties: the user (principal), the IdP, and the SP. The flow typically follows these steps: 1. User attempts to access a resource on an SP (e.g., a cloud application). 2. SP redirects the user to the IdP for authentication. This may involve an HTTP redirect with a SAML authentication request or an OAuth authorization request. 3. User authenticates to the IdP (providing username/password, MFA, etc.). 4. IdP generates an assertion (SAML) or ID token (OIDC) containing claims about the user (e.g., identity, attributes, roles). The assertion is digitally signed by the IdP using its private key. 5. User is redirected back to the SP with the assertion/token. The SP validates the signature using the IdP's public key (obtained via metadata exchange) and grants access.

The key security property is that the SP never sees the user's credentials—it only receives a cryptographically verified assertion.

SAML 2.0 (RFC 7522): Uses XML-based assertions. Common in enterprise SSO. Ports: HTTPS (443) for binding. Assertions contain Subject, Conditions (validity window), AttributeStatement (user attributes), and AuthnStatement (authentication event). SAML supports SP-initiated and IdP-initiated SSO.

OAuth 2.0 (RFC 6749): An authorization framework, not authentication. Issues access tokens (opaque or JWT) to allow delegated access to APIs. Roles: Resource Owner (user), Client (application), Authorization Server (AS), Resource Server (RS). Grant types: Authorization Code, Implicit, Client Credentials, Resource Owner Password Credentials. OAuth 2.0 does not define user identity—it's for authorization.

OpenID Connect (OIDC) (OIDC Core 1.0): An authentication layer built on OAuth 2.0. Issues an ID Token (JWT) containing identity claims. Standard scope: openid, profile, email, etc. OIDC adds the id_token and UserInfo endpoint. Commonly used in consumer SSO (Google, Microsoft).

WS-Federation: Microsoft-centric protocol using XML and SOAP. Less common today.

Token Theft: Attackers intercept SAML assertions or OIDC ID tokens via man-in-the-middle (MITM) or cross-site scripting (XSS). Defense: Use HTTPS everywhere, short token lifetimes, and token binding (e.g., OAuth 2.0 Token Binding RFC 8471).

Assertion Manipulation: An attacker modifies a SAML assertion (e.g., changes user role) if not signed. Defense: Always sign assertions; SP must validate signature and check conditions (NotBefore/NotOnOrAfter).

Replay Attacks: An attacker captures a valid token and reuses it. Defense: Include timestamps, nonces, and One-Time Use tokens. OIDC uses nonce parameter.

IdP Confusion: An attacker tricks the SP into accepting an assertion from a malicious IdP. Defense: SP must validate the Issuer field and use a pre-configured list of trusted IdPs.

Cross-Site Request Forgery (CSRF): In OAuth, an attacker tricks a user into authorizing a malicious client. Defense: Use state parameter (anti-CSRF token).

SAML Tracer (Browser Extension): View SAML requests/responses in plaintext. Useful for debugging.

OpenSSL for SAML signature verification:

openssl dgst -sha256 -verify idp_public.pem -signature assertion.sig assertion.xml

OIDC token validation with jose CLI:

jose jws verify -k provider_jwks.json -t id_token.jwt

Common CVE: CVE-2017-11427 (SAML XML signature wrapping in OneLogin).

Before federation, IdP and SP exchange metadata: certificates, endpoints, entity IDs. This can be manual (copying XML metadata) or dynamic (via OpenID Connect Discovery). The SP must trust the IdP's signing certificate to validate assertions.

Scenario 1: SAML Assertion Replay Attack

A SOC analyst detects multiple failed logins from the same IP but with different SAML assertions. The SIEM shows repeated use of the same assertion ID within a short time. The analyst uses SAML Tracer to capture the assertion and sees the same AssertionID repeated. The correct response: configure the SP to cache assertion IDs and reject duplicates. The analyst also recommends reducing assertion lifetime to 5 minutes and enabling OneTimeUse condition. Common mistake: focusing on blocking the IP rather than fixing the replay vulnerability.

Scenario 2: OIDC Token Theft via XSS

A web application stores the OIDC ID token in localStorage. An XSS vulnerability allows an attacker to exfiltrate the token. The attacker uses the token to access the UserInfo endpoint and impersonate the user. The SOC engineer sees a login from a new device without MFA. The correct response: patch XSS, use HttpOnly cookies for tokens, implement token binding (DPoP), and rotate tokens on each request. Common mistake: blaming the IdP for weak authentication.

Scenario 3: IdP Confusion Attack

An attacker registers a malicious IdP and tricks an SP into accepting its assertions. The SP's metadata only includes the legitimate IdP, but the attacker's assertion has a spoofed Issuer field. The SP fails to validate the Issuer against the trusted list. The SOC analyst sees successful logins from unknown users. The correct response: configure the SP to strictly validate the Issuer against a whitelist and use signed metadata. Common mistake: assuming that signature validation alone prevents this attack.