SAML lets your customers sign in with their own identity provider, which removes a password from your system and adds a trust relationship you have to validate correctly. When validation is wrong, an attacker does not guess a password. They present an assertion claiming to be somebody else, and your portal believes it. OWASP maintains a cheat sheet for this because the same handful of implementation errors keep recurring.
Signatures and what gets checked
The assertion carries a signature and the whole security model depends on your service validating it properly. Three failures dominate. Accepting an unsigned assertion, which some libraries permit when configured loosely. Validating a signature without confirming it was made by the key you expect, so a self-signed document passes. Signature wrapping, where an attacker keeps the legitimate signed element and adds an unsigned one that the application actually reads. That last one is subtle and it is precisely why generic XML handling is a poor foundation for authentication. Use a library that validates the document as a whole rather than pulling out the elements you happen to want.
See also: Making New Friends Online: How Voice-First Apps Like Xena Help
The fields nobody validates
A correctly signed assertion can still be replayed or misdirected. Check the audience restriction so an assertion issued for another service is rejected, and check the recipient and destination match your endpoint. Enforce the validity window rather than treating timestamps as informational, and track assertion identifiers so the same one cannot be used twice. Where the portal matches users by email address, confirm the identity provider actually verifies that address, because otherwise a customer administrator can claim an address belonging to somebody at another organisation.
“Ask how your portal decides which local account an assertion maps to. If the answer is email address and you accept assertions from any customer’s identity provider, then any customer administrator can potentially sign in as any of your users. That is an architecture question, not a bug, and it needs answering before you add the tenth customer.”
William Fieldhouse, Director, Aardwolf Security Ltd
Managing many identity providers
A portal serving dozens of enterprise customers ends up trusting dozens of issuers, and each is configured by somebody in a hurry during onboarding. Keep a register of the metadata, certificates and expiry dates, and automate the reminder before a certificate expires so onboarding problems do not become outages. Review the register when a customer leaves, because a trust relationship outlives the contract unless somebody removes it. Scope each trust relationship to the customer it belongs to, so an assertion from one customer’s provider cannot authenticate a user in another customer’s tenant, which is the failure that combines an authentication flaw with a tenancy breach.
Testing federation properly
This needs a tester with two accounts and an identity provider they control, since the interesting attacks involve issuing your own assertions. Single sign-on penetration testing covers signature handling, replay, audience validation and the mapping logic that turns an assertion into a session. Where the same identity is used for programmatic access, API and integration testing should cover the token exchange as well, because the checks applied in the browser flow are often absent from the machine one.
Frequently asked questions about SAML security
These questions come up when a portal adds enterprise single sign-on.
Is OpenID Connect safer than SAML?
It is simpler, which usually means fewer implementation mistakes, and it is not automatically safer. Both depend on validating tokens correctly, and both fail the same way when a library is configured permissively.
Should you build federation yourself?
Rarely. Use a maintained library or an identity platform, and spend your effort on configuration, key management and the mapping logic, which is where the errors that matter actually live.
