Skip to main content

Dual-Mode Policy Authoring

Summary​

Dual-Mode Policy Authoring allows policy authors to switch between visual UI-based condition building and text-based DSL expressions. This flexibility accommodates different skill levels and use cases — from business analysts using drag-and-drop interfaces to developers writing complex expressions.

Why It Exists​

Authorization policies range from straightforward role checks to complex multi-attribute conditions. A single authoring approach cannot serve all needs effectively. Dual-mode authoring provides the accessibility of visual tools for common cases while preserving the power of expressions for advanced scenarios.

Where It Fits in Keymate​

Dual-mode authoring is available in the Admin Console when creating or editing any policy type. The mode setting is stored with the policy and determines how the policy engine interprets the policy definition.

Boundaries​

What it covers:

  • Switching between CONDITIONS and EXPRESSION modes
  • Visual condition builder for structured policies
  • DSL editor for expression-based policies
  • Automatic conversion between modes (where possible)

What it does not cover:

How It Works​

Policy Modes​

ModeDescriptionBest For
CONDITIONSStructured JSON objects representing conditionsUI-based editing, simple policies
EXPRESSIONText-based DSL expressionsComplex logic, developer workflows

CONDITIONS Mode​

In CONDITIONS mode, policies are defined using structured condition objects:

  • BasicCondition — Single attribute comparison
  • AndCondition — All conditions must be true
  • OrCondition — Any condition must be true
  • GroupCondition — Container for organizing conditions

EXPRESSION Mode​

In EXPRESSION mode, the policy is defined as a text expression:

user.department == 'engineering' AND (user.role == 'manager' OR user.level >= 5)

Mode Switching​

When switching from CONDITIONS to EXPRESSION mode, the system generates the equivalent DSL expression. Switching from EXPRESSION to CONDITIONS is supported for expressions that map to structured conditions.

Diagram​

Example Scenario​

Scenario​

A security team needs to create a policy that grants access to confidential documents only during business hours from approved locations.

Input​

  • Actor: Security analyst
  • Resource: Policy definition
  • Action: Create policy
  • Context: Admin Console

Expected Outcome​

  • Policy created using CONDITIONS mode initially
  • Analyst switches to EXPRESSION mode to add time-based condition
  • Final expression: user.clearance >= 3 AND context.hour >= 9 AND context.hour <= 17 AND context.location IN ['headquarters', 'branch-office']

Common Misunderstandings​

  • Mode affects evaluation — Both modes produce the same authorization result; mode only affects how the policy is authored and stored
  • Automatic conversion limits — Complex expressions may not convert cleanly to structured conditions
warning

Switching from EXPRESSION to CONDITIONS mode may lose precision for complex expressions. Always verify the converted policy.

Design Notes / Best Practices​

  • Start with CONDITIONS mode for straightforward policies
  • Use EXPRESSION mode when you need complex boolean logic or nested conditions
  • Document complex expressions with comments in the policy description
  • Test policies after mode conversion to ensure equivalent behavior
tip

Use the "View as Expression" feature in CONDITIONS mode to learn DSL syntax from your visual conditions.

  • Business analysts creating role-based policies through UI
  • Developers authoring attribute-based policies with expressions
  • Policy migration from other systems using expression import

Policy DSL

Expression language syntax and operators

Simulation & Why Denied

Test and debug policies

Admin Console

Policy management interface

Policy Development Guide

Hands-on policy authoring