This document provides quick policy patterns for common authorization scenarios. Each recipe includes the policy configuration and explanation of when to use it.
For comprehensive real-world scenarios with complete setup workflows, see the Policy Cookbook. For formal policy evaluation details, see the Algorithm Reference. For the policy language details, see the Language Reference.
The simplest policy - grant read access to anything under the public path.
{
"name": "public-read",
"description": "Allow anyone to read public resources",
"engine": "Prefix",
"deny": false,
"statements": [
{
"rules": {
"action": "read",
"object": "hc://<domain-uuid>/public/"
}
}
]
}
Note: Replace
<domain-uuid>with your actual domain UUID (e.g.,550e8400-e29b-41d4-a716-446655440000).
When to use: Landing pages, public documentation, shared assets.
Use macros to let users manage their own profile and settings.
{
"name": "self-service",
"description": "Users can access their own resources",
"engine": "Fixed",
"deny": false,
"statements": [
{
"rules": {
"subject": "$current_user()",
"object": "hc://<domain-uuid>/users/$current_user()/profile"
}
}
]
}
Note: Replace
<domain-uuid>with your actual domain UUID.
When to use: User profiles, personal settings, private documents.
The following recipes demonstrate different pattern matching approaches using the Fixed, Prefix, and Regex engines. For more complex real-world scenarios that combine multiple policies, see the Policy Cookbook.
Allow access to all PDF documents in a directory tree.
{
"name": "pdf-access",
"description": "Access to PDF files in reports directory",
"engine": "Regex",
"deny": false,
"statements": [
{
"rules": {
"action": "read",
"object": "hc://[a-f0-9-]{36}/reports/.*\\.pdf$"
}
}
]
}
Matches: hc://550e8400-e29b-41d4-a716-446655440000/reports/quarterly.pdf, hc://550e8400-e29b-41d4-a716-446655440000/reports/archive/annual.pdf
When to use: Document management systems, file-type-specific permissions.
Authorize users based on their email domain.
{
"name": "company-email-access",
"description": "Allow access to users with company email",
"engine": "Regex",
"deny": false,
"statements": [
{
"rules": {
"subject": ".*@acme-corp\\.com$",
"action": "read",
"object": "hc://[a-f0-9-]{36}/internal/.*"
}
}
]
}
Matches: alice@acme-corp.com, bob@acme-corp.com
Does not match: alice@gmail.com, attacker@fake-acme-corp.com
When to use: Organization-wide access, corporate resource sharing.
Allow access to any single-digit API version.
{
"name": "api-access",
"description": "Access to API v1-v9",
"engine": "Regex",
"deny": false,
"statements": [
{
"rules": {
"action": "read",
"object": "/api/v[0-9]/users/.*"
}
}
]
}
Matches: /api/v1/users/alice, /api/v2/users/bob
Does not match: /api/v10/users/alice (two digits)
When to use: Multi-version API deployments, backward compatibility scenarios.
Match resources across domain-specific paths.
{
"name": "domain-docs",
"description": "Access to documents in any domain",
"engine": "Regex",
"deny": false,
"statements": [
{
"rules": {
"action": "read",
"object": "hc://[a-f0-9-]{36}/documents/.*"
}
}
]
}
Matches: hc://550e8400-e29b-41d4-a716-446655440000/documents/readme, hc://a1b2c3d4-e5f6-7890-abcd-ef1234567890/documents/archive/old
When to use: Multi-domain systems, shared document repositories.
Match any role with admin suffix.
{
"name": "admin-roles",
"description": "Access for any admin role",
"engine": "Regex",
"deny": false,
"statements": [
{
"rules": {
"role": ".*-admin$",
"action": "write",
"object": "hc://[a-f0-9-]{36}/config/.*"
}
}
]
}
Matches roles: billing-admin, system-admin, docs-admin
Does not match: admin, admin-viewer
When to use: Role-based access control (RBAC) with naming conventions.
Use deny policies to explicitly block access regardless of other policies.
{
"name": "block-secrets",
"description": "Block access to secret files",
"engine": "Regex",
"deny": true,
"statements": [
{
"rules": {
"object": "hc://.*/secrets/.*"
}
},
{
"rules": {
"object": "hc://.*\\.env$"
}
}
]
}
Important: Deny policies take precedence. If this matches, access is denied even if other policies would allow it.
When to use: Defense-in-depth for critical resources, compliance requirements. See Scenario 2 in the Policy Cookbook for a complete secrets management example.
Match AWS-style resource identifiers.
{
"name": "s3-bucket-access",
"description": "Access to production S3 buckets",
"engine": "Regex",
"deny": false,
"statements": [
{
"rules": {
"object": "arn:aws:s3:::.*-production$"
}
}
]
}
Matches: arn:aws:s3:::app-production, arn:aws:s3:::data-production
When to use: Cloud resource authorization, AWS integration scenarios.
Let users access their own tenant's resources with pattern matching.
{
"name": "tenant-self-service",
"description": "Users can access their tenant's documents",
"engine": "Regex",
"deny": false,
"statements": [
{
"rules": {
"subject": "$current_user()",
"object": "hc://$requestors_tenant()/documents/.*"
}
}
]
}
This combines the $requestors_tenant() macro with regex patterns for flexible yet scoped access.
When to use: Multi-tenant SaaS applications, customer data isolation.
| Scenario | Recommended Engine | Why |
|---|---|---|
| Exact resource match | Fixed | Fastest, no pattern overhead |
| Hierarchical paths | Prefix | Simple, matches everything under a path |
| Complex patterns, alternation | Regex | Full regex power for sophisticated matching |
Performance considerations: Use the simplest engine that meets your needs. Fixed and Prefix engines have lower computational overhead than Regex.
Security note: Complex regex patterns can be computationally expensive. For security-critical policies, prefer Fixed or Prefix engines when possible.