- 0 minutes to read

Claims and Policies - Common Scenarios

Practical, real-world examples for implementing Claims and Policies in Nodinite v7 using OIDC/OAuth 2.0 authentication.

✅ Step-by-step implementation guides
✅ Department-based access control examples
✅ Multi-level permission scenarios
✅ Regional and environmental authorization

Note

This guide is for OIDC/OAuth 2.0 mode only. For Windows authentication, see Users and Windows AD Groups.

Scenario 1: Department-Based Access Control

Goal: Create separate access for Finance, Operations, and HR departments with different permission levels.

Step 1: Create Department Claims

Navigate to Administration → Claims and create:

Key Value Description
department finance Finance Department member
department operations Operations Department member
department hr Human Resources Department member

Step 2: Create Access Level Claims

Key Value Description
access_level readonly Read-only access
access_level editor Read and edit access
access_level admin Full administrative access

Step 3: Create Department Policies

Navigate to Administration → Policies and create:

Finance User Policy:

  • Name: Finance User Policy
  • Description: Standard user access for Finance Department
  • Claims:
    • department=finance
    • access_level=editor

Finance Admin Policy:

  • Name: Finance Admin Policy
  • Description: Administrative access for Finance Department
  • Claims:
    • department=finance
    • access_level=admin

Operations User Policy:

  • Name: Operations User Policy
  • Description: Standard user access for Operations Department
  • Claims:
    • department=operations
    • access_level=editor

HR Read-Only Policy:

  • Name: HR Read-Only Policy
  • Description: Read-only access for HR Department
  • Claims:
    • department=hr
    • access_level=readonly

Step 4: Create Roles and Assign Policies

Create Roles for each department:

  • Finance User role → Assign Finance User Policy
  • Finance Manager role → Assign Finance Admin Policy
  • Operations Team role → Assign Operations User Policy
  • HR Viewer role → Assign HR Read-Only Policy

Result

Users authenticate through their identity provider with department Claims:

  • Finance user with department=finance and access_level=editor gets Finance User role
  • Operations user with department=operations gets Operations Team role access

Scenario 2: Regional Authorization

Goal: Restrict access by geographic region for a global company with European, Americas, and Asia-Pacific operations.

Step 1: Create Regional Claims

Key Value Description
region europe European region access
region americas Americas region access
region apac Asia-Pacific region access
region global Global/all regions access

Step 2: Create Department Claims

Key Value Description
department operations Operations Department
department sales Sales Department

Step 3: Create Regional Policies

European Operations Policy:

  • Name: European Operations Policy
  • Description: Operations access for European region
  • Claims:
    • region=europe
    • department=operations
    • access_level=admin

Americas Sales Policy:

  • Name: Americas Sales Policy
  • Description: Sales access for Americas region
  • Claims:
    • region=americas
    • department=sales
    • access_level=editor

Global Operations Policy:

  • Name: Global Operations Policy
  • Description: Operations access for all regions
  • Claims:
    • region=global
    • department=operations
    • access_level=admin

Step 4: Create Regional Roles

  • Europe Operations role → Assign European Operations Policy
  • Americas Sales role → Assign Americas Sales Policy
  • Global Operations Manager role → Assign Global Operations Policy

Result

Users see only integrations and monitors for their assigned region(s).

Scenario 3: Environment Separation (Dev/Test/Prod)

Goal: Separate access to Development, Test, and Production environments with strict controls on production.

Step 1: Create Environment Claims

Key Value Description
environment development Development environment
environment test Test environment
environment production Production environment

Step 2: Create Role Claims

Key Value Description
role_type developer Developer role type
role_type tester QA/Tester role type
role_type operations Operations team role type

Step 3: Create Environment Policies

Developer Policy:

  • Name: Developer Full Access
  • Description: Full access to Dev and Test environments
  • Claims:
    • role_type=developer
    • environment=development
    • environment=test
    • access_level=admin

