Authentication schemes

An authentication scheme verifies that a user is authorized to access a station. All authentication requests are routed through the system’s AuthenticationService.

These authentication schemes are provided as standard components of the AuthenticationService:

DigestScheme (default authentication scheme) never sends a user password directly to the station. Instead, it sends proof that the user knows the password. This scheme connects a Niagara 4 Supervisor to a Niagara 4 station.
AXDigestScheme (default authentication scheme) passes several messages back and forth to prove that the client knows the password. It never actually transmits the client’s password, which helps protect the system if another layer of security, such as secure TLS communication, fails.
This scheme provides compatibility with stations running previous software versions. Stations running NiagaraAX must have been upgraded with the following security updates: 3.8, 3.7u1, 3.6u4, or 3.5u4. This scheme allows a Niagara 4 supervisor to connect to a NiagaraAX station.
HTTPBasicScheme performs HTTP-Basic authentication using standard HTTP headers. It only works via the web, and is intended for clients that cannot use cookies. This authentication scheme sends the user name and password over the connection. This component is located in the baja palette.

Both the DigestScheme and AXDigestScheme use SCRAM-SHA (Salted Challenge Response Authentication Mechanism) to secure the transmission of clear-text passwords over a channel protected by TLS (Transport Layer Security). This authentication mechanism conforms to the RFC 5802 standard as defined by the IETF (Internet Engineering Task Force). It is the same mechanism for both schemes. The main difference between the two schemes has to do with the order of operations that is required to support the differences between NiagaraAX and Niagara 4.

Additional schemes

A station can support more than one authentication scheme. Schemes may be added to or removed from the AuthenticationSchemes container in the AuthenticationService under the Services container.

Each user account is associated with a specific scheme. This allows some user accounts to use one scheme, while other accounts use different schemes. For example, a digest scheme is appropriate for human users, whereas a Certificate or HTTP-Basic scheme is more appropriate for devices. The system supports only schemes that have been added to the AuthenticationService.

CAUTION: Deleting a scheme may leave your users with an invalid reference to a non-existent scheme.

Additional schemes are in the baja, ldap, and saml, and clientCertAuth palettes. Other schemes may be found in other palettes, and developers may create new authentication schemes. Third-party schemes may also be available.

The following schemes (which require the use of an LDAP server and additional properties, which must be configured) are in the ldap palette:

LdapScheme
KerberosScheme

Client Certificate Authentication Scheme

In Niagara, the clientCertAuth palette contains the ClientCertAuthScheme, which provides authentication using a client certificate. Each user’s client certificate with its public key is directly bound to the user object. Each certificate’s public key matches its private key. During a login attempt, the system prompts the user to upload his or her certificate with its private key. To authenticate the user, the system verifies that the private key matches the public key stored on the user object.

Google Authentication Scheme

The gauth palette contains the GoogleAuthenticationScheme (Google Auth Authenticator), which provides two-factor authentication using a password and single-use token sent to the user’s mobile phone. The authenticator app is time based and automatically updates the tokens every 30 seconds.

In addition to adding the GoogleAuthenticationScheme to the standard AuthenticationService, this scheme requires that the Google Authenticator app be installed on the user’s phone.

SAML Authentication Scheme

The saml palette contains the SAMLAuthenticationScheme, which can be added to the AuthenticationSchemes container to configure the station for SAML SSO (Single Sign On). Authentication schemes that support SSO allow supported users to bypass entering a username in the pre-login step. Instead, the users are redirected to an alternate login page.