Access Management Sidebar Menu Item

What is Access Management?

As a Nodinite Administrator, the Access Management menu is your central hub for controlling who can access what in your integration environment. With it you can:

• ✅ Enforce security policies and compliance requirements
• ✅ Grant granular access to logs, monitors, documentation, and architecture diagrams
• ✅ Support both on-premises (Windows) and cloud-based (OIDC/OAuth 2.0) authentication
• ✅ Keep an audit trail of all sensitive operations
• ✅ Implement the principle of least privilege across your organization

Access Management uses role-based security: you define permission sets in Roles, then assign Users, Windows AD Groups, or Policies to those Roles. The model scales from small teams to enterprise deployments with thousands of integrations.

Important

All operations that change data or involve sensitive actions (downloads, message views) are logged in a tamper-resistant Log Audits storage. Only Administrators can search the audit log, in the Web Client or through the Web API. The DaysToKeepLogAudits System Parameter sets how long the entries are kept.

Understanding the Access Management Model

Authentication tells Nodinite who the user is; Roles decide what that user can see and do. The identity objects differ per authentication mode, but every path ends in the same Roles and the same permission sets.

Blue = Windows mode identities, purple = OIDC/OAuth 2.0 mode identities, orange = Roles (the same in both modes), teal = the permission sets each Role holds.

Key Components Explained

Understanding Administrator vs Regular User Access

The Administration menu, and with it Access Management, is only visible to members of the built-in Administrators Role. Regular users see a simplified menu with the features their Roles grant.

Administrators see the Administration menu in the Nodinite Web Client. This installation runs in Windows mode; the Access Management items depend on your authentication mode.

Regular users don't see the Administration menu. What they see under Log, Monitor, and Repository comes from their assigned Roles.

For a non-technical tour of what the Administration menu holds, see Getting Started with Administration.

Common Concepts (Both Authentication Modes)

Roles and Permission Sets

Roles are the foundation of Nodinite's access control. Each Role holds one permission set per feature area:

Users can have multiple Roles, and permissions are cumulative. A user assigned both "Business User" and "Developer" gets the permissions of both, unless one of the Roles sets Deny, which always wins.

For C4 Diagram Sets, the Role editor has a C4 Set Permissions (x) tab where administrators assign sets and set Access and Modify per set. The Create right (Create C4 Diagram Sets), which also gates Import, and the Logging right are global permissions on the same C4 tab.

The same Roles also govern programmatic access: the Web API and the MCP Endpoint (used by the AI Assistant and external AI tools) only return what the caller's Roles allow.

System Parameters That Shape Access

These System Parameters change how Roles and permissions behave for the whole installation:

Note

LogAccessRoles and LogServiceUsers are not Nodinite Roles. They list the SQL Server database roles and service accounts the Logging Service grants on each new Log Database.

Audit Logging

Every access-sensitive operation is logged: who opened which Log Views and when, configuration changes, Remote Action executions, and permission changes. Review the entries in Log Audits to maintain compliance and troubleshoot security incidents.

Principle of Least Privilege

Best practice: Grant users only the minimum permissions needed for their job function:

• Business users: Access to their specific Log Views only
• Developers: Test/Dev environment access, not Production
• Operations: Monitoring access, limited configuration changes
• Administrators: Full access, but use separate accounts for day-to-day work

Create narrowly scoped Roles and assign them based on job function, not seniority.

Windows Authentication Mode

What is Windows Authentication Mode?

Windows Authentication Mode uses your existing Active Directory for both authentication and authorization. Users log in with their Windows domain credentials, and access is controlled through:

• Individual Users (Windows domain accounts)
• Windows AD Groups (Active Directory security groups)
• Roles (permission sets assigned to Users or Groups)

When to Use Windows Authentication

• ✅ On-premises deployment with Active Directory
• ✅ All users within your Windows domain/forest
• ✅ Preference for traditional Windows-integrated security
• ✅ No external identity provider required

Authorization Components

Users

Users are individual Windows domain accounts (e.g., DOMAIN\john.smith) that you explicitly grant access to Nodinite. Use individual Users when:

• You have external users (partners, vendors) not in your AD
• You need fine-grained control over specific individuals
• You want to track access per person, not per group

How to manage: Add or manage User

Windows AD Groups

Windows AD Groups are Active Directory security groups (e.g., DOMAIN\Integration Team) that you map to Nodinite Roles. The feature is on while the UseActiveDirectoryGroups System Parameter is true (the default). Use AD Groups when:

• You want automatic provisioning based on AD group membership
• You need to maintain access control centrally in Active Directory
• You have many users with similar permissions
• You use AD group nesting for organizational structure

How to manage: Add or manage Windows AD Group

Roles

Roles define permission sets that are assigned to Users or Windows AD Groups. Example Roles:

