What is a Policy?

Master flexible authorization in Nodinite v7 by understanding Policies. This page explains how Policies group Claims together and provide the link between individual permissions and Roles.

✅ Group related Claims for easier management
✅ Reusable permission sets across multiple Roles
✅ Flexible authorization for complex scenarios
✅ Foundation for OIDC/OAuth 2.0 access control

Note

Policies are only available when Nodinite is configured for OIDC/OAuth 2.0 authentication mode. For Windows authentication mode, use Users and Windows AD Groups instead.

Get started now: Add or manage Policy user guide.

What is a Policy?

A Policy in Nodinite is a named collection of Claims that can be assigned to one or more Roles. Policies provide a way to group related permissions and attributes together for easier management and reusability.

Think of it this way:

• Claims = Individual permissions (key/value pairs)
• Policies = Groups of related Claims
• Roles = Job functions that receive Policies

Example of a Policy showing grouped Claims in the Nodinite Web Client.

Authorization Flow with Policies

Understanding how Policies fit into the authorization model:

1. Claims - Individual key/value pairs (e.g., department=finance, access_level=admin)
2. Policies - Groups of Claims (e.g., "Finance Admin Policy" contains both Claims above)
3. Roles - Assigned Policies to grant permissions (e.g., "Finance Manager" role)
4. Users - Authenticated via identity provider, receive Claims
5. Authorization - Nodinite matches user Claims with Policy requirements in assigned Roles

Key Characteristics

Named Collections

Each Policy has:

• Name (Required) - Unique identifier for the Policy
• Description (Optional) - Explains the Policy's purpose
• Claims - One or more Claims grouped together

Reusability

Policies can be assigned to multiple Roles:

• Create once, use many times
• Consistent permissions across Roles
• Easier maintenance and updates

Flexibility

Policies support complex authorization scenarios:

• Combine Claims from different categories
• Mix department, access level, and regional Claims
• Create fine-grained or broad permission sets

Policy Structure

Example: Finance Admin Policy

Name: Finance Admin Policy
Description: Full administrative access to finance integrations and reporting

Claims in this Policy: | Key | Value | Description | |-----|-------|-------------| | department | finance | Finance Department member | | access_level | admin | Administrator access level | | environment | production | Production environment access |

This Policy groups three Claims together, creating a complete permission set for finance administrators.

Example: Regional Read-Only Policy

Name: Europe Read-Only Access
Description: Read-only access to European integration monitoring

Claims in this Policy: | Key | Value | Description | |-----|-------|-------------| | region | europe | European region | | access_level | readonly | Read-only access level |

This Policy combines regional and permission-level Claims.

Policy Management

You can manage Nodinite Policies from the Administration section in the Nodinite Web Client:

Example of the Policies menu item in the Administration sidebar.

Available Operations

• Add new Policy - Create Policies
• Edit Policy - Modify Name, Description, or Claims
• Delete Policy - Remove Policies (can be restored)
• Restore Policy - Recover deleted Policies
• Filter Policies - Search by Name or Description
• Manage Claims - Add/remove Claims from the Policy

Policy Detail Page

When creating or editing a Policy, you work with three main sections:

1. General Information

• Name - The Policy name (required, must be unique)
• Description - Optional description of the Policy's purpose

2. Claims Management Tabs

The Policy detail page includes three tabs for managing Claims:

New/Edit Tab:

• Create new Claims or edit existing ones
• "Add and Use" option to create and assign in one step
• Convenient for creating Claims specific to this Policy

All Tab:

• Browse all available Claims in the system
• Use checkboxes to add Claims to this Policy
• Search and filter to find specific Claims
• Shows deleted Claims when "Include Deleted" is enabled

Selected Tab:

• View all Claims currently assigned to this Policy
• Use checkboxes to remove Claims from this Policy
• Shows warning badges for deleted Claims
• Search within selected Claims

The three tabs for managing Claims within a Policy.

Policies vs. Users/Groups

OIDC/OAuth 2.0 Mode (Policies)

How it works:

