SAML

The flow is short. The service provider redirects the user to the identity provider, the identity provider authenticates them and returns a signed assertion naming the user and their attributes, and the service provider validates the signature and creates a session. Everything rests on that validation, because the assertion travels through the user’s browser and is therefore under the user’s control.

That is where the classic audit finding lives. Implementations that parse the document before verifying the signature, that verify a signature over one element while reading the values from another, or that accept an assertion signed by any certificate in the trust store rather than the expected one, can all be made to accept an assertion the identity provider never issued. Signature wrapping is the general name for the family, and it is an implementation defect in the service provider rather than a flaw in the standard. Missing checks on audience, recipient, validity window and single use are the same class of problem.

The other item worth recording is the signing key itself: whoever holds it can mint an assertion for any user in any federated application without touching those applications, so it belongs with the most sensitive material in the estate. Where single sign on is being rebuilt, OpenID Connect is the usual target. Reviewing existing trusts is part of the Microsoft 365 hardening work where federation trusts are reviewed.