Multiple Credentials

User authentication

A Niagara system typically uses login credentials (user names and passwords) to authenticate a user. Whenever a connection to the platform or a station is attempted via Workbench, first a secure communication session is established using TLS (Transport Layer Security). After a secure platform or station connection is made, the Authentication window opens and asks for user credentials, which are verified against the user account.

Figure 4. Station authentication window

The Authentication window includes a checkbox to Remember these credentials. When checked, Workbench stores the credentials in encrypted format and uses them to automatically fill in the login credentials the next time the user logs in.

NOTE: This is a convenience mechanism. However, when the box is checked, anyone with access to that Workbench is able to log in using those credentials. For highly sensitive systems and privileged accounts, make sure that the box is unchecked.

System passphrase

System passphrase protects sensitive information stored in the system’s memory, hard disk and on the SD card in JACE-8000 controllers. When performing a new installation, the installation wizard prompts you to set a system passphrase for encryption purposes.

The system passphrase defaults to the factory default platform password. During commissioning, installers will be prompted to change the default system passphrase.

NOTE: Once the installation program sets the system passphrase, this step will not be presented again upon subsequent Niagara 4 installations.

To change the system passphrase, use the Platform Administration tool.

Restoring a station from a backup and transferring station files to a new location require the person performing the action to supply this encryption passphrase.

Once changed, the passphrase must be stored in a safe location from where it can be retrieved as needed.

Certificates private key

The framework supports TLS (Transport Layer Security) protocol, to provide secure networks using PKI (Public Key Infrastructure). It uses certificates to verify the identity of a server so that communication is trusted. Using digital certificates allows a seamless use of TLS (HTTPS) in a browser and Workbench, and provides both encryption (during data transmission) as well as server authentication.

A root CA (Certificate Authority) certificate is a self-signed CA certificate whose private key is used to sign intermediate and server certificates in a trusted certificate tree. If your company serves as its own CA, the system requires the creation of a password for the certificate's private key. This should be a strong password, which should be physically stored in a secure vault.

The Certificate Manager prompts for the private key password:

To export a certificate when creating a public root CA certificate
To backup certificates with their private keys
To create a CA certificate (root or intermediate) for importing into a client User Trust Store
To create a CSR (Certificate Signing Request) for a CA certificate (root or intermediate)
To sign a CA certificate