• Production Monitor – Full access to production Log Views and Monitor Views
• Developer – Access to test/dev environments and the Repository Model
• Business Analyst – Read-only access to specific business process logs

How to manage: Add or manage Role

Getting Started with Windows Authentication

Prerequisites for Windows Mode

• Nodinite installed with Windows Authentication enabled
• Active Directory domain available
• Administrator credentials for the Nodinite Web Client

Typical Workflow for Windows Mode

1. Create Roles – Define permission sets matching your organizational needs
2. Add Windows AD Groups – Map existing AD security groups to Roles
3. Add individual Users (if needed) – Grant access to external users or specific individuals
4. Assign permissions – Configure Log View, Monitor View, Repository Model, and C4 Diagram Set access per Role
5. Test access – Log in as a regular user to verify permissions

OIDC/OAuth 2.0 Mode

What is OIDC/OAuth 2.0 Mode?

OIDC/OAuth 2.0 Mode uses OpenID Connect and OAuth 2.0 for authentication and authorization. It works with external identity providers such as:

• Azure AD (Microsoft Entra ID)
• Okta
• Auth0
• Google Workspace
• Any OpenID Connect compliant provider

Authorization is controlled through:

• Claims – Key/value pairs representing permissions or user attributes
• Policies – Groups of Claims that simplify permission management
• Roles – Permission sets with Policies assigned (similar to Windows mode)

When to Use OIDC/OAuth 2.0

• ✅ Cloud-based or hybrid deployments
• ✅ Integration with external identity providers
• ✅ Cross-platform authentication requirements
• ✅ Modern security protocols (MFA, conditional access)
• ✅ Multi-tenant or SaaS-style deployments

Authorization Components

Claims

Claims are key/value pairs provided by your identity provider that represent permissions or user attributes. Examples:

• department = finance
• access_level = admin
• region = EMEA
• role = integration-developer

Claims are the building blocks for authorization in OIDC/OAuth 2.0 mode.

How to manage: Add or manage Claim

Policies

Policies are groups of Claims. A user matches a Policy only when they have all of its Claims (AND logic); a user who matches any of several Policies on a Role gets that Role (OR logic). Example Policies:

• Finance Admin Policy – Contains Claims: department=finance, access_level=admin
• EMEA Developer Policy – Contains Claims: region=EMEA, role=developer

Policies are assigned to Roles, much like Windows AD Groups in Windows Authentication mode.

How to manage: Add or manage Policy

Roles in OIDC Mode

Roles define permission sets, just like in Windows Authentication mode. Instead of Users or Groups, you assign Policies (which contain Claims) to them.

When a user logs in via OIDC/OAuth 2.0, Nodinite evaluates their Claims against Policies to determine which Roles they inherit.

How to manage: Add or manage Role

Getting Started with OIDC/OAuth 2.0

Prerequisites for OIDC Mode

• Nodinite installed with OIDC/OAuth 2.0 enabled
• Identity provider configured (e.g., Azure AD)
• Claims configured in your identity provider
• Administrator credentials for the Nodinite Web Client

Typical Workflow for OIDC Mode

1. Configure identity provider – Set up Azure AD, Okta, or another OIDC provider
2. Define Claims – Map Claims from your identity provider to Nodinite
3. Create Policies – Group related Claims into Policies
4. Create Roles – Define permission sets and assign Policies to Roles
5. Assign permissions – Configure Log View, Monitor View, Repository Model, and C4 Diagram Set access per Role
6. Test access – Log in via your identity provider to verify permissions

Worked examples (department, region, environment, compliance, multi-tenant, and migration from Windows) are in Claims and Policies - Common Scenarios.

Frequently Asked Questions

Which authentication mode should I use?

Choose Windows Authentication for on-premises installations where all users are in your Active Directory domain or forest. Choose OIDC/OAuth 2.0 for cloud or hybrid installations, external identity providers (Azure AD, Okta), and MFA or conditional access. The full checklists are in the two When to Use sections above. The mode is chosen at installation, see Install Nodinite v7 - Authentication.

How are Users/Groups different from Claims/Policies?

Users and Windows AD Groups map directly to Windows accounts and Active Directory security groups, and Windows handles both authentication and authorization. Claims are key/value pairs sent by any OpenID Connect provider; you group them in Policies and assign the Policies to Roles. Either way, the Roles and permission sets are identical, as the diagram in Understanding the Access Management Model shows.

When should I use Windows AD Groups vs individual Users?

Note

This applies to Windows Authentication mode only.

Use Windows AD Groups for teams and departments, so access follows AD group membership. Use individual Users for exceptions: external partners, temporary access, or a person who needs a unique Role combination. You can mix both on the same Role; the comparison table is in What is a User.

Can one user have multiple Roles?

