Policy DSL
Summary
The Policy DSL (Domain-Specific Language) is an expression language for defining policy conditions in Keymate. It provides a declarative syntax for specifying attribute comparisons, logical operators, and context-aware conditions that determine authorization decisions.
Why It Exists
Complex authorization requirements often cannot be expressed through simple role assignments or UI-based condition builders alone. The Policy DSL enables developers to write precise, maintainable policy logic that can reference user attributes, resource properties, and environmental context in a single expression.
Where It Fits in Keymate
The Policy DSL is used within the Policy Engine to evaluate authorization decisions. Policies written in DSL are stored in the policy store and evaluated at runtime when access decisions are requested through the Access Gateway or Permission Gateway.
Boundaries
What it covers:
- Attribute references (user, resource, context)
- Comparison operators
- Logical operators (AND, OR, NOT)
- Collection operations (IN, NOT_IN, CONTAINS)
What it does not cover:
- Policy deployment and versioning (see Policy Lifecycle)
- Visual policy editing (see Dual-Mode Authoring)
How It Works
Policies can operate in two modes: EXPRESSION mode uses the DSL directly, while CONDITIONS mode uses structured condition objects that can be edited through the UI.
Expression Syntax
Expressions reference attributes using dot notation:
user.department == 'engineering'
resource.classification == 'public'
context.ip IN ['192.0.2.0/24']
Comparison Operators
| Operator | Description | Example |
|---|---|---|
EQ / == | Equals | user.role == 'admin' |
NE / != | Not equals | user.status != 'suspended' |
GT / > | Greater than | user.level > 5 |
GE / >= | Greater or equal | context.amount >= 1000 |
LT / < | Less than | resource.risk < 3 |
LE / <= | Less or equal | user.age <= 65 |
IN | Value in collection | user.role IN ['admin', 'editor'] |
NOT_IN | Value not in collection | context.country NOT_IN ['restricted'] |
MATCHES | Regex match | resource.name MATCHES '^doc-.*' |
LIKE | Pattern match | user.email LIKE '%@example.com' |
CONTAINS | Contains substring | resource.tags CONTAINS 'sensitive' |
Logical Operators
Combine conditions using logical operators:
user.department == 'engineering' AND user.level >= 3
user.role == 'admin' OR resource.isPublic == true
NOT (context.country IN ['restricted'])
Diagram
Example Scenario
Scenario
A document management system requires that only engineering managers can approve budget documents over $10,000.
Input
- Actor: User with
department=engineering,role=manager,level=4 - Resource: Document with
type=budget,amount=15000 - Action:
approve - Context: Request from office IP
Expected Outcome
- Granted
- Why: Expression
user.department == 'engineering' AND user.role == 'manager' AND resource.amount > 10000evaluates to true
Common Misunderstandings
- Expression vs Conditions mode — Both achieve the same result; expressions are text-based while conditions are structured objects
- Case sensitivity — Attribute names and string comparisons are case-sensitive by default
String values in expressions must be quoted. user.role == admin is invalid; use user.role == 'admin'.
Design Notes / Best Practices
- Keep expressions readable by using meaningful attribute names
- Use parentheses to clarify operator precedence in complex expressions
- Test expressions with the simulation feature before deployment
Start with CONDITIONS mode in the UI, then switch to EXPRESSION mode to see the generated DSL syntax.
Related Use Cases
- ABAC policies requiring complex attribute comparisons
- Dynamic policies with JavaScript-enhanced evaluation
- Context-aware access control based on environmental factors