SAML is a product of the OASIS (organization) Security Services Technical Committee.
The critical aspects of SAML 1.1 are covered in detail in the official documents SAMLCore[1] and SAMLBind.
SAML has undergone one minor (V1.1) and one major revision (V2.0) since V1.0, which itself is a relatively simple protocol.
Warning: Implementers and deployers should note well that all code examples in this article are non-normative and for illustration purposes only.
SAML assertions contain statements that service providers use to make access control decisions.
In some cases, however, additional information is needed before a service provider can make an access control decision.
An attribute statement can indicate whether or not the principal has an affiliation of "student", which the service provider uses to allow or deny access (resp.)
In some situations, it may be preferable to associate the policy decision point with the identity provider.
In this case, the service provider passes a URI to the identity provider who asserts an authorization decision statement that dictates whether or not the principal should be allowed access to the secured resource at the given URI.
Other transport mechanisms besides HTTP are permitted, provided the protocol-independent aspects of the SAML SOAP binding are observed (see section 3.1.2 of SAMLBind[2]).
SAML 1.1 specifies two Web Browser SSO Profiles: The Browser/POST Profile relies on a "push" operation that passes an SSO assertion by value through the browser using HTTP POST.
Both SAML 1.1 profiles begin at the inter-site transfer service, which is managed by the identity provider.
In practice, a client accessing a secured resource at a service provider will be redirected to the inter-site transfer service at the identity provider, but the precise sequence of steps needed to accomplish this is not outlined by SAML 1.1.
To expedite processing by the assertion consumer service, two separate URLs are specified: These and other endpoint locations may be recorded in metadata files.
The Inter-site Transfer Service returns an HTML document containing a FORM element: where the TARGET parameter has been preserved from step 1.
Important: It is assumed that the principal has already established a security context at the identity provider, otherwise the Inter-site Transfer Service would be unable to provide an authentication statement in the SAML Response element.
The Assertion Consumer Service consumes the SAML Response element, creates a security context at the service provider and redirects the user agent to the target resource.
The identity provider completes the back-channel exchange by responding with a SAML assertion bound to a SAML SOAP message: In this case, the authentication statement includes a NameIdentifier containing the principal's e-mail address.