How to Create Conditional Access Rules¶

This guide shows you how to create sophisticated access control rules using Peakhour's Edge Access rule engine to implement context-aware security policies.

Before you begin: Ensure you have configured Edge Access authentication and understand the zero trust architecture.

Understanding Policy Actions¶

Edge Access supports five policy actions that determine what happens when a rule matches:

ALLOW - Grant access to the requested resource
BLOCK - Deny access and return 403 Forbidden
BYPASS - Skip authentication requirements (use carefully)
SERVICE_AUTH - Require service token authentication
LOGIN_GATE - Require user authentication via identity provider

Rule Structure and Syntax¶

Edge Access uses Wirefilter syntax for conditional logic. Rules combine fields, operators, and values to create precise matching conditions.

Basic Rule Syntax¶

field operator value

Examples:

ip.src eq "203.0.113.42"
http.host eq "app.example.com"
auth.user.email ends_with "@company.com"

Complex Rules with Logic¶

Combine conditions using and, or, and parentheses:

(auth.user.email ends_with "@company.com" or auth.user.email ends_with "@partner.com") 
and ip.geoip.country ne "CN"

Create Location-Based Access Rules¶

Restrict by Country¶

Use Case: Allow access only from specific countries

Navigate to Edge Access > Rules
Click Create New Rule
Configure rule:

Name: Office Countries Only
Description: Allow access only from US, CA, and GB
Rule: ip.geoip.country in ("US", "CA", "GB")

Block High-Risk Countries¶

Use Case: Deny access from countries with high security risk

Name: Block High-Risk Countries
Description: Block access from sanctioned countries
Rule: ip.geoip.country in ("CN", "RU", "KP", "IR")
Action: BLOCK

City-Level Restrictions¶

Use Case: Limit access to specific metropolitan areas

Name: Major Cities Only  
Description: Allow access only from major office locations
Rule: ip.geoip.city in ("New York", "London", "Tokyo", "San Francisco")

Create User-Based Access Rules¶

Domain-Based User Access¶

Use Case: Restrict access to company email domains

Name: Corporate Users Only
Description: Allow only company email addresses
Rule: auth.user.email ends_with "@company.com"
Action: ALLOW

Multi-Domain Organizations¶

Use Case: Support multiple affiliated organizations

Name: Affiliated Organizations
Description: Allow users from parent company and subsidiaries
Rule: auth.user.email ends_with "@company.com" or 
      auth.user.email ends_with "@subsidiary.com" or
      auth.user.email ends_with "@partner.com"

Department-Specific Access¶

Use Case: Restrict sensitive applications to specific departments

Name: Finance Department Only
Description: Allow only finance team users
Rule: auth.user.email contains ".finance@company.com"
Action: ALLOW

Create Network-Based Access Rules¶

Office IP Allowlist¶

Use Case: Allow access only from known office networks

First, create an IP list: 1. Navigate to Edge Access > Lists 2. Create IP List named office_networks:

203.0.113.0/24
198.51.100.0/24
192.0.2.0/24

Then create the rule:

Name: Office Networks Only
Description: Allow access only from office IP ranges
Rule: ip.src in $office_networks
Action: ALLOW

Block Known Bad Networks¶

Use Case: Deny access from suspicious ASNs

Create an integer list named blocked_asns:

ASNs: 12345, 67890, 54321

Then create the rule:

Name: Block Suspicious ASNs
Description: Block access from known bad network providers
Rule: ip.geoip.asnum in $blocked_asns
Action: BLOCK

Create Application-Specific Rules¶

Path-Based Access Control¶

Use Case: Restrict admin sections to specific users

Name: Admin Section Access
Description: Limit admin paths to admin users
Rule: http.request.uri.path starts_with "/admin" and 
      auth.user.email ends_with "@company.com"
Action: LOGIN_GATE

Method-Based Restrictions¶

Use Case: Allow only read operations for external users

Name: External User Read-Only
Description: External partners can only perform GET requests
Rule: auth.user.email ends_with "@partner.com" and 
      http.request.method ne "GET"
Action: BLOCK

Host-Based Policies¶

Use Case: Different rules for different applications

