Federation, SSO & identity providers
Most enterprises stop managing cloud logins one account at a time and instead federate access through a central identity provider — Okta, Entra ID, Ping, Google Workspace, or another IdP — so that people sign in once and inherit cloud roles from their directory group membership. Done well, federation is the strongest control in the identity domain: joiners, movers, and leavers are handled in one place, MFA is enforced upstream, and no human carries standing cloud credentials. Done poorly, it becomes a quiet single point of failure — the SAML or OIDC trust that grants access is only as trustworthy as its signing certificate, its assertion conditions, and the group-to-role mapping behind it. This sub-topic examines the plumbing of that trust: who the cloud believes when an assertion arrives, what that assertion is allowed to grant, and whether any direct logins still bypass the front door entirely. It is distinct from role and MFA hygiene — here the question is whether the federation model itself holds up.
Overview
What this check looks like in practice
Most enterprises federate cloud access through an identity provider. Misconfigured federation, orphaned direct logins, and weak group-to-role mappings undermine the whole model.
Why it matters
Federation concentrates trust: a single misconfigured identity provider or a role that trusts the wrong assertion can hand an attacker access to every account the IdP fronts, which is exactly why assertion-forgery and token-theft techniques (Golden SAML, malicious app registrations, stolen refresh tokens) target this layer. Auditors treat federation as a keystone control — they want evidence that cloud access is centrally governed, that group-to-role mappings follow least privilege, and that deprovisioning in the HR system actually revokes cloud access rather than just hiding the SSO tile. The most damaging failures are the invisible ones: an orphaned break-glass login that never went through the IdP, a SAML trust with no audience or condition restriction, or a session lifetime measured in days so a stolen token stays valid long after the user left. Because federation touches every downstream role, a weakness here quietly undermines the MFA, least-privilege, and joiner-mover-leaver controls the organization believes it already has.
What we assess
What we look for
- Direct cloud logins (IAM users, local admin accounts, standalone service-account keys) that bypass the central IdP and are not documented, monitored break-glass paths
- SAML/OIDC trust configuration weaknesses: missing audience/condition restrictions, overly long assertion or token validity, unpinned or stale IdP signing certificates, and trusts that accept assertions without an external ID or subject constraint
- Group-to-role mappings that over-grant on join — broad directory groups wired to admin-equivalent cloud roles, or default 'all employees' groups mapped to privileged permission sets
- Session and token lifetimes that are longer than the work requires, leaving stolen tokens valid well beyond a normal working session
- Deprovisioning gaps between the HR system, the IdP, and cloud access — offboarded users whose federated access or refresh tokens still resolve to live roles
- SCIM/automated provisioning coverage: whether group and user changes actually propagate to the cloud, or whether stale mappings persist because provisioning is manual or partial
- Guest, external, and cross-tenant/cross-organization federation that grants standing access broader than the integration needs
- Whether MFA and Conditional Access are actually enforced at the IdP for privileged federated sessions, rather than assumed
Across your clouds
AWS, Azure & Google Cloud
AWS
IAM Identity Center (successor to AWS SSO) fronting an external IdP over SAML/OIDC with SCIM provisioning, or legacy IAM SAML/OIDC identity providers with roles whose trust policies assume federated principals. We check permission-set session duration, group-to-permission-set assignments, the sts:AssumeRoleWithSAML / AssumeRoleWithWebIdentity trust conditions (SAML:aud audience, oidc issuer/sub, session-tag PrincipalTag constraints), signing-certificate freshness on the IAM SAML provider, and any residual IAM users that log in outside Identity Center.
Azure
Entra ID as the identity provider for federated cloud and SaaS access — enterprise applications (SAML/OIDC SSO), federated identity credentials on app registrations, and workload/service-principal trust. We review Conditional Access enforcement on privileged sessions, sign-in-frequency and refresh-token lifetimes, cross-tenant access (B2B) inbound/outbound settings, guest-account sprawl, consented (delegated and application) app permissions, and whether group-based role assignments over-grant on join.
Google Cloud
Workforce Identity Federation for human access and Workload Identity Federation for external workloads, plus Cloud Identity / Google Workspace as the directory, with SAML/OIDC to an external IdP. We check provider attribute mappings and attribute conditions, Google Group-to-IAM-binding grants, workforce-pool session duration and reauthentication settings, org-policy constraints on service-account key creation (iam.disableServiceAccountKeyCreation), and any direct service-account keys that bypass federation.
Example finding
A SAML role trust with no audience restriction and a 12-hour session, plus three surviving direct-login IAM users
Risk: The federated role accepts any valid assertion from the IdP without constraining the audience (SAML:aud) or a subject condition, so a forged or replayed assertion (Golden SAML-style) or a token minted for a different relying party could assume it; the long session means a stolen session persists most of a day. Meanwhile three IAM users with console passwords and access keys bypass SSO entirely, so their activity is invisible to the IdP's MFA and Conditional Access and survives offboarding in the directory.
Fix: Add an audience/condition constraint to the role trust policy so it only accepts assertions minted for this relying party, shorten the permission-set/role session duration to match a working session, rotate and pin the IdP signing certificate on the SAML provider, and either convert the three direct IAM users to federated access or, if they are genuine break-glass accounts, reduce them to one, enforce hardware MFA, and alert on every use.
Remediation
How to close it
- 1 Inventory every path into each cloud account and classify it: federated via the central IdP, or a direct login (IAM user, local admin, standalone key). Every direct path must be justified as documented break-glass or scheduled for migration.
- 2 Tighten the trust itself — add audience/condition/external-ID constraints to SAML and OIDC role trusts, pin and rotate IdP signing certificates, and reject assertions that lack a bound subject or relying-party restriction.
- 3 Right-size group-to-role mappings so joining a directory group grants only the access that role of person needs; break broad 'all staff' or catch-all groups away from privileged permission sets and roles.
- 4 Shorten session and token lifetimes to match real working sessions, and enforce MFA and Conditional Access at the IdP for privileged federated access rather than assuming it applies.
- 5 Close the deprovisioning loop: wire SCIM/automated provisioning from HR to IdP to cloud, and verify by test that offboarding a user revokes cloud roles and invalidates refresh tokens, not just the SSO tile.
- 6 Reduce break-glass to the minimum number of accounts, protect them with hardware MFA and sealed credentials, and alert on every use so the one bypass you keep is the one you always see.
Compliance evidence
Questions
We already use SSO — isn't federation basically solved?
Adopting SSO is the start, not the finish. The assessment looks at how the federation is configured, not whether it exists: assertion and token constraints, signing-certificate hygiene, session lifetimes, how directory groups map to cloud roles, and — most often the real gap — whether any direct logins still bypass the IdP. A healthy SSO tile can sit in front of a trust relationship that grants far more than it should.
Does assessing federation mean touching our identity provider or reconfiguring SSO?
No. This is read-only, like the rest of the health check. We review the cloud-side trust configuration, permission-set and role assignments, session settings, and provisioning coverage, and we correlate them with how your IdP is wired — without changing SAML, OIDC, Conditional Access, or any production login. You get findings and an ordered plan; your team makes the changes.
What is the most common federation finding you see?
Orphaned direct access and over-granting on join. Direct IAM users or standalone service-account keys survive an SSO rollout and quietly bypass MFA and offboarding, and broad directory groups get wired to admin-equivalent roles so joining a team grants more than the job needs. Both are invisible from the SSO login screen, which is exactly why they persist until someone looks at the trust and mapping layer directly.
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
