- 7 minutes to read

What is a Role?

A Role in Nodinite is a named collection of permissions that controls what users can see and do. Roles let business users solve their own problems, safely: each team gets exactly the Log Views, Monitor Views, documentation, and diagrams it needs, and nothing more.

  • ✅ One authorization model for Windows and OIDC/OAuth 2.0 authentication
  • ✅ Four permission sets: Log Views, Monitor Views, Repository Model, C4 Diagram Sets
  • ✅ Cumulative permissions across Roles, with Deny always winning
  • ✅ Every sensitive action recorded in Log Audits
  • ✅ The same Roles also apply to the Web API and the MCP Endpoint

Get started now: Add or manage Role. All Roles are listed in the Roles Overview.

Overview

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

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

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

The Built-in Administrators Role

Every installation has a built-in Administrators Role. Its members have access to all features, including the Administration menu and Access Management, and the Role can't be edited or deleted. Keep it in the DefaultRolesInViews System Parameter so administrators can reach every new Log View, Monitor View, and C4 Diagram Set.

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, Repository Model items, and C4 Diagram Sets 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, Repository Model items, and C4 Diagram Sets 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; the Role functionality is the same.

Windows Authentication Mode

In Windows Authentication mode, Roles are assigned to:

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

Finance Role editor General tab with one User and one Windows AD Group assigned, next to the four permission tabs
The Finance Role with a Windows User and a Windows AD Group; use Edit on each card to change the members. The Log, Monitor, C4 Set, and Repository Permissions tabs hold the permission sets.

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 each Policy. A user who has all Claims of a Policy gets that Policy's Roles.

Example: Finance Department Policy

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

Roles tab in the Policy editor with the Administrators Role selected
In OIDC/OAuth 2.0 mode, you pick the Roles for a Policy on the Policy's Roles tab, see Add or manage Policy.

About Permission Sets

Permission sets enforce security policies for end-users and are set on each Role. For each Role, a Nodinite Administrator sets:

A permission can be set globally (for all items of a kind) or on each item. The values are:

  • Inherited – Default; the global setting decides.

    Note

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

  • Allow – Access is granted.
  • Deny – The feature is blocked. 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 Deny. Instead, consider removing the entity from the Role.

flowchart LR G["fa:fa-globe Global setting"] -->|"Inherit, Allow, or Deny"| P["fa:fa-gear Permission on one item"] P --> A["fa:fa-circle-check Allow: access granted"] P --> D["fa:fa-ban Deny: blocked, always wins"] style G fill:#2678BD,color:#fff style P fill:#E47528,color:#fff style A fill:#93d16d,color:#000 style D fill:#c33d34,color:#fff

Blue = the global setting, orange = the permission on one Log View, Monitor View, entity, or set, green = Allow, red = Deny.

Role Components: Permission Sets

Regardless of authentication mode, every Role defines access through four permission sets:

Permission Set Purpose Controls Access To
Log Views Which log data users can view, query, resend, or repair Log Views, message context, body, transformed body
Monitor Views Which monitored resources users can observe and control Monitor Views, Remote Actions, metrics, history, Articles
Repository Model Which documentation users can read, create, or modify Integrations, Systems, Services, Contracts, Message Types, Endpoints, Articles, Custom Fields, Custom Metadata, BPMs, Domains
C4 Diagram Sets Which architecture diagram sets users can open, create, or change Assigned C4 Diagram Sets, Import, grouped-log dynamic diagrams

Access Rights: Allow and Deny

For end-users to work 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 can't access the entity

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

flowchart TD subgraph Role["fa:fa-users-class Role"] A["fa:fa-door-open Access"] L["fa:fa-hard-drive Log Views"] M["fa:fa-display Monitor Views"] R["fa:fa-sitemap Repository"] C["fa:fa-layer-group C4 Diagram Sets"] A -->|"Allow or Deny"| L A -->|"Allow or Deny"| M A -->|"Allow or Deny"| R A -->|"Allow or Deny"| C end style A fill:#E47528,color:#fff style L fill:#3F827B,color:#fff style M fill:#3F827B,color:#fff style R fill:#3F827B,color:#fff style C fill:#3F827B,color:#fff

The Access right (orange) opens each of the four independent permission sets (teal).

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

More worked examples are in Claims and Policies - Common Scenarios.

Next Steps

Add or manage Role
Add or manage Log View
Add or manage Monitor View
Add or manage C4 Diagram Set
Repository Model

Permission Sets

Log View permission set
Monitor View permission set
Repository Model permission set
C4 Diagram Set permission set

Windows Authentication Mode

Users - Individual Windows accounts
Windows AD Groups - Active Directory groups
UseActiveDirectoryGroups - Turn Windows AD Groups on or off

OIDC/OAuth 2.0 Mode

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

General

Access Management - Authorization overview
Roles Overview - All Roles
DefaultRolesInViews - Roles pre-selected on new views and sets
Log Audits - Audit trail
Log Views
Monitor Views
Getting Started with Administration
Install Nodinite v7 - Authentication - Authentication modes