- 6 minutes to read

What is a Role?

A Role in Nodinite is a named collection of permissions that control what users can access and do within the system. Roles are the universal authorization mechanism - they work identically regardless of whether users authenticate via Windows or OAuth 2.0/OIDC.

Get started now: Add or Manage Role user guide.

Overview

Nodinite uses Role-Based Access Control (RBAC) to enforce security policies. A Nodinite Administrator creates Roles and assigns permission sets that define access to:

The key principle: Once a user authenticates (regardless of method), Roles determine what they can do. Authentication establishes identity; Roles enforce authorization.

All potentially sensitive operations are automatically recorded in the Audit Log for compliance and security tracking.

Why Roles Are Authentication-Mode Agnostic

Nodinite v7 supports two authentication modes, but Roles work identically in both:

Authentication Step Authorization Step (Same for Both Modes)
Windows Auth: User logs in with DOMAIN\username → matched to Users or Windows AD Groups → assigned to Roles Role permissions define access - User sees only the Log Views, Monitor Views, and Repository Model items permitted by their assigned Roles
OAuth 2.0/OIDC: User logs in via identity provider (Azure AD, Okta, etc.) → Claims matched to Policies → assigned to Roles Role permissions define access - User sees only the Log Views, Monitor Views, and Repository Model items permitted by their assigned Roles

No matter how users authenticate, once they're assigned to Roles, the permission system is identical.

How Users Are Assigned to Roles

The assignment mechanism differs by authentication mode, but the Role functionality is the same:

Windows Authentication Mode

In Windows Authentication mode, Roles are assigned to:

  • Users - Individual Windows domain accounts (e.g., CONTOSO\alice.smith)
  • Windows AD Groups - Active Directory security groups (e.g., CONTOSO\Finance Team)

Assignment is direct: Administrators explicitly add Users or AD Groups to Roles in Nodinite.

Role with Users and Groups
Example of a Role with Windows Users and AD Groups assigned.

OAuth 2.0 / OIDC Authentication Mode

In OAuth 2.0/OIDC mode, Roles are assigned to:

  • Policies - Groups of Claims (key/value pairs from the identity provider)

Assignment is dynamic: When a user authenticates, their Claims (from Azure AD, Okta, etc.) are matched against Policy requirements. If the Claims match a Policy's requirements, the user is assigned to that Policy's Roles.

Example:

  • Policy: "Finance Department Policy"
  • Claim Requirements: department=finance AND access_level=editor
  • Assigned to Role: "Finance Editor"
  • Result: User with department=finance and access_level=editor Claims → automatically gets "Finance Editor" Role

Role with Policies
Example of a Role with Policies assigned in OIDC/OAuth 2.0 mode.

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:

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.

graph TD subgraph "fal:fa-lock Permission set" ro1(fal:fa-door-open Global setting) ro2(fal:fa-gear Permission) ro1 --> |Inherit, Allow or Deny| ro2 end

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

Role Components: Permission Sets

Regardless of authentication mode, every Role defines access through three permission sets that control what users can see and do:

Permission Set Purpose Controls Access To
Log Views Define which log data users can view and query Transaction logs, error logs, custom log views
Monitor Views Define which monitoring resources users can observe and control BizTalk applications, Azure services, custom monitors
Repository Model Define which knowledge base content users can read or edit Documentation, configurations, business rules

Access Rights: Allow and Deny

For end-users to interact with these entities, the Access permission must be set to Allow.

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

Critical rule: Deny always wins - A Deny permission overrides all Allow permissions. If a user is assigned to multiple Roles and any Role has a Deny, the user is blocked from access.

graph TD subgraph "fal:fa-users-class Role" ro1(fal:fa-door-open Access) ro2(fal:fa-hard-drive Log Views) ro3(fal:fa-display Monitor Views) ro4(fal:fa-sitemap Repository) ro1 --> |Allow or Deny| ro2 ro1 --> |Allow or Deny| ro3 ro1 --> |Allow or Deny| ro4 ro2 -.- ro21[fal:fa-lock Permission Set] ro3 -.- ro22[fal:fa-lock Permission Set] ro4 -.- ro23[fal:fa-lock Permission Set] end

Every Role controls access through three independent permission sets for Log Views, Monitor Views, and Repository Model.

Examples: How Roles Work in Both Authentication Modes

The examples below show how Roles define the same types of permissions in both Windows and OIDC/OAuth 2.0 environments. The assignment mechanism differs (Users/Groups vs Policies), but the permission structure is identical.

Windows Authentication Mode Example

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

OIDC/OAuth 2.0 Mode Example

Policy Claims in Policy Role Log Views Monitor Views Repository
Finance User Policy department=finance
access_level=editor		 Finance Editor Finance-specific Log Views Finance Monitor Views Read rights on finance resources
IT Operations Policy department=it
access_level=admin
environment=production		 IT Operations All Log Views All Monitor Views with Remote Actions Full access to Knowledge Base
Developer Policy team=development
environment=test		 Developers Development Log Views Test/Dev Monitor Views Write access to documentation

Next Step

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

Permission Sets:

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

Windows Authentication Mode:

Users - Individual Windows accounts
Windows AD Groups - Active Directory groups

OIDC/OAuth 2.0 Mode:

Claims - Key/value authorization attributes
Policies - Groups of Claims

General:

Access Management - Authorization overview
Log Views
Monitor Views
Install Nodinite v7 - Authentication - Authentication modes