- 11 minutes to read

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. This powerful feature enables you to:

  • ✅ Enforce security policies and compliance requirements
  • ✅ Grant granular access to logs, monitors, and configuration
  • ✅ Support both on-premises and cloud-based authentication
  • ✅ Maintain audit trails of all sensitive operations
  • ✅ Implement principle of least privilege across your organization

Access Management uses role-based security – a flexible model where you define permission sets (Roles), then assign users, groups, or policies to those roles. This approach 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 access the Audit Log via the Web Client or Web API.

Understanding Administrator vs Regular User Access

Access Management features are only visible to Administrators. Regular users see a simplified menu without access control options.

Administrator view of Access Management menu
As a Nodinite Administrator, you have full access to the 'Access Management' menu in the Nodinite Web Client. The available menu items depend on your authentication mode.

Non-administrator view of sidebar menu
Regular users (non-administrators) do not see the Access Management menu. They only have access to features granted through their assigned Roles.

Common Concepts (Both Authentication Modes)

Regardless of which authentication mode you use, these core concepts apply:

Roles

Roles are the foundation of Nodinite's access control system. A Role defines:

  • Log View permissions – Which log data users can see
  • Monitor View permissions – Which monitoring dashboards are accessible
  • Repository Model permissions – Access to integration documentation
  • Feature permissions – Remote Actions, administration, configuration

Users can have multiple Roles, and permissions are cumulative. For example, a user assigned both "Business User" and "Developer" roles gets all permissions from both.

Audit Logging

Every access-sensitive operation is logged:

  • Who accessed which Log Views and when
  • Configuration changes and who made them
  • Remote Action executions
  • Permission modifications

Review audit logs 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

Windows Authentication Mode

What is Windows Authentication Mode?

Windows Authentication Mode leverages your existing Active Directory infrastructure 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. 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 leverage 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 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:

Typical workflow:

  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, and Repository Model access per Role
  5. Test access – Log in as a regular user to verify permissions

Start here:

OIDC/OAuth 2.0 Mode

What is OIDC/OAuth 2.0 Mode?

OIDC/OAuth 2.0 Mode uses modern OpenID Connect and OAuth 2.0 protocols for authentication and authorization. This cloud-native approach works with external identity providers like:

  • 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 that simplify permission management. Instead of assigning individual Claims to Roles, you create Policies that bundle related Claims together. Example Policies:

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

Policies are then assigned to Roles, similar to how Windows AD Groups work in Windows Authentication mode.

How to manage: Add or manage Policy

Roles

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

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:

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

Typical workflow:

  1. Configure identity provider – Set up Azure AD, Okta, or other 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, and Repository Model access per Role
  6. Test access – Log in via your identity provider to verify permissions

Start here:

Frequently Asked Questions

Which authentication mode should I use?

Choose Windows Authentication if:

  • ✅ You have on-premises deployment with Active Directory
  • ✅ All users are within your Windows domain/forest
  • ✅ You prefer traditional Windows-integrated security
  • ✅ You don't need external identity provider integration

Choose OIDC/OAuth 2.0 if:

  • ✅ You have cloud-based or hybrid deployments
  • ✅ You want to integrate with Azure AD, Okta, or other identity providers
  • ✅ You need cross-platform authentication
  • ✅ You require modern security features (MFA, conditional access)

How are Users/Groups different from Claims/Policies?

Windows Mode (Users & Windows AD Groups):

  • Direct mapping to Windows domain accounts and Active Directory security groups
  • Authentication and authorization both handled by Windows
  • Best for on-premises deployments with existing AD infrastructure
  • Example: Assign AD group "Integration Team" to "Developer" Role

OIDC/OAuth 2.0 Mode (Claims & Policies):

  • Flexible key/value pairs (Claims) provided by identity provider
  • Claims grouped into Policies, Policies assigned to Roles
  • Works with any OpenID Connect compliant provider
  • Better for cloud, SaaS, and multi-platform deployments
  • Example: Policy "EMEA Developers" contains Claims region=EMEA + role=developer, assigned to "Developer" Role

When should I use Windows AD Groups vs individual Users?

Note

This applies to Windows Authentication mode only.

Use Windows 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 want to leverage existing AD security group structure

Use individual Users when:

  • ✅ You have external users (partners, vendors) not in your AD
  • ✅ You need fine-grained control over specific individuals
  • ✅ You want explicit per-person access tracking
  • ✅ The user count is small and doesn't justify AD group management

Can one user have multiple Roles?

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

Example:

  • User assigned to "Business User" role → Gets read access to finance Log Views
  • Same user also assigned to "Developer" role → Gets Repository Model access
  • Result: 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).

How do I revoke access quickly in an emergency?

Several options, in order of speed:

  1. Disable the User account (Windows mode) or remove Claims (OIDC mode) – Immediate access revocation
  2. Remove Role assignment – Remove User/Group or Policy from 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 at the identity provider level (AD account or OIDC provider).

How do I audit who has access to what?

Use these features to track access:

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

What's the principle of least privilege?

Grant users only the minimum permissions needed for their job function. Examples:

  • Business users: Access to their specific Log Views only, not all integrations
  • Developers: Test/Dev environment access, not Production
  • Operations team: Full monitoring access, but no configuration changes
  • Administrators: Full access, but use separate account for non-admin tasks

Implementation: Create narrowly-scoped Roles and assign based on job function, not seniority.

Common Administrative Tasks

Grant access to Log Views

Log Views display log messages from your integrations. To grant access:

  1. Create or edit a Role
  2. Configure Log View permission set
  3. Assign Users, Windows AD Groups, or Policies to the Role
  4. Users can now see logs matching their Log View permissions

Grant access to Monitor Views

Monitor Views display real-time monitoring dashboards. To grant access:

  1. Create or edit a Role
  2. Configure Monitor View permission set
  3. Assign Users, Windows AD Groups, or Policies to the Role
  4. Users can now see monitors matching their Monitor View permissions

Grant access to Repository Model

Repository Model provides integration documentation and architecture views. To grant access:

  1. Create or edit a Role
  2. Configure Repository Model permission set
  3. Assign Users, Windows AD Groups, or Policies to the Role
  4. Users can now access integration documentation features

Next Step

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 dashboard access
Permission Set for the Repository Model – Grant integration documentation access

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 authorization structure:

Add or manage Policy – Group Claims into Policies
Add or manage Role – Define permission sets and assign Policies

Finally, configure specific access permissions:

Permission Set for Log Views – Grant access to log data
Permission Set for Monitor Views – Grant monitoring dashboard access
Permission Set for the Repository Model – Grant integration documentation access

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)

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 dashboard access
Repository Model – Integration documentation access
Remote Actions – Self-service operations permissions
Log Audits – Track user activity and changes

Installation and Configuration

Administration – Main administration overview
Web Client – User interface
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