Policy Management

Policy Management allows administrators to create, version, test, and manage role-based access control (RBAC) policies using Open Policy Agent (OPA) and the Rego policy language. These policies govern what users can access and do within the system based on their roles, the resource type, and the action being performed.

Overview

The policy management interface is organized into two tabs:

• Policies — Create and manage RBAC policies
• Evaluations — View the history of policy evaluation decisions

---

Managing Policies

Viewing Policies

The Policies tab displays a table of all configured policies with the following columns:

Column	Description
Name	The unique identifier for the policy
Version	The current version number
Status	Active or Inactive
Last Modified	When the policy was last updated
Actions	Edit, Test, History, and Delete buttons

Creating a Policy

1. Click the Create Policy button in the top-right corner.
2. In the dialog that appears, fill in:
   • Policy Name — A unique identifier (e.g., document_access_policy)
   • Policy Content — The policy logic written in Rego syntax
3. Click Create Policy to save.

Note

Policies use the Rego language from Open Policy Agent. The editor provides a placeholder example showing common patterns including role-based access checks and resource-level conditions.

Example Policy Structure

A typical policy follows this pattern:

package innqualis.rbac

import rego.v1

default allow := false

allow if {
    input.user.role == "admin"
}

allow if {
    input.user.role == "qa_manager"
    input.action in ["read", "approve"]
}

allow if {
    input.user.role == "user"
    input.action == "read"
    not input.resource.is_confidential
}

Editing a Policy

1. Click the Edit button (pencil icon) on the policy row.
2. Update the Version number and Policy Content as needed.
3. Click Update Policy to save changes.

Caution

The policy name cannot be changed after creation. If you need a differently named policy, create a new one and delete the old one.

Deleting a Policy

1. Click the Delete button (trash icon) on the policy row.
2. Confirm the deletion in the confirmation dialog.

---

Testing Policies

The test framework allows you to validate policies against specific scenarios before they affect production access control.

Running Tests

1. Click the Test button (test tube icon) on a policy row.
2. The test dialog opens with pre-populated sample test cases.
3. Each test case defines:
   • Test Case Name — A descriptive label
   • User ID — The user to simulate
   • Resource Type — Document, Deviation, CAPA, or Training
   • Resource ID — The specific resource (optional)
   • Action — Read, Write, Approve, Reject, or Delete
   • Expected Result — Allow or Deny
4. Click Add Test Case to create additional scenarios.
5. Click Run Tests to execute all test cases against the policy.

Understanding Test Results

After running tests, results appear showing:

• Test Case number
• Pass/Fail status badge
• Expected vs. Actual decision (Allow or Deny)

A test passes when the actual policy decision matches the expected result.

Tip

Create test cases that cover both positive (allow) and negative (deny) scenarios. Include edge cases such as users with multiple roles, confidential resources, and unusual action combinations.

---

Viewing Policy Evaluations

The Evaluations tab shows a chronological log of real policy evaluation decisions made by the system. Each entry includes:

Column	Description
Policy	Which policy was evaluated
User	The user whose access was checked
Resource	The resource type and ID
Action	The action that was requested
Decision	Allow (green) or Deny (red)
Timestamp	When the evaluation occurred

This log is useful for:

• Debugging access issues reported by users
• Auditing who accessed what and when
• Verifying that policy changes produce the expected behavior

---

Version History

Click the History button (clock icon) on any policy to view its version history. This shows previous versions of the policy content, helping you track changes over time and understand when and why access rules were modified.

---

Best Practices

• Version policies incrementally when making changes so you can track the evolution of access rules.
• Test before deploying — Always run the test suite after modifying a policy to catch unintended access changes.
• Use descriptive names — Policy names should clearly indicate what they control (e.g., document_approval_policy, training_access_policy).
• Start restrictive — Default to denying access (default allow := false) and explicitly grant permissions for specific roles and actions.
• Review evaluations regularly — Check the evaluations log periodically to identify unexpected deny decisions that might indicate policy issues.