The growth in the adoption of SAML is closely linked to the proliferation of SaaS applications. As users begin to access the bulk of their applications over the web, enterprises need a way to ensure that user identities are centrally managed and delivered to application providers in a secure, standard way. The SAML specification addresses this need by identifying the roles of the parties involved in exchanging authentication data and specifying a standard way that authentication data needs to be structured and delivered.
The current version of the specification is SAML 2.0. The concepts described in this section are a small subset of the SAML specification; they relate to only those elements that you need to understand to implement SAML in PAS for OpenEdge.
In a typical SAML-based SSO workflow, there are three key participants:
A user, also called a principal, who needs to access a service and whose identity needs to be authenticated.
A SAML service provider, which is typically a web application that provides services to authenticated users and can process SAML assertions.
An identity provider, also known as a SAML authority, that manages user identities and provides authentication and authorization services. Examples of identity providers include Okta, OneLogin, and Active Directory Federation Services.
In addition, a user may require a user agent, such as a browser, to access the desired services.
Workflow
At a high-level, a SAML-based SSO workflow proceeds as follows:
1. A user tries to access a resource or service hosted by the service provider.
2. The service provider creates a SAML request and redirects the user's browser to a configured SSO URL that belongs to an identity provider.
3. The identity provider processes the SAML request and presents an authentication challenge such as a login page or a two-factor/multi-factor authentication form to the user.
4. The user responds to the authentication challenge.
5. If the identity provider is able to authenticate the user, it sends a SAML response containing a SAML assertion to the user's browser and redirects the browser to an Assertion Consumer Service (ACS) URL that belongs to the service provider.
6. The service provider receives the SAML response and validates the SAML assertion. It then grants access to the requested service or resource.
This type of workflow is called Service Provider Initiated SSO. There is also another type of workflow that is less common, called Identity Provider Initiated SSO, where a user logs in to the identity provider first and then accesses a service provider page.
Protocols, bindings, and profiles
The SAML specification caters to a wide range of authentication requirements. As a result, it defines a number of protocols, bindings, and profiles, each of which pertain to specific authentication use cases.
A protocol is a standard way to perform an operation. For example, the SAML specification defines an Authentication Request protocol that service providers must use when they need to send authentication requests to an identity provider.
A binding defines how a protocol message must be carried over a transport layer. The SAML specification defines bindings for various types of HTTP as well as SOAP requests.
A profile is a combination of bindings and protocols. For example, the Web Browser SSO Profile defines that when a service provider needs to authenticate a user who is trying to access a resource via a browser, it should send an Authentication Request message to an identity provider using either the HTTP Redirect, HTTP POST, or HTTP Artifact binding.
SAML assertions
At the core of SAML is a SAML assertion (also called a SAML token). When an identity provider authenticates a user's identity, it generates a SAML assertion that it returns as part of a SAML response. A SAML assertion in the Web Browser SSO Profile contains the following:
Information about the assertion itself, such as the SAML version, the timestamp when the assertion was issued, the identity provider that issued it, etc.
Information about the user (referred to in the assertion as the subject). The assertion typically specifies the Name ID of the user (joe@hiscompany.com) and also specifies the format of the Name ID (email address, Windows domain qualified name, Kerberos principal name, etc).
Validity period of the assertion; may include conditions such as not before or after a specified date and time.
An <AudienceRestriction> element that specifies which URIs are valid for the assertion. The ACS URL must be listed as one of the audiences in this element.
Optional attributes that can be customized based on your needs. A typical use of these optional attributes is pass information about the user's roles.
A SAML response can be signed or unsigned and a SAML assertion can be signed and/or encrypted. The service provider as well as the identity provider must be configured so that there is an 'agreement' on the signatures and encryptions. This is usually done by exposing configurations through metadata.
Metadata
Since digital signatures and encryption can be used in SAML messages, the service provider and the identity provider must establish trust in advance. This is typically done through metadata defined in an XML file.
The metadata of an identity provider includes information such as:
The entity ID--a unique identifier for the identity provider. This is typically an endpoint or URL.
Supported HTTP bindings (POST, Redirect, etc) and the SSO URL for each binding.
The identity provider's X.509 public key certificate that is used by the service provider to decrypt SAML response messages.
The metadata of the service provider includes information such as:
The entity ID--a unique identifier for the service provider. This is typically an endpoint or URL.
The Assertion Consumer Service (ACS) URL. This is the location where the service provider receives SAML response messages. The ACS URL is typically sent in the SAML request message as well.
The service provider's X.509 public key certificate that is used by the identity provider to decrypt SAML request messages.
There are a few elements whose values must match in the metadata of the identity provider and the service provider. For example:
The Name ID format of the user whose identity needs to be authenticated.
The hashing algorithm if digital signatures are being used.
A user, also called a principal, who needs to access a service and whose identity needs to be authenticated.