What it means
SAML commonly enables enterprise browser single sign-on. An identity provider authenticates the user and issues a signed assertion containing identity and related attributes. The service provider validates the assertion and establishes a local session.
How it works
Security depends on trusted metadata, certificate and key management, signature validation, audience and recipient checks, time conditions, assertion identifiers, and safe browser bindings. SAML assertions are not general-purpose API access tokens and should be accepted only by their intended service provider.
An employee opens a business application, is redirected to the corporate identity provider, signs in, and returns with a SAML response. The application validates the response and grants a session based on approved attributes.
Practical focus
- Validate signatures, issuer, audience, recipient, destination, and time conditions
- Protect signing keys and manage certificate rollover
- Restrict accepted identity providers and metadata sources
- Map group and role attributes to local permissions conservatively
Common mistakes
- Checking only that an assertion is signed without validating who signed it
- Accepting assertions intended for another service
- Using long-lived assertions or broad attribute mappings
Certification relevance
This subject appears in or supports the following certification bodies of knowledge: