Documentation

Your First Policy

Learn how to create access policies using TigerIdentity's intuitive YAML DSL. This guide walks you through building a complete policy from scratch.

What is a Policy?

A policy is a rule that defines who can access what resources, when, and under what conditions. Unlike traditional role-based access control (RBAC), TigerIdentity policies are dynamic, context-aware, and continuously evaluated.

Key Benefits

Zero Standing Privilege: Access is granted just-in-time and automatically expires
Context-Aware: Decisions consider time, location, device, and risk factors
Continuous Evaluation: Access can be revoked if conditions change mid-session

Policy Structure

Every TigerIdentity policy is written in YAML and follows a consistent structure.

metadata

Policy identification and description

name, description, labels

subjects

Who the policy applies to (users, groups, services)

type: group, id: engineering

resources

What resources can be accessed

type: database, environment: production

actions

What operations are allowed

read, write, delete, admin

conditions

When and under what circumstances access is granted

time, location, MFA, risk score

effect

Whether to allow or deny access

allow, deny

ttl

How long the access grant is valid

8h, 24h, 7d

Example: Engineering Database Access

Let's create a policy that allows engineers to access production databases during business hours, with MFA required and 8-hour session limits.

Complete Policy

version: v1
kind: Policy
metadata:
  name: eng-prod-db-access
  description: Engineers can access production databases during business hours with MFA
  labels:
    team: engineering
    environment: production
    sensitivity: high
spec:
  # Who this policy applies to
  subjects:
    - type: group
      id: engineering
      source: okta

  # What resources can be accessed
  resources:
    - type: database
      environment: production
      tags:
        tier: primary

  # What actions are allowed
  actions:
    - read
    - write

  # Conditions that must be met
  conditions:
    # Time-based condition
    - type: time
      businessHours: true
      timezone: America/Los_Angeles
      days:
        - monday
        - tuesday
        - wednesday
        - thursday
        - friday
      hours:
        start: "09:00"
        end: "17:00"

    # MFA requirement
    - type: mfa
      required: true
      maxAge: 1h  # MFA must be within last hour

    # Device compliance
    - type: device
      mustBeManaged: true
      osMinVersions:
        macOS: "13.0"
        windows: "10.0"

  # Grant access
  effect: allow

  # Access expires after 8 hours
  ttl: 8h

  # Priority (higher number = higher priority)
  priority: 100

Field-by-Field Explanation

Subjects

The subjects section defines who this policy applies to. In this case, anyone in the "engineering" group from Okta.

Resources

The resources section specifies what can be accessed. We're targeting production databases tagged as "primary tier."

Actions

The actions list defines permitted operations. Here, we allow read and write, but not delete or admin actions.

Conditions

Multiple conditions must all be satisfied. Access requires business hours, recent MFA, and a managed device with minimum OS versions.

TTL (Time to Live)

Sessions automatically expire after 8 hours, implementing Zero Standing Privilege. Users must re-authenticate after expiration.

Testing with Simulation Mode

Before deploying a policy, test it using simulation mode to verify the expected behavior.

1. Save Your Policy

# Save the policy to a file
cat > eng-prod-db-access.yaml <<EOF
[paste the policy YAML from above]
EOF

2. Validate Syntax

# Validate the policy syntax
tiger policy validate -f eng-prod-db-access.yaml

# Expected output:
# ✓ Policy syntax is valid
# ✓ All required fields present
# ✓ No conflicting conditions

3. Simulate Access Requests

# Test scenario 1: During business hours with MFA
tiger policy simulate \
  --file eng-prod-db-access.yaml \
  --principal [email protected] \
  --resource db://prod-postgres \
  --action write \
  --context '{
    "time": "2024-01-15T14:00:00Z",
    "mfa_verified_at": "2024-01-15T13:30:00Z",
    "device": {
      "managed": true,
      "os": "macOS",
      "version": "14.0"
    }
  }'