• Define Claims (key/value pairs)
• Group Claims into Policies
• Assign Policies to Roles
• Users receive access based on their Claims matching Policy requirements

Advantages:

• Platform-independent
• Flexible and extensible
• Works with any identity provider
• Modern cloud-native approach

Use when:

• Cloud-based deployments
• Multi-platform environments
• External identity providers (Azure AD, Okta, etc.)
• Need modern authentication protocols

Windows Authentication Mode (Users/Groups)

How it works:

• Assign Users directly to Roles
• Or assign Windows AD Groups to Roles
• Windows handles authentication and authorization

Advantages:

• Direct Active Directory integration
• Familiar Windows security model
• No additional Claims configuration

Use when:

• On-premises deployments
• All users in Windows domain
• Traditional Windows-integrated security

Important

You cannot mix modes. Nodinite uses either Windows authentication (Users/Groups) or OIDC/OAuth 2.0 (Claims/Policies), configured during installation.

Policy Assignment to Roles

Once created, Policies are assigned to Roles:

In the Role Detail Page

When viewing or editing a Role in OIDC/OAuth 2.0 mode, you'll see a Policies card showing:

The Policies card in a Role showing assigned Policies.

• Policy count - Number of Policies assigned
• Policy names - Clickable links to Policy details
• Policy descriptions - Quick reference
• Warning badges - For deleted Policies

Note

In the current version, Policy assignment to Roles is configured through backend or API. The Policies card in Roles is read-only for viewing.

Best Practices

Naming Conventions

Use clear, descriptive names that explain the Policy's purpose:

✅ Good Names:
   Finance Admin Policy
   Europe Read-Only Access
   Operations Full Access
   Developer Test Environment

❌ Poor Names:
   Policy1
   Fin_Pol
   ADMIN
   Test

Descriptive Documentation

Always provide a comprehensive Description:

✅ Good Description:
   "Full administrative access to finance integrations, including 
    invoice processing, payment systems, and financial reporting. 
    Grants read/write/delete permissions in production environment."

❌ Poor Description:
   "Finance policy"
   "Admin access"
   ""

Logical Grouping

Group related Claims together:

Department-Based Policy:

Policy: "Finance Department Access"
Claims:
  - department=finance
  - environment=production
  - access_level=editor

Functional Policy:

Policy: "Read-Only Monitoring"
Claims:
  - access_level=readonly
  - feature=monitoring
  - feature=logging

Regional Policy:

Policy: "European Operations"
Claims:
  - region=europe
  - department=operations
  - access_level=admin

Reusability

Design Policies to be reusable across multiple Roles:

Policy: "Production Environment Access"
  - environment=production
  - compliance=validated

Assigned to Roles:
  - Finance Manager (with other finance Policies)
  - Operations Lead (with other operations Policies)
  - Senior Developer (with other developer Policies)

Review Deleted Claims

If a Policy contains deleted Claims:

• Warning badges appear
• Edit the Policy to remove deleted Claims
• Add replacement Claims
• Or restore the deleted Claims if they're still needed

Common Scenarios

Scenario 1: Department-Based Access Control

Goal: Different access levels for different departments

Policy: "Finance Department Access"
Claims:
  - department=finance
  - access_level=editor

Policy: "Finance Admin Access"  
Claims:
  - department=finance
  - access_level=admin

Policy: "Operations Department Access"
Claims:
  - department=operations
  - access_level=editor

Each Role gets the appropriate Policy for their department and level.

Scenario 2: Multi-Permission Policies

Goal: Combine multiple types of permissions

Policy: "European Finance Manager"
Claims:
  - department=finance
  - region=europe
  - access_level=admin
  - environment=production
  - feature=reporting

This single Policy grants comprehensive access for a specific job function.

Scenario 3: Tiered Access Levels

Goal: Read-only, editor, and admin tiers

Policy: "Read-Only Access"
Claims:
  - access_level=readonly

Policy: "Editor Access"
Claims:
  - access_level=readonly
  - access_level=editor

Policy: "Full Admin Access"
Claims:
  - access_level=readonly
  - access_level=editor
  - access_level=admin

