Manage User Security and Permissions

Before users can start using NEXUS, an administrator must create new users for them in NEXUS IC and assign the required permissions to them.

See the following documentation for detailed information about security and permissions:

Caution

  • To log in to the database, a NEXUS login must have Read permissions (as a minimum) to the Personnel table, so ensure that Business Object ‣ System Table ‣ Security Permissions is set to Read for all users.

  • Setting Deny All on the Special Permission ‘Security’ will disable the Database ‣ Security main menu item, regardless of what permissions have been set on the Security Permissions tables.

Generic Permissions

Generic permissions are managed on a table-by-table basis, rather than on a screen-by-screen basis. For example, if you want a user to be able to add or delete assets, you should edit the user or the user’s group and give them Read / Write permission on the system table ‘Asset’. If you want to enable this user or group only to view assets but not to add or delete them, give the user or group Read permission.

Inheritance of Permissions

Each user has their own permissions, plus they inherit the permissions of any user group they are a member of. If a user has their own permissions, these override the permissions they inherit from any user group.

Permissions can be inherited in two ways:

  • From the permissions of the user groups that the user is a member of.

  • From the relevant parent security item in the hierarchy of permissions. The parent security item can be the direct parent of the security item in the hierarchy of Business Object permissions, or a Special Permission can be counted as a parent too. For example, permissions to access the Anomaly Action system table will be inherited from the parent Anomaly unless you do not specifically change the settings for this table:

    _images/database.security.permission.hierarchy.png

When multiple permission levels apply, they are prioritised as follows:

Priority

Permission Level

1

User-specific permission

2

Permissions inherited from user group

3

Permissions inherited from parent security item or special permission

Determining Permissions

To figure out the permission for an item, NEXUS proceeds as follows:

  1. It retrieves the permissions specific for the user.

  2. If no user-specific permissions have been set up, it checks the permissions of all groups the user is a member of.

  3. If there are no resultant permissions set, then NEXUS finds the parent of the security item and checks permissions on that. If necessary, a Special Permission will be counted as a parent. For example, if an Asset Information form has no explicit permissions (because it is set to Inherited), then NEXUS will use the Asset Information special permission.

Permission Types

The following types of permissions can be applied:

Permission Type

Description

Read/Write

Allows a user to both view and modify the contents of a table or item. This permission is additive and overwrites Read and Inherited.

Read

Allows a user to view the contents of a table or item but not make any changes. This permission is additive and overwrites Inherited.

Inherited

It means that no specific permissions have been applied for this security item, for this user or user group. In case of a user, permissions will be inherited from the user group as described above. In case of a user group, Inherited means that no permissions are set up, that is, the permission will be Deny All.

Deny

Denies Write permissions. This permission is subtractive and overwrites Read/Write and Inherited.

Deny All

Denies Read/Write permissions. This permission is subtractive and overwrites all other permission types.

For example, if a user is a member of several user groups, and their permission in one user group is Read, in the other it’s Read/Write, then Read/Write will apply. If, however, the permission is Deny All in any of the user groups, Deny All will apply.

Asset-Specific Permissions

You can also set up permissions on the level of assets. For more information, see Asset Security.

Create a New User

  1. In the menu, navigate to Database ‣ Security….

  2. On the Users tab, choose Add.

  3. In the Add Personnel dialog, on the Personnel tab, enter the name of the user and any other personal details (such as address, email, phone number, position) as required.

  4. On the Login tab, specify the login name, which will be used as a username when logging in. For example, if the name of the user is “Sample User”, the login name can be “sample.user”.

  5. On this same tab, tick the Enabled checkbox and create a password for the user using the Change Password button. If you want the user to change their password upon login, tick the Force Password Reset checkbox.

  6. If required, you can also enable Single Sign-On (SSO) on this tab (see Set Up Single Sign-On (SSO)).

  7. On the Member Of tab, select the security group to which you want to assign the new user (if required).

  8. Click OK.

Create a New User Group

  1. In the menu, navigate to Database ‣ Security….

  2. On the Groups tab, choose Add.

  3. In the Add Security Group dialog, on the Security Group tab, enter the name of the user group and if required, a description.

  4. On the Permissions tab, set up the permissions as required (see Set Up Permissions for User/User Group).

  5. Click OK.

Set Up Permissions for User/User Group

Once you have a user or user group created in your database, you can assign permissions to them as described below. By default, most permissions are inherited based on the permission management rules described above.

  1. In the menu, navigate to Database ‣ Security….

  2. On the Users or Groups tab, select the relevant user or user group and click Edit in the toolbar, or just double-click the item to open the dialog for editing.

  3. In the dialog that appears, go to the Permissions tab.

  4. Select either a business object or a special permission for which you want to make permission settings.

  5. Right-click the selected item and in the drop-down menu, select the required permission under Permission.

    For example, if you want to change the Security permissions for a user group from Deny All to Read / Write, proceed as follows:

    _images/database.security.permissions.png

  6. Click OK.

Set Up Single Sign-On (SSO)

You can configure a user to use Window domain credentials to log in to Integrity Centre. This is smoother as users will not need to enter a separate password when they start Integrity Centre — instead Integrity Centre will query the domain controller to check the user’s credentials. To configure this:

  1. Edit the user and go to the Login tab.

  2. Click the ellipsis button under ‘Windows User’.

  3. In the resulting ‘Select User’ dialog, you may need to click Locations and select Entire Directory.

  4. Type the user’s full or partial Windows login name, and click Check Names, choose the appropriate name from the list and click OK.

Note

  • This configuration is relevant for on-premises deployment only. For information about setting up SSO for Software as a Service (SaaS), see Software as a Service (SaaS) Deployment.

  • Windows domain credentials may not work when you are away from the Windows domain.

Tip

You can always bypass the automatic connection to the database using domain credentials by holding down the Shift key as Integrity Centre starts up.

Force Reset Password

If you are not using SSO, you can force a user to reset their NEXUS password on their next login. (You would typically do this when you have just created a user account and have set a temporary password.) On their next login, the user will be required to enter their old password and then choose a new one before they can proceed.

To enable this feature, under Database ‣ Security…, go to the Login tab and tick the Force Password Reset checkbox.