Documentation

Policy Engine

A high-performance authorization engine that evaluates context-aware policies in under 50ms using a declarative YAML-based policy language.

Overview

TigerIdentity's Policy Engine is the decision-making core of the platform. It evaluates access requests against a set of policies written in a human-readable YAML DSL, considering dozens of contextual factors in real-time.

Unlike traditional RBAC systems that only check group membership, the Policy Engine can evaluate:

Identity attributes (department, role, clearance)

Request context (IP, location, device posture)

Resource sensitivity and classification

Time of day and day of week

Risk scores from security tools

Custom business logic

Performance Target: p95 latency under 50ms for policy evaluation, achieved through policy compilation and in-memory rule execution.

Policy Structure

Policies are written in YAML and consist of five main components. Here's the anatomy of a complete policy:

apiVersion: tigeridentity.com/v1
kind: Policy
metadata:
  name: production-database-access
  description: Control access to production databases
  version: 1.2.0
spec:
  # 1. SUBJECTS: Who does this policy apply to?
  subjects:
    - type: user
      attributes:
        department: [engineering, data-science]
    - type: user
      groups: [database-admins]

  # 2. RESOURCES: What resources does this policy govern?
  resources:
    - type: database
      attributes:
        environment: production
        classification: [sensitive, pii]

  # 3. ACTIONS: What operations are allowed/denied?
  actions:
    - read
    - query
    - write  # More restrictive conditions apply

  # 4. CONDITIONS: Under what circumstances?
  conditions:
    # Require MFA for all access
    - require:
        subject.mfa_verified: true

    # Only allow from corporate network or VPN
    - require:
        request.network: [corporate, vpn]

    # Additional conditions for write access
    - when:
        action: write
      require:
        subject.groups: [database-admins, senior-engineers]
        request.time.day_of_week: [monday, tuesday, wednesday, thursday, friday]
        request.time.hour: { gte: 9, lte: 17 }  # Business hours only

    # Deny if risk score is high
    - deny_if:
        subject.risk_score: { gte: 80 }

  # 5. EFFECT: What happens when conditions are met?
  effect: allow

  # Optional: Require approval for certain actions
  approval:
    required: true
    when:
      action: write
      resource.classification: pii
    approvers:
      - type: manager
      - type: group
        name: data-governance
    timeout: 4h

Subjects

Define who the policy applies to using identity types, attributes, groups, or specific principals.

Resources

Specify which resources are governed using resource types, tags, attributes, or ARNs.

Actions

List the operations this policy controls: read, write, delete, admin, or resource-specific actions.

Conditions

Apply context-aware rules using operators like require, deny_if, and when for conditional logic.

Subjects, Resources & Actions

Subject Selectors

Multiple ways to specify who a policy applies to:

subjects:
  # By identity type
  - type: user
  - type: service_account
  - type: api_key
  - type: ai_agent

  # By attributes
  - type: user
    attributes:
      department: engineering
      employment_type: [full-time, contractor]
      security_clearance: { gte: 3 }

  # By group membership
  - type: user
    groups: [admin, senior-engineers]

  # By specific principal
  - principal: "arn:aws:iam::123456789:user/john.doe"
  - principal: "user:[email protected]"

  # All subjects (wildcard)
  - type: "*"

Resource Selectors

Flexible ways to target resources:

resources:
  # By resource type
  - type: database
  - type: s3_bucket
  - type: api_endpoint

  # By attributes or tags
  - type: database
    attributes:
      environment: production
      classification: [pii, financial]
      cost_center: "CC-1234"

  # By specific ARN or ID
  - arn: "arn:aws:s3:::production-data"
  - id: "resource:db:prod-db-01"

  # By pattern matching
  - type: s3_bucket
    name_pattern: "prod-*"

  # All resources of a type
  - type: database
    wildcard: true

Actions

Standard and custom actions:

actions:
  # Standard CRUD actions
  - read
  - write
  - delete
  - admin

  # Resource-specific actions
  - database:query
  - database:schema_change
  - s3:GetObject
  - s3:PutObject
  - api:execute

  # Wildcard (all actions)
  - "*"

Conditions

Conditions are where the power of context-aware authorization shines. Use the full context of the request to make fine-grained decisions.

require - Positive Conditions

All conditions must be true for the policy to match.

conditions:
  - require:
      subject.mfa_verified: true
      subject.device.managed: true
      request.network: [corporate, vpn]
      request.ip_reputation: { lte: 20 }  # Low risk score

deny_if - Negative Conditions

Explicitly deny access when conditions are met.