Tester Policy:

  • Name: Tester Policy
  • Description: Full access to Test environment only
  • Claims:
    • role_type=tester
    • environment=test
    • access_level=editor

Production Operations Policy:

  • Name: Production Operations Policy
  • Description: Full access to Production environment
  • Claims:
    • role_type=operations
    • environment=production
    • access_level=admin

Production Read-Only Policy:

  • Name: Production Read-Only Policy
  • Description: Read-only production access for developers
  • Claims:
    • role_type=developer
    • environment=production
    • access_level=readonly

Step 4: Create Environment Roles

  • Developer role → Assign Developer Full Access and Production Read-Only Policy
  • QA Tester role → Assign Tester Policy
  • Operations Engineer role → Assign Production Operations Policy

Result

  • Developers have full control in Dev/Test but read-only in Production
  • QA has full access to Test only
  • Operations has full Production access

Scenario 4: Compliance and Audit Requirements

Goal: Meet compliance requirements with specific claims for audited systems and PCI compliance.

Step 1: Create Compliance Claims

Key Value Description
compliance pci-dss PCI-DSS compliant systems access
compliance hipaa HIPAA compliant systems access
compliance sox SOX compliant systems access
audit_access enabled Access to audit trails
data_classification confidential Confidential data access

Step 2: Create Compliance Policies

PCI Compliance Admin Policy:

  • Name: PCI Compliance Admin Policy
  • Description: Administrative access to PCI-DSS compliant payment systems
  • Claims:
    • compliance=pci-dss
    • department=finance
    • access_level=admin
    • data_classification=confidential

Compliance Auditor Policy:

  • Name: Compliance Auditor Policy
  • Description: Read-only access for compliance auditors
  • Claims:
    • compliance=pci-dss
    • compliance=hipaa
    • compliance=sox
    • audit_access=enabled
    • access_level=readonly

Step 3: Create Compliance Roles

  • PCI Administrator role → Assign PCI Compliance Admin Policy
  • Compliance Auditor role → Assign Compliance Auditor Policy

Result

Only users with proper compliance Claims can access regulated systems.

Scenario 5: Multi-Tenant Setup

Goal: Support multiple customers/tenants with isolated access in a shared Nodinite instance.

Step 1: Create Tenant Claims

Key Value Description
tenant customer-a Customer A tenant
tenant customer-b Customer B tenant
tenant customer-c Customer C tenant
tenant internal Internal use tenant

Step 2: Create Tenant-Specific Policies

Customer A Operations Policy:

  • Name: Customer A Operations Policy
  • Description: Operations access for Customer A
  • Claims:
    • tenant=customer-a
    • department=operations
    • access_level=admin

Customer A Business User Policy:

  • Name: Customer A Business User Policy
  • Description: Business user access for Customer A
  • Claims:
    • tenant=customer-a
    • access_level=readonly

Internal Admin Policy:

  • Name: Internal Admin Policy
  • Description: Administrative access to all tenants for internal staff
  • Claims:
    • tenant=internal
    • access_level=admin

Step 3: Create Tenant Roles

  • Customer A Ops role → Assign Customer A Operations Policy
  • Customer A User role → Assign Customer A Business User Policy
  • Internal Administrator role → Assign Internal Admin Policy

Result

Each tenant sees only their own integrations and data.

Scenario 6: Migrating from Windows to OIDC

Goal: Transition from Windows authentication (Users/Groups) to OIDC/OAuth 2.0 (Claims/Policies).

Step 1: Document Current Windows Setup

Map your existing Windows AD Groups to Claims:

Windows AD Group Maps To Claims
SE_Finance_Team department=finance, access_level=editor
SE_Finance_Managers department=finance, access_level=admin
SE_IT_Operations department=it, access_level=admin, environment=production
Global_Developers role_type=developer, environment=development, environment=test

Step 2: Create Equivalent Claims

Create Claims that represent your Windows Group permissions:

