The Security Assertion Markup Language (SAML) is an open standard for sharing security information about identity, authentication and authorization across different systems. SAML is implemented using the Extensible Markup Language (XML) standard for sharing data. The SAML framework enables Single Sign-on (SSO), which in turn allows users to log in once, and their login credential can be reused to authenticate with and access other different service providers. It defines several entities, described in the following table, including end users, service providers (SP), and identity providers (IdP), and is used to manage identity information.
| Entity | Description |
| End user | An end user is an entity requiring authentication prior to being allowed to use an application. |
| Identity provider (IdP) | Performs authentication and passes the user’s identity and authorization level to the service provider. For example, Active Directory Federation Services (ADFS). |
| Service provider (SP) | Trusts the identity provider and authorizes the given user to access the requested resource.. With SAML 2.0, a PowerScale cluster is a service provider. |
| SAML Assertion | XML document that the identity provider sends to the service provider that contains the user authorization. |
The Windows Active Directory Federation Services (ADFS), for example, is one of the ubiquitous identity providers for SAML contexts.
OneFS 9.5 introduces SAML-based SSO for the WebUI to provide a more convenient authentication method, in addition to meeting the security compliance requirements for federal and enterprise customers. In OneFS 9.5, the WebUI’s initial login page has been redesigned to support SSO and, when enabled, a new ‘Log in with SSO’ button is displayed on the login page under the traditional username and password text boxes. For example:
OneFS SSO is also zone-aware in support of multi-tenant cluster configurations. As such, a separate Identity Provider can be configured independently for each OneFS access zone.
Under the hood, OneFS SSO employs the following high level architecture:
In OneFS 9.5, the SSO operates through HTTP REDIRECT and POST bindings, with the cluster acting as the Service Provider.
There are three different types of SAML Assertions – authentication, attribute, and authorization decision.
- Authentication assertions prove identification of the user and provide the time the user logged in and what method of authentication they used (I.e., Kerberos, 2 factor, etc.)
- The attribution assertion passes the SAML attributes to the service provider – SAML attributes are specific pieces of data that provide information about the user.
- An authorization decision assertion says if the user is authorized to use the service or if the identify provider denied their request due to a password failure or lack of rights to the service.
SAML SSO works by transferring the user’s identity from one place (the identity provider) to another (the service provider). This is done through an exchange of digitally signed XML documents.
A SAML Request, also known as an authentication request, is generated by the Service Provider to ‘request’ an authentication.
A SAML Response is generated by the Identity Provider and contains the actual assertion of the authenticated user. In addition, a SAML Response may contain additional information, such as user profile information and group/role information, depending on what the Service Provider can support. Note that the Service Provider never directly interacts with the Identity Provider, with a browser acting as the agent facilitating any redirections.
Since SAML authentication is asynchronous, the Service Provider does not maintain the state of any authentication requests. As such, when the Service Provider receives a response from an Identity Provider, the response must contain all the necessary information.
The general flow is as follows:
When OneFS redirects a user to the configured IdP for login, it makes an HTTP GET request (SAMLRequest), instructing the IdP that the cluster is attempting to perform a login (SAMLAuthnRequest). When the user successfully authenticates, the IdP responds back to OneFS with an HTTP POST containing an HTML form (SAMLResponse) that indicates whether the login was successful, who logged in, plus any additional claims configured on the IdP.
On receiving the SAMLResponse, OneFS verifies the signature using the public key (X.509 certificate) in to ensure it really came from its trusted IdP and that none of the contents have been tampered with. OneFS then extracts the identity of the user, along with any other pertinent attributes. At this point, the user is redirected back to the OneFS WebUI dashboard (landing page), as if logged into the site manually.
In the next article in this series, we’ll take a detailed look at the above procedure to deploy SSO on a PowerScale cluster: