Its Web Browser Single Sign-On profile commonly lets an identity provider authenticate a user and send an assertion to a service provider that relies on that result.
In a service-provider-initiated flow, the service provider sends an authentication request and receives a SAML response through the user’s browser. The service provider validates the response and assertion, including the issuer, signature, recipient, audience, time conditions, request correlation, and subject-confirmation rules. Metadata commonly distributes entity identifiers, endpoints, supported bindings, and verification certificates between trusted parties.
Key points
Assertions and profilesAuthentication statements describe an authentication event; attribute statements carry selected subject data; profiles constrain how SAML messages are used for a particular purpose.
ValidationApply the selected profile’s complete processing rules rather than merely checking that some XML element is signed, and reject unexpected issuers, destinations, algorithms, and duplicate identifiers.
OperationsProtect signing keys, plan certificate rollover and clock tolerance, minimize attributes, test identity-provider outages, and distinguish identity-provider and service-provider sessions during logout.
Important limitationSAML is a flexible federation framework, not a guarantee of secure single sign-on. Unsafe XML processing, signature-validation mistakes, stale metadata, overbroad attributes, or weak local sessions can defeat a conforming-looking integration.