3.1.6.9. Security

The Security section is where you define profiles and security objects such as users, roles, ACLs that allows us to define different user roles, configure the access permissions for the roles, manage the API Key, configure the related metadata for Oauth2.0, etc.

3.1.6.9.1. Admin Users

In the Admin Users section ON CMDB > Security > Admin Users, you can create administrator users, that is to say, we will manage those users who will have access to the OpenNAC Enterprise Administration Portal. From this view, you can create different users and configure parameters such as email, role, phone, etc.

../../../_images/security_adminusers.png

These users can be created on different User Data Sources and you can assign them different roles:

administrator
otpmanager
readonly
audit
operator
userDeviceViewer

These roles are used to manage access to the OpenNAC Enterprise Administration Portal so that each user can have different permissions when navigating through the different sections of the administration portal. Refer to the Roles section for role configuration.

The password expiration date displayed in the last column, was previously configured in the vars Configuration > Configuration section.

Note

If a user with a specific role switches to another role, they will automatically be logged out to renew their permissions. The next time the user logs in, the new permission for the assigned role will apply.

../../../_images/security_adminusers_create.png

Warning

All passwords must comply with the following password policy:

Password length: minimum 8 characters.
One or more lowercase characters.
One or more uppercase characters.
One or more numbers.
One or more special characters.
It cannot be the user’s name.
It cannot be a car license plate.
None of the last 3 passwords used can be reused.

In this configuration window, you can also enable the “Request OTP to authenticate user” flag to enforce an additional layer of security during the authentication process by requiring users to provide a One-Time Password (OTP).

3.1.6.9.2. Local Users

In the Local User section ON CMDB > Security > Local Users, you will find two subsections: Provisional local users and Autogenerated local users.

In the Provisioned local users section you can register local users and its information will be stored in the OpenNAC Enterprise database.

../../../_images/security_localusers.png

To add a new user, click on the Add new button, and a pop up window where we can register the following information will appear:

../../../_images/security_localusers_create.png

Warning

All passwords must comply with the following password policy:

Password length: minimum 8 characters.
One or more lowercase characters.
One or more uppercase characters.
One or more numbers.
One or more special characters.
It cannot be the user’s name.
It cannot be a car license plate.
None of the last 3 passwords used can be reused.

In this configuration window, you can also enable the “Request OTP to authenticate user” flag to enforce an additional layer of security during the authentication process by requiring users to provide a One-Time Password (OTP).

If you want to add more properties to the user, you can create custom properties by clicking on the Set User custom properties button. There, you can define the name of the property (it will be the variable name that will be stored on the database) and the label that we will associate with the new property.

../../../_images/security_localusers_customproperties.png

Once we have defined those custom properties, if we add a new user or edit an existing one, a new field with the specified label will appear on the pop-up window.

../../../_images/security_localusers_addnew_withcustomproperties.png

If we forget the password, we can select the desired user and click the Send password email, and a new password will be sent to the configured mail.

In the Autogenerated local users section, we will find the users that had been registered through the different workflows from the Captive Portal.

../../../_images/security_localusers_autogenerated.png

3.1.6.9.3. ACLs

On ACLS ON CMDB > Security > ACLs is possible to define the capabilities used by the roles (formally named ACLs). This security method allows us to control which actions can be carried out by the user. These ACLs are also valid and used to provide security to the API as well. This ACL defines which methods are available to be used through HTTP connection and its classes and description.

We can also edit the existing ACLs by selecting the desired ACL and clicking the Edit button. A pop-up window will appear so that we can select the different roles to which we want to give access to the different actions.

Here we can see the current ACLs, the families, its methods and the roles that can use the different capabilities.

../../../_images/oncmdbsecurityacls1.PNG

../../../_images/oncmdbsecurityacls2.PNG

../../../_images/oncmdbsecurityacls3.PNG

3.1.6.9.4. Roles

In the ON CMDB > Security > Roles section , you can generate Administration Portal profiles (roles) and associate them with admin users. This functionality allows administrators to provide different views for particular uses by customizing the Administration Portal access and the permissions that are given to a particular user.

In this view we can see the default roles with basic permissions:

administrator: A privileged role from where we will be able to perform all types of actions in the administration portal.
otpmanager: This role will only have access to manage functions related to the OTP such as regenerate OTP, send emails with the OTP, configure its TTL, etc.
readonly: This role does not have permissions to create, add, modify or delete any object in the administration portal, so it will only be able to read the objects that are already created.
audit: Role with permissions to audit logs. This role will be able to check all the different logs in the administration portal related to the different functionalities of the solution.
operator: Role with permissions to operate on the different menus but with a privilege level lower than an administrator. In this case, we will not be able to make modifications to database users, import new objects, etc.
userDeviceViewer: A role with privileges to manage only User Devices within the CMDB.

Note

You can modify the permissions of all roles, except for the administrator role, to suit the needs of each environment.

To create a custom role, click the Add new button:

../../../_images/security_role_create.png

Define the role name and its description. When creating a new role, the minimum permission are assigned through ACLs. To manage those permissions, select the desired role and click on the Manage role button.

../../../_images/security_role_manageroles.png

In this view, the administrator can see and select all the OpenNAC Enterprise Administration Portal menu options with their available permissions, allowing you to manage the permissions assigned to each specific role.

The administrator can enable and disable different views and menus in the Administration Portal and manage the various ALCs (permissions to edit, add, delete, etc.) across different sections of the Administration Portal.

3.1.6.9.5. API Key

In the API Key section ON CMDB > Security > API Key you can generate different API Keys and associate them with different devices. This API Key is a security method that allows us to control network access to the ON Core API. The API Key must be defined using the source IP of the users or network devices that require communication with the ON Core API.

To generate a new API Key, click on the Add new button. As soon as the source IP is added a security token is automatically created. If you want to interact with the product through it, you must use the API to query the API classes.

If there is more than one node that needs to have access to the API we will select the option Enable API Key for any source IP, else, we will enter the VPNGW IP in Enable API Key only for source IP.

One of the main use cases for the API Keys is third party integrations (NGFW, SIEM, AVS, PATCHING, MDMS, etc.) and our own integration. With this API Key, you do not need user/password to interact with OpenNAC Enterprise technologies.

3.1.6.9.6. OAuth 2.0

In the ON CMDB > Security > OAuth 2.0 section, you can perform OAuth 2.0 client configurations. OAuth 2.0 is an open standard for secure, delegated authorization, allowing one application to access another application or user’s data without sharing credentials. If you want to add a new application or service to access user’s data using OAuth 2.0, you can configure it in this section.

To configure a new client, click on the Add new. It will display he following fields:

Name: intuitive name the for client you are configuring.
Client IP: The IP address used by your client for making requests.
REALM: A security context or scope for your client’s operations.
State: A security feature for preventing cross-site request forgery.
Client ID: A unique identifier for your client application.
Client secret: A confidential key for client authentication.
Scope: Permissions and access levels your client requests.
Redirect URI: Where the user is sent after granting permissions.
Public Key: Used for verifying OAuth tokens or encrypting data.

See the Integrations > OAuth 2.0 section for more information about this authorization protocol.