conditions:
  - deny_if:
      subject.risk_score: { gte: 80 }
  - deny_if:
      request.location.country: [sanctioned_list]
  - deny_if:
      subject.account_status: [suspended, terminated]

when - Conditional Logic

Apply conditions only when certain criteria are met.

conditions:
  - when:
      action: [write, delete]
    require:
      subject.groups: [admin]

  - when:
      resource.classification: pii
    require:
      subject.training_completed: [privacy-101, gdpr-compliance]
      request.reason: { not_empty: true }

Policy Evaluation Order

When multiple policies match a request, TigerIdentity uses a priority-based evaluation system with explicit deny override.

Collect Matching Policies

Find all policies where the subject, resource, and action selectors match the request.

Evaluate Conditions

For each matching policy, evaluate all conditions against the request context. Policies with failing conditions are excluded.

Apply Deny Override

If any policy with effect: deny matches, the request is denied immediately. Denies always win over allows.

Priority Order

If multiple allow policies match, use the highest priority policy. Ties are broken by most recent version.

Default Deny

If no allow policy matches, access is denied by default (implicit deny).

Built-in Functions

Use built-in functions in conditions for complex logic:

Comparison Operators

eq, ne, lt, lte, gt, gte

in, not_in

contains, not_contains

starts_with, ends_with

regex_match

String Functions

lower, upper

trim, split

length

not_empty

Time Functions

now, time_between

day_of_week

hour_of_day

business_hours

Graph Functions

has_relationship

ancestor_of, descendant_of

path_exists

shortest_path

# Example using built-in functions

conditions:
  # Time-based conditions
  - require:
      function: time_between
      args:
        start: "09:00"
        end: "17:00"
        timezone: "America/New_York"

  # Graph query - check if user reports to VP of Engineering
  - require:
      function: has_relationship
      args:
        from: subject.id
        to: "user:[email protected]"
        relationship: REPORTS_TO
        max_depth: 5

  # String manipulation
  - require:
      function: regex_match
      args:
        value: subject.email
        pattern: "^[a-z]+@company\.com$"

Policy Compilation

To achieve sub-50ms evaluation latency, TigerIdentity compiles policies from YAML into optimized executable rules stored in memory.

Compilation Process

Parse YAML and validate syntax
Optimize condition evaluation order
Index policies by subject/resource patterns
Generate bytecode for fast execution

Runtime Evaluation

In-memory rule execution (no database queries)
Parallel evaluation of independent conditions
Short-circuit evaluation (exit on first deny)
Cached identity attributes for common queries

# Policy evaluation API request

curl -X POST https://api.tigeridentity.com/v1/decisions/evaluate \
  -H "Authorization: Bearer ${API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "subject": {
      "type": "user",
      "id": "user:[email protected]",
      "attributes": {
        "department": "engineering",
        "groups": ["senior-engineers"],
        "mfa_verified": true
      }
    },
    "resource": {
      "type": "database",
      "id": "db:prod-customer-db",
      "attributes": {
        "environment": "production",
        "classification": "pii"
      }
    },
    "action": "query",
    "context": {
      "ip_address": "203.0.113.42",
      "user_agent": "PostgreSQL Client/14.2",
      "timestamp": "2026-02-05T10:30:00Z"
    }
  }'

# Response (returned in 23ms)
{
  "decision": "allow",
  "policies_evaluated": 3,
  "matched_policy": "production-database-access:v1.2.0",
  "conditions_checked": 5,
  "conditions_passed": 5,
  "evaluation_time_ms": 23,
  "metadata": {
    "reason": "User is in engineering department with MFA, accessing from corporate network",
    "expires_at": "2026-02-05T14:30:00Z",
    "session_id": "sess_abc123"
  }
}

Performance Guarantees

<50ms

p95 evaluation latency

10,000+

Evaluations per second per node

99.99%

Availability SLA

Write Your First Policy

Start building context-aware authorization policies in minutes.

Start Free Trial Book a Demo

Policy Engine

Overview

Policy Structure

Subjects

Resources

Actions

Conditions

Subjects, Resources & Actions

Subject Selectors

Resource Selectors

Actions

Conditions

require - Positive Conditions

deny_if - Negative Conditions

when - Conditional Logic

Policy Evaluation Order

Collect Matching Policies

Evaluate Conditions

Apply Deny Override

Priority Order

Default Deny

Built-in Functions

Comparison Operators

String Functions

Time Functions

Graph Functions

Policy Compilation

Compilation Process

Runtime Evaluation

Performance Guarantees

Related Documentation

Identity Fabric

Zero Standing Privilege

CAEP Integration

Write Your First Policy