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 to ensure that user identities are centrally managed and delivered to application providers in a secure and standard way. The SAML specification addresses this need by:
  • Identifying the roles of the parties involved in exchanging authentication data
  • Specifying a standard way that authentication data is structured and delivered.

The current version of the specification is SAML 2.0. The concepts described in this topic 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.

For more information about SAML, see the official SAML technical overview.

Participants

In a typical SAML-based SSO workflow, there are three key participants:
  • A user is also called a principal, who needs to access a service and whose identity needs to be authenticated.
  • A SAML service provider is typically a web application that provides services to authenticated users and can process SAML assertions.
  • An identity provider, is also known as a SAML authority, who 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, this is a SAML-based SSO service provider(SP)-initiated workflow:
  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, then 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, also referred to as an SP-initiated flow. Another type of workflow, which is less common, is 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 pertains to specific authentication use cases.

A protocol is a standard way to perform an operation. For example, the authentication request protocol that service providers must use while sending 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 and 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 using 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 or a SAML token. When an identity provider authenticates a user's identity, it generates a SAML assertion and returns it 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, and so on.
  • Information about the user, (referred to in the assertion as the subject), such as the Name ID of the user (joe@hiscompany.com) and the format of the Name ID (email address, Windows domain qualified name, Kerberos principal name, and so on).
  • The validity period of the assertion; may include conditions such as not before or after a specified date and time.
  • Optional attributes that can be customized based on your needs. A typical use of these optional attributes is to pass information about the user's roles.

A SAML response can be signed or unsigned, and a SAML assertion can be signed or encrypted. The service provider and the identity provider must be configured and their configurations must be exposed through metadata so that there is an 'agreement' on the signatures and encryption.

Metadata

Because digital signatures and encryption can be used in SAML messages, the service provider and the identity provider must establish trust, in advance, through metadata defined in an XML file. If the providers support URL access to the metadata, they can exchange metadata using URLs.

The metadata of an identity provider includes information such as:
  • The entity ID, a unique identifier for the identity provider, typically an endpoint or URL.
  • Supported HTTP bindings (such as POST or Redirect) and the SSO URL for each binding.
  • The identity provider's X.509 public-key certificate 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, typically an endpoint or URL.
  • The service provider's X.509 public key certificate, used by the identity provider to decrypt SAML request messages.
Note: The values of a few elements 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.