How SAML SSO works

In Niagara, SAML SSO is the main supported SSO scheme. The SAMLAuthenticationScheme, found in the saml palette, configures a station for SAML Single Sign-On (SSO). This scheme stores configuration properties required for communications with a SAML IdP (Identity Provider). With SSO, when a user tries to access the station and has not been authenticated, the station delegates authentication to the configured IdP.

The framework’s SAML scheme uses SAML 2.0 (Security Assertion Markup Language v.2.0). This is an open standard for exchanging authentication and authorization data in the form of encrypted messages passed between security domains. Specific protocols process the SAML request-response message exchanges over a secure connection. SSO via a web browser uses the SAML 2.0 Web Browser SSO profile to define how to use SAML messages and bindings between browser-connected Supervisor and remote controller stations.

With SSO, the process of SAML request-response message exchanges occurs between two system entities:

  • SP (Service Provider), which is a station typically running on a remote controller.

  • IdP (Identity Provider), which stores and maintains the authentication and authorization information.

SAML SSO uses an approach similar to LDAP authentication, which also stores authentication credentials external to the remote station.

Figure 1. SAML transaction steps


Beginning with step number one:

  1. A user directs their web browser to a URL hosted by a Niagara station with the SAML Authentication Scheme available.

  2. The SP generates a SAML request. Since the URL being requested requires authentication, the station opens a login window with various options. The user chooses to use SAML authentication. The station, acting as the SP, generates a SAML request that is unique to the user and to this particular session (visit).

  3. The SP redirects the browser to the SAML IdP, Single Sign On (SSO) URL. In Niagara, the SAML IdP can be another Niagara station, such as the Supervisor station or it can be a third-party SAML IdP server.

  4. The IdP receives the redirect, decodes it and prompts the user to log in to the IdP using their credentials.

  5. After the user successfully logs in, the IdP generates a SAML response to be sent back to the SP.

  6. The IdP encodes the SAML response and redirects the user’s web browser back to the SP’s Assertion Consumer Service (ACS) URL. The redirected URL contains the encoded SAML response and all the user data, which the SP is authorized to receive.

  7. The SP (ACS URL) verifies the SAML response.

  8. The SP grants access to the application and redirects the user’s web browser back to the original URL they attempted to access. This time, based on the IdP authentication, the application’s web page opens.

To configure a station for SAML SSO, in addition to the default authentication schemes (Digest and AxDigest), the station’s AuthenticationService must contain a properly configured SAML authentication scheme. The AuthenticationService also contains SSO configuration properties with which to tailor the authentication workflow.

Note: In Niagara, an added baja-UserPrototype component supports the UserService. SAML authentication requires this UserPrototype.
Note: In Niagara 4.10 and later, the WebService Same Site property value “Strict” is not supported for SAML authentication. If the property is set to “Strict” it will cause SAML authentication to fail.

The Components chapter of this guide provides more information about the WebService component, and user-authentication components: baja-UserService, saml-SAMLAuthenticationScheme, saml-SAMLAttributeMapper, and saml-SamlXmlDecryptor.