# Output:
# ✓ Access ALLOWED
#   Policy: eng-prod-db-access
#   All conditions satisfied:
#     ✓ Business hours (2:00 PM PST, Monday)
#     ✓ MFA verified (30 minutes ago)
#     ✓ Managed device (macOS 14.0)
#   Session expires: 8 hours

# Test scenario 2: Outside business hours
tiger policy simulate \
  --file eng-prod-db-access.yaml \
  --principal [email protected] \
  --resource db://prod-postgres \
  --action write \
  --context '{
    "time": "2024-01-15T22:00:00Z"
  }'

# Output:
# ✗ Access DENIED
#   Policy: eng-prod-db-access
#   Failed conditions:
#     ✗ Not during business hours (10:00 PM PST)

4. Deploy the Policy

# Deploy to production
tiger policy create -f eng-prod-db-access.yaml

# Verify deployment
tiger policy get eng-prod-db-access

# List all active policies
tiger policy list --environment production

Common Policy Patterns

Here are several real-world policy patterns you can adapt for your organization.

Business Hours Access

Grant access only during specific time windows with automatic expiration.

version: v1
kind: Policy
metadata:
  name: business-hours-access
  description: Allow access during business hours only
spec:
  subjects:
    - type: group
      id: employees
  resources:
    - type: application
      environment: production
  actions:
    - read
    - write
  conditions:
    - type: time
      businessHours: true
      timezone: America/New_York
      days: [monday, tuesday, wednesday, thursday, friday]
      hours:
        start: "09:00"
        end: "17:00"
  effect: allow
  ttl: 8h

Approval-Based Access

Require manager approval before granting elevated privileges.

version: v1
kind: Policy
metadata:
  name: admin-approval-required
  description: Admins require approval for production access
spec:
  subjects:
    - type: role
      id: admin
  resources:
    - type: database
      environment: production
  actions:
    - admin
    - delete
  conditions:
    - type: approval
      required: true
      approvers:
        - type: group
          id: managers
      minApprovals: 2
      expiresIn: 1h
    - type: mfa
      required: true
  effect: allow
  ttl: 4h

Location-Based Access

Restrict access based on IP address or geographic location.

version: v1
kind: Policy
metadata:
  name: geo-restricted
  description: Only allow access from approved countries
spec:
  subjects:
    - type: group
      id: remote-workers
  resources:
    - type: api
      service: customer-data
  actions:
    - read
  conditions:
    - type: location
      countries:
        - US
        - CA
        - GB
      ipRanges:
        - 10.0.0.0/8
        - 172.16.0.0/12
  effect: allow
  ttl: 12h

Risk-Based Access

Grant or deny access based on real-time risk scoring.

version: v1
kind: Policy
metadata:
  name: risk-adaptive
  description: Adjust access based on risk score
spec:
  subjects:
    - type: user
      pattern: "*@example.com"
  resources:
    - type: database
      sensitivity: high
  actions:
    - read
    - write
  conditions:
    - type: riskScore
      maxScore: 50
      factors:
        - impossibleTravel
        - unusualLocation
        - deviceCompliance
        - passwordAge
    - type: mfa
      required: true
      step-up:
        when: riskScore > 30
  effect: allow
  ttl: 1h

Best Practices

Start Restrictive

Begin with the minimum necessary permissions and expand as needed. It's easier to add access than to remove it.

Use Short TTLs

Set appropriate session durations. For sensitive resources, use 1-4 hour TTLs to minimize exposure.

Layer Conditions

Combine multiple conditions for defense in depth. Use time, location, MFA, and device checks together.

Test Thoroughly

Always simulate policies with various scenarios before deployment. Test both allow and deny cases.

Next Steps

Learn Core Concepts

Understand principals, resources, and the TigerIdentity decision engine.

Integrate with Your App

Use the Decision API to enforce policies in your applications.

View API docs

Ready to Build Your Policies?

Start creating dynamic, context-aware access policies with TigerIdentity today.

Start Free Trial Quick Start Guide