What is a Role?
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 are used to enforce different security policies for end-users working with Nodinite. All user actions with potentially sensitive operations are Log Audited.
Above is an example of different Roles, having different access rights.
- Members of the Administrators role is a Nodinite Administrator.
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 a member of the Role
- Windows Active Directory Groups can be a member of the Role
- The Administrator assigns the Role a permission set for the following Nodinite entities:
For the above, even the Nodinite Administrator must have the proper permission sets assigned to interact with the 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, different permission sets may be applied.
Here's an example of the Economy role with the configuration options for Log Views.
About permission sets
The permission sets are used to enforce a security policy for end-users working with Nodinite, and these are applied on the user-defined Nodinite Roles-level.
For each Role; A Nodinite Administrator assigns the different permission sets on the following Nodinite entities:
A permission set can either be applied on the Global level or set uniquely on the entity directly. The following options exist:
- Inherited - default (which means not enabled)
Note
Not allowed is NOT the same thing as a Deny(!) as it merely means; Honour the inheritance chain.
- 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 win. Since the entities are assigned to the Roles, you should rarely have to use the Deny setting. Instead of denying access, consider removing the entity from the Role instead.
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 can NOT access the entity
Examples
| Windows User | AD Group | Role | Log Views | Monitor Views | Repository |
|---|---|---|---|---|---|
| Agni Waseem | - | Economy | Find Order by Order Id | Get alerts, troubleshoot if the daily exchange-rate failed to appear before 08:15 | Read rights on monitored resources |
| - | SE_IT_Operations | IT-Operations | Can use and manage all Log Views | Get alerts from all detected problems and can perform Remote Actions to swiftly resolve problems | Maintains the Knowledge base Articles and modifies the custom metadata fields |
| Joe | - | Production | Denied | A single Monitor View with the right to restart the printer service on Windows Server "SEDC01" | Can read the knowledge base article with the restart instructions |
| John | SE_DevTeam NO_DevTeam | Developers | Denied | Denied | Writes the Knowledge base Articles and contributes with the documentation for new systems integrations solutions |
Next Step
Add or manage Log View
Add or manage Monitor View
Add or manage Role
Repository Model
Related
Log View permission set
Monitor View permission set
Repository Model permission set