Yes. Users can be assigned multiple Roles, and permissions are cumulative:

• User assigned to the "Business User" Role → gets read access to finance Log Views
• Same user also assigned to the "Developer" Role → gets Repository Model access
• Result: the user has both sets of permissions (finance logs + Repository Model)

This applies to both Windows Authentication mode (via multiple User/Group assignments) and OIDC/OAuth 2.0 mode (via multiple Policy assignments). A Deny in any of the Roles still wins over every Allow.

How do I revoke access quickly in an emergency?

Use one of these options, fastest first:

1. Disable the User account (Windows mode) or remove Claims (OIDC mode) – Immediate access revocation
2. Remove the Role assignment – Remove the User/Group or Policy from the specific Role – Takes effect on next login
3. Modify the Role – Change permissions for all members of that Role – Affects all users with that Role

Best practice: For immediate lockout, disable the account at the identity provider (AD account or OIDC provider).

How do I audit who has access to what?

• Log Audits – Track who accessed which Log Views, when, and what actions they performed
• Roles Overview – See all Roles and their assigned Users/Groups/Policies
• Users Overview / Windows AD Groups - Overview (Windows mode) – See which Roles each User or Group has; the User editor also shows the user's effective Log and Monitor permissions
• Policies Overview (OIDC mode) – See which Claims are grouped in each Policy and which Roles use them

Compliance reports: Export Log Audits for SOX, HIPAA, or GDPR compliance reviews.

A user can't log in or sees the wrong data. Where do I start?

For OIDC/OAuth 2.0 mode, follow Troubleshooting Claims and Policies. For Windows mode, see the troubleshooting sections in Add or manage User and Add or manage Windows AD Group.

Common Administrative Tasks

Grant Access to a Feature Area

Every feature area is granted the same way:

1. Create or edit a Role in Add or manage Role.
2. Open the permission set for the feature area (table below) and set Allow on the items the Role needs.
3. Assign Users, Windows AD Groups, or Policies to the Role.
4. Log in as a member of the Role and verify what they see.

Next Steps

For Windows Authentication Mode

Start by creating Roles that match your organizational structure:

Add or manage Role – Define permission sets
Add or manage Windows AD Group – Map Active Directory groups to Roles
Add or manage User – Grant access to individual users

Then configure specific access permissions:

Permission Set for Log Views – Grant access to log data
Permission Set for Monitor Views – Grant monitoring access
Permission Set for the Repository Model – Grant integration documentation access
Permission Set for C4 Diagram Sets – Grant C4 Diagram Set access, create, modify, and logging rights

For OIDC/OAuth 2.0 Mode

Start by configuring your identity provider and Claims:

Install Nodinite v7 - OpenID – Configure OIDC/OAuth 2.0 authentication
Install Nodinite v7 - OpenID - EntraID – Azure AD (Entra ID) specific setup
Add or manage Claim – Define Claims from your identity provider

Then create the authorization structure:

Add or manage Policy – Group Claims into Policies
Add or manage Role – Define permission sets and assign Policies
Claims and Policies - Common Scenarios – Worked examples

Finally, configure the same permission sets as in Windows mode (Log Views, Monitor Views, Repository Model, C4 Diagram Sets).

Related Topics

Access Management Concepts

What is a Role – Understanding permission sets
What is a User – Individual account management (Windows mode)
What is a Windows AD Group – Active Directory integration (Windows mode)
What is a Claim – Understanding Claims (OIDC/OAuth 2.0 mode)
What is a Policy – Grouping Claims (OIDC/OAuth 2.0 mode)
Troubleshooting Claims and Policies – Fix OIDC/OAuth 2.0 access problems

Management Pages

Roles Overview – View and manage all Roles
Users Overview – User administration (Windows mode)
Windows AD Groups - Overview – AD group management (Windows mode)
Claims Overview – Manage all Claims (OIDC/OAuth 2.0 mode)
Policies Overview – Manage all Policies (OIDC/OAuth 2.0 mode)

Features Controlled by Access Management

Log Views – Log data access control
Monitor Views – Monitoring access
Repository Model – Integration documentation access
C4 Diagram Sets – Diagram set access and grouped-log dynamic diagram gating
Remote Actions – Self-service operations permissions
Log Audits – Track user activity and changes
MCP Endpoint – AI tool access that follows the caller's Roles

Settings, Installation, and Configuration

Administration – Main administration overview
System Parameters – Installation-wide settings
Web Client – User interface
Getting Started with Administration – What the Administration menu holds
Install Nodinite v7 - Authentication – Authentication mode configuration
Install Nodinite v7 - OpenID – OIDC/OAuth 2.0 setup guide
Install Nodinite v7 - OpenID - EntraID – Azure AD (Entra ID) configuration
Web API – API access and authentication