What is a Role?

Unlock the power of secure, role-based access control in Nodinite. This page explains what a Role is, how it empowers integration experts and administrators, and how you can use Roles to enforce security policies and streamline user management.

✅ Centralized, role-based access control for all Nodinite features
✅ Enforce granular security policies for users and groups
✅ Full audit trail for sensitive operations
✅ Flexible assignment of permission sets for Log Views, Monitor Views, and Repository Model

On this page you will learn how to enable Role-Based Access Control (RBAC) and what a Role is in Nodinite.

• Get started now: How to Add or Manage Role user guide.

A Nodinite Administrator creates user-defined Roles in Nodinite. These Roles enforce different security policies for end-users. All user actions with potentially sensitive operations are Log Audited.

Above is an example of different Roles, each with unique access rights.

• Members of the Administrators role are Nodinite Administrators.

  The built-in role named Administrators cannot be renamed or deleted. Review the Access Management user guide for additional details.

• You must be a member of the Administrators role to manage Roles.
• End-users with appropriate rights can create and manage any number of Roles.
• Windows Active Directory Users can be members of a Role.
• Windows Active Directory Groups can be members of a Role.
• The Administrator assigns a permission set for the following Nodinite entities:
  • Log View permission set
  • Monitor Views permission set
  • Repository Model permission set

  Even the Nodinite Administrator must have the proper permission sets assigned to interact with these entities!

As defined by your access policy, you can allow members of, for example, the Economy role to have access only to selected Log Views. For each of these Log Views, you can apply different permission sets.

Here's an example of the Economy role with configuration options for Log Views.

About permission sets

Permission sets enforce security policies for end-users and are applied at the user-defined Nodinite Roles level.
For each Role, a Nodinite Administrator assigns different permission sets to the following Nodinite entities:

• Log View permission set
• Monitor Views permission set
• Repository Model permission set

A permission set can be applied globally or set uniquely on each entity. The following options exist:

• Inherited – Default (not enabled)

  Note

  Not allowed is NOT the same as Deny! It means the inheritance chain is honored.

• Allow – Access is granted.
• Deny – The feature is blocked from usage. Use this setting only for special cases.

Important

Regardless of other permission sets, a Deny always wins. Since entities are assigned to Roles, you should rarely need to use Deny. Instead, consider removing the entity from the Role.

Visual overview: How permission sets are inherited and applied in Nodinite.

Access right

For end-users to interact with the Repository Model, Monitor Views, and/or the Log Views, the Access permission must be set to Allow.
The highest level of a permission set is the Access right. The available values for this setting are:

• Allow – Members of the Role can access the entity
• Deny – Members of the Role cannot access the entity

Visual overview: How access rights and permission sets relate to Roles in Nodinite.

Examples

Next Step

Add or manage Log View
Add or manage Monitor View
Add or manage Role
Repository Model

Related Topics

Log View permission set
Monitor View permission set
Repository Model permission set

Access Management
Log Views
Monitor Views
Users