Identity federation lets your users authenticate once and access resources across multiple cloud platforms and applications. It’s convenient, it improves user experience, and it can dramatically simplify identity management. It also creates trust relationships that attackers can exploit to pivot between environments.
When federation works correctly, it’s invisible. When it fails, the impact crosses every environment connected by the trust. Understanding the risks inherent in federation helps you implement it securely.
SAML Assertion Attacks
SAML-based federation relies on signed assertions from an identity provider that the service provider trusts. If an attacker can forge, modify, or replay a SAML assertion, they can authenticate as any user without knowing their password.
SAML implementation flaws, including signature wrapping attacks, missing signature validation, and predictable assertion IDs, have been discovered in major platforms. The complexity of SAML means that even experienced developers introduce implementation errors.
William Fieldhouse, Director of Aardwolf Security Ltd, comments: “Identity federation is one of the most powerful and most dangerous features in cloud environments. A misconfigured SAML trust or an overprivileged OIDC provider can give an attacker in one environment seamless, authenticated access to another. We test federation trust boundaries in every cloud engagement.”
Cross-Cloud Trust Boundaries
Organisations using multiple cloud providers often federate identity between them. Your Azure AD might issue tokens that grant access to AWS resources, or vice versa. These cross-cloud trust relationships mean that a compromise in one cloud environment can cascade into another.
The blast radius of an identity compromise expands with every federated trust. An attacker who compromises your identity provider effectively compromises every service provider that trusts it.
Testing Federation Security
Both Azure penetration testing and AWS penetration testing should include assessment of your federation configurations. Testers evaluate SAML implementations for common vulnerabilities, test token validation and replay controls, and attempt to escalate access through trust relationships.
Federation testing requires specialist knowledge. The interactions between identity providers, service providers, and multiple cloud platforms create complex trust chains that standard testing approaches don’t cover adequately.
Securing Your Federation
Validate SAML signatures using strict canonicalisation. Implement assertion time limits and replay detection. Use conditional access policies that evaluate device health and location before issuing tokens. Monitor federation logs for unusual authentication patterns.
And review your trust relationships regularly. Every federated connection is a potential attack path, and connections established during rapid cloud adoption may not reflect your current security requirements.