Name: Production Environment Access
Description: Strict access controls for production
Rule: http.host eq "prod.company.com" and 
      auth.user.email ends_with "@company.com" and
      ip.geoip.country in ("US", "CA")
Action: LOGIN_GATE

Create Device Fingerprint Rules¶

Block Suspicious Clients¶

Use Case: Block requests from known bad fingerprints

Name: Block Malicious Fingerprints
Description: Block requests with suspicious TLS fingerprints
Rule: fingerprint.tls in $malicious_fingerprints
Action: BLOCK

Allow Known Good Clients¶

Use Case: Bypass authentication for known good automated clients

Name: Known Service Clients
Description: Allow trusted service fingerprints
Rule: fingerprint.h2 in $trusted_service_fingerprints
Action: BYPASS

Create Service Authentication Rules¶

API Service Access¶

Use Case: Require service tokens for API endpoints

Name: API Service Authentication
Description: APIs require service token authentication
Rule: http.request.uri.path starts_with "/api/"
Action: SERVICE_AUTH

Mixed Authentication¶

Use Case: Allow both user and service authentication

Name: Flexible API Access
Description: Allow either user login or service token
Rule: http.request.uri.path starts_with "/api/v1" and 
      (auth.user.email ends_with "@company.com" or 
       http.request.headers["Authorization"] starts_with "Bearer")
Action: ALLOW

Combine Rules into Policies¶

Create Comprehensive Policy¶

Navigate to Edge Access > Policies
Click Create New Policy
Configure policy settings:

Name: Corporate Access Policy
Description: Comprehensive access control for corporate users
Application: app.company.com

Add Rules in Priority Order¶

Add rules in order of evaluation (higher priority first):

Block Rule (Priority 1):

Rule: ip.geoip.country in $blocked_countries
Action: BLOCK

Admin Access Rule (Priority 2):

Rule: http.request.uri.path starts_with "/admin" and 
      auth.user.email matches ".*\\.admin@company\\.com"
Action: LOGIN_GATE

General User Rule (Priority 3):

Rule: auth.user.email ends_with "@company.com" and
      ip.geoip.country in ("US", "CA", "GB")
Action: ALLOW

Default Deny (Priority 4):
```
Rule: true
Action: BLOCK
```

Test Your Rules¶

Use Rule Simulation¶

Navigate to Edge Access > Rules > Test Rules

Enter test conditions:

IP Address: 203.0.113.42
User Email: john.doe@company.com
Host: app.company.com
Path: /dashboard
Country: US

Click Simulate to see which rules match

Review Analytics¶

Navigate to Edge Access > Analytics
Review policy evaluation results:
Successful authentications
Blocked access attempts
Rule match patterns
User access patterns

Advanced Rule Patterns¶

Time-Based Logic (Using Lists)¶

While direct time conditions aren't supported, use maintenance lists:

Name: Maintenance Mode
Description: Block access during maintenance windows
Rule: http.host in $maintenance_hosts
Action: BLOCK

Complex User Agent Rules¶

Filter based on user agent patterns:

Name: Block Automated Tools
Description: Block known scanning tools
Rule: http.user_agent matches ".*(curl|wget|scanner).*"
Action: BLOCK

Troubleshooting Rules¶

Common Issues¶

Rule Not Matching:

Verify field names exactly match available fields
Check operator syntax (use eq not ==)
Ensure string values are quoted
Validate list references use $ prefix

Performance Issues:

Place most specific rules first
Use lists instead of long or conditions
Avoid complex regex patterns where possible

Testing Strategies¶

Start Simple: Begin with basic rules and add complexity
Use Simulation: Test rules before deployment
Monitor Analytics: Watch for unexpected blocks or allows
Gradual Rollout: Deploy to test users first

Security Best Practices¶

Default Deny: Always end policies with a catch-all block rule
Principle of Least Privilege: Start restrictive and add exceptions
Regular Review: Audit rules monthly for relevance
List Management: Keep IP and domain lists updated
Monitor Analytics: Watch for bypass attempts and policy violations

Your conditional access rules are now configured to provide context-aware security that adapts to user location, device characteristics, and application requirements while maintaining the principle of least privilege access.