Key Value Description
department finance Replaces SE_Finance_Team group
department it Replaces SE_IT_Operations group
access_level editor Standard user permissions
access_level admin Admin permissions
role_type developer Developer role
environment production Production access
environment development Dev environment
environment test Test environment

Step 3: Create Policies Matching Windows Groups

Finance Team Policy:

  • Name: Finance Team Policy
  • Description: Replaces SE_Finance_Team Windows group
  • Claims:
    • department=finance
    • access_level=editor

IT Operations Policy:

  • Name: IT Operations Policy
  • Description: Replaces SE_IT_Operations Windows group
  • Claims:
    • department=it
    • access_level=admin
    • environment=production

Developers Policy:

  • Name: Developers Policy
  • Description: Replaces Global_Developers Windows group
  • Claims:
    • role_type=developer
    • environment=development
    • environment=test

Step 4: Configure Identity Provider

In your identity provider (Azure AD, Okta, etc.):

  1. Map Windows group memberships to Claims
  2. Configure claim transformation rules
  3. Test with pilot users

Step 5: Update Nodinite Configuration

  1. Switch authentication mode to OIDC/OAuth 2.0 (see Install Nodinite v7 - OpenID)
  2. Assign Policies to existing Roles
  3. Test access with pilot users
  4. Roll out to all users

Step 6: Decommission Windows Authentication

Once verified:

  1. Remove Windows Users from Roles
  2. Remove Windows AD Groups from Roles
  3. Document the new Claims/Policies structure

Scenario 7: Dynamic Permissions Based on Time

Goal: Grant temporary elevated permissions for on-call staff.

Step 1: Create On-Call Claims

Key Value Description
oncall_status active Currently on call
oncall_status inactive Not on call
shift weekday Weekday shift
shift weekend Weekend shift

Step 2: Create On-Call Policies

On-Call Administrator Policy:

  • Name: On-Call Administrator Policy
  • Description: Elevated permissions for on-call staff
  • Claims:
    • oncall_status=active
    • access_level=admin
    • environment=production

Standard Operations Policy:

  • Name: Standard Operations Policy
  • Description: Normal operations permissions
  • Claims:
    • department=operations
    • access_level=editor

Step 3: Configure Identity Provider

In your identity provider:

  1. Set up automated processes to add/remove oncall_status=active Claim
  2. Based on on-call schedule, dynamically assign Claims
  3. User gets elevated permissions only when on call

Result

Users automatically get elevated permissions during their on-call shift.

Best Practices Across All Scenarios

Naming Conventions

✅ Good:

  • Use lowercase for consistency
  • Use underscores for multi-word keys: access_level, role_type
  • Be descriptive: department, region, environment

❌ Avoid:

  • Mixed case: AccessLevel, Dept
  • Abbreviations: env, rgn
  • Special characters: access-level, role.type

Claim Design

  • Start specific, not broad: Begin with granular Claims, combine into Policies
  • Keep Claims atomic: Each Claim represents one thing
  • Document everything: Use Description fields extensively

Policy Organization

  • Group logically: Department-based, role-based, or function-based
  • Reuse Policies: Design Policies to be assigned to multiple Roles
  • Clear naming: Policy names should explain their purpose

Testing

  1. Test with pilot users before full rollout
  2. Verify Claim matching - ensure users receive correct Claims from identity provider
  3. Check permission inheritance - verify Role assignments work correctly
  4. Document test results for audit purposes

Security

  • Principle of least privilege: Grant minimum necessary permissions
  • Regular audits: Review Claims, Policies, and Role assignments quarterly
  • Monitor access: Use Log Audits to track permission changes
  • Separate environments: Different Policies for Dev, Test, Production

Next Step

Add or manage Claim - Create Claims
Add or manage Policy - Create Policies
Add or manage Role - Assign Policies to Roles
Install Nodinite v7 - OpenID - Configure OIDC/OAuth 2.0

What is a Claim?
What is a Policy?
What is a Role?
Access Management
Install Nodinite v7 - OpenID - EntraID