Assign to Roles based on user responsibilities.

Scenario 4: Environment Separation

Goal: Separate access for Dev, Test, and Production

Policy: "Development Environment"
Claims:
  - environment=development
  - environment=test

Policy: "Production Environment"
Claims:
  - environment=production
  - compliance=validated

Ensures production access is strictly controlled.

Integration with Claims

Creating Claims within Policies

When editing a Policy, you can create new Claims directly:

1. Switch to the "New/Edit" tab
2. Enter the Claim Key, Value, and Description
3. Click "Add and Use" to create the Claim AND add it to this Policy

This is convenient when you need a Claim specifically for this Policy.

Adding Existing Claims

To add existing Claims to a Policy:

1. Switch to the "All" tab
2. Browse or search for Claims
3. Check the boxes for Claims you want to add
4. Claims are added to the "Selected" tab

Removing Claims from Policies

To remove Claims from a Policy:

1. Switch to the "Selected" tab
2. Uncheck the boxes for Claims you want to remove
3. Click "Save" to apply changes

Troubleshooting

Cannot Create Policy - "Name already exists"

Issue: Error when creating a Policy

Solution: Policy names must be unique. Either:

• Choose a different name
• Check if the Policy was deleted (restore it instead)
• Edit the existing Policy if it serves the same purpose

Policy Shows Deleted Claims

Issue: Policy contains Claims with warning badges

Explanation: The Claims have been deleted but remain referenced in the Policy for audit purposes.

Solution:

1. Edit the Policy
2. Go to the "Selected" tab
3. Uncheck the deleted Claims
4. Add replacement Claims from the "All" tab
5. Or restore the deleted Claims if still needed

Cannot See Policy in Role

Issue: Created a Policy but don't see it in Role editor

Possible causes:

1. Policy assignment is managed through backend/API (not UI)
2. Policy was deleted
3. Browser cache issue

Solution:

1. Contact your system administrator for Policy assignment
2. Verify Policy exists and is not deleted
3. Refresh the page

Policy Contains No Claims

Issue: Policy created but has no Claims assigned

Solution: This is allowed but not useful. Edit the Policy and add Claims:

1. Open the Policy detail page
2. Use the "All" tab to add existing Claims
3. Or use the "New/Edit" tab to create and add Claims
4. Save the Policy

Security Considerations

Principle of Least Privilege

Create specific Policies rather than overly broad ones:

✅ Specific Policy:
   "Finance Invoice Processing"
   Claims:
     - department=finance
     - feature=invoices
     - access_level=editor

❌ Too Broad:
   "Full System Access"
   Claims:
     - access=all
     - permission=everything

Regular Audits

• Review Policies quarterly
• Remove unused Policies
• Update descriptions
• Verify Claims are still appropriate
• Check Role assignments

Claim Validation

Ensure all Claims in a Policy are:

• Still valid (not deleted)
• Still relevant to the Policy's purpose
• Properly documented
• Following naming conventions

Quick Facts

• Policies are named collections of Claims
• Available only in OIDC/OAuth 2.0 mode
• Policy names must be unique
• Policies can be assigned to multiple Roles
• Policies can contain one or more Claims
• Deleted Policies can be restored
• Three tabs for managing Claims: New/Edit, All, Selected
• Always provide a Description for clarity
• Reusable across multiple Roles

Next Step

Add or manage Policy
What is a Role?
What is a Claim?
Install Nodinite v7 - OpenID Connect

Related Topics

Policies:

Policies Overview - Manage all Policies
Add or manage Policy - Policy management guide

Claims:

What is a Claim? - Understanding Claims
Claims Overview - Manage all Claims
Add or manage Claim - Claim management guide

Roles:

What is a Role? - Understanding Roles
Roles Overview - Manage all Roles

Configuration:

Access Management - Authorization overview
Install Nodinite v7 - OpenID - Configure OIDC/OAuth 2.0
Install Nodinite v7 - OpenID - EntraID - Azure AD setup

Windows Mode Alternative:

Users - Windows authentication mode
Windows AD Groups - Windows authentication mode