Glossary

Certificate A PKI (Public Key Certificate) or digital certificate is an electronic document used to prove ownership of a public key. The certificate includes information about the key, the identity of its owner, and the digital signature of an entity that verified the validity of the certificate’s contents. If the signature is valid, and the client can trust the signer, the client can be confident that it can use the public key contained in the certificate to communicate with the server.
Certificate Authority (CA) An entity that issues the digital certificates used to certify the ownership of a public key by the named subject of the certificate. This allows system users to rely upon signatures or assertions made by the private key that corresponds to the certified public key. In this relationship model, the party that relies on the certificate trusts that the subject (owner) of the certificate is authentic because of the relationship of both parties to the CA.
chain of trust Also called a web of trust, certification path, or trusted certificate tree is an approach to server verification that uses a self-signed certificate owned by a CA (Certificate Authority) to begin the authorized relationships. The private key of this root CA certificate signs a company’s server certificate(s). Intermediate certificates may be used to further isolate relationships, such as by geographic location or corporate division.
Distinguished Name A Distinguished Name (DN) is a string that uniquely identifies an entry in the LDAP directory. It’s comparable to a path in a file system. The CN portion of the DN is comparable to a file name.

As it applies to SAML attribute mapping, an Identity Provider may return a DN (e.g. CN=userGroup, OU=Users, DC=domain, DC=net) for the prototypeName attribute. More details on SAML authentication and attribute mapping are available in the “Single Sign On” section of the Niagara Station Security Guide.

key A digital key is a very large, difficult-to-predict number surrounded by a certificate. Keys serve these purposes: 1) The public key of a root CA certificate in a client’s System or User Trust Store verifies the authenticity of each server. 2) The private key of a trusted root CA certificate may sign other certificates. 3) After server authentication, matching public and private keys encrypt and decrypt data transmission.
NEQL Niagara Entity Query Language provides a simple mechanism for querying objects with tags. Whereas BQL supports the tree semantics and pathing of Workbench component space (for example parent.parent) and BFormat operations, NEQL queries only for tags using the Niagara 4 tagable and entity APIs.
object An object is the base class required for all system entities that conform to the baja model. Objects group information used to construct a model that includes building devices, virtual devices, individual points, users, system features and services. Objects appear in the Nav tree as files, modules, installers, administrators, copiers, drivers and apps. Metadata associated with objects, including categories, roles (permissions), and hierarchies, provide access control and configuration options to manage automated buildings efficiently.
pem file A Privacy Enhanced Mail Certificate (PEM) is a certificate file for authenticating a secure server. It may contain: a private key and various certificates, such as a certificate authority (CA) certificate, primary certificate, and intermediate certificate. These certificates make up the chain of trust.
permission The right to access a component slot, folder, file or history. Three rights may be granted: the right to read information provided by the object, the right to write (change) the object, and the right to invoke an action on the object. Rights are granted using the Role Manager’s permissions map. Permissions are applied to users by assigning each user a role. A super user is automatically granted every permission in every category for every object.
permission level A slot config flag that indicates who is allowed to access the slot. When unchecked (the default) at least admin-Read (R) permission is required (as defined in the Role Manager’s permissions map). When checked a user with a minimum of operator-read permission (r) may access the slot.
role A logical grouping that is assigned as metadata to system users (human and machine) for security purposes. For example, roles may be used to group users as administrators (admin), regular users (user), and operators (operator).

Roles speed the management of permissions for a large number of users. The permissions of a group of users that share the same role can be updated by changing the role’s permissions instead of updating each user’s permissions individually.

You manage roles using the RoleService.

signature A digital signature combines a unique hash that is created using a cryptographic algorithm (such as SHA-512) with a public key. This is done by using a matching private key to encrypt the hash. The resulting signature is unique to both the certificate and the user. Finally, the signing process embeds the digital signature in the certificate.
user permission See permission.