Conditions
Conditions provide fine-grained control over when IAM policies apply. They allow you to specify additional constraints that must be met for a policy statement to take effect, such as time-based access, IP restrictions, or resource-specific attributes.Condition Structure
Conditions are specified in theCondition element of a policy statement:
Condition Operators
String Conditions
Equals
Exact string match (case-sensitive).NotEquals
String does not match (case-sensitive).StringLike
Pattern matching with wildcards (* and ?).
StringNotLike
Pattern does not match.Numeric Conditions
NumericEquals
Exact numeric match.NumericLessThan
Numeric value is less than specified.NumericGreaterThan
Numeric value is greater than specified.Date/Time Conditions
DateEquals
Exact date/time match.DateGreaterThan
Current time is after specified date.DateLessThan
Current time is before specified date.Boolean Conditions
Bool
Boolean value match.IP Address Conditions
IP address conditions use thenetwork: namespace and evaluate the request’s source IP address in-memory (no database query). They can be combined with other condition types using AND logic.
Supported value formats:
- Exact IP:
"192.168.1.50"— matches a single address (treated as/32). - CIDR range:
"10.0.0.0/8"— matches any address in the subnet. - Array:
["192.168.1.0/24", "10.0.0.0/16"]— matches if the source IP falls within any entry (OR logic).
Only IPv4 addresses are supported. IPv6-mapped IPv4 addresses (e.g.,
::ffff:192.168.1.50) are automatically normalized to their IPv4 equivalent.IpAddress
Allow-list — the request must originate from one of the specified IPs or ranges. If the source IP does not match any entry, the request is denied.NotIpAddress
Deny-list — the request must not originate from any of the specified IPs or ranges. If the source IP matches any entry, the request is denied.Condition Keys
Network Namespace (network:)
Keys for network-level request attributes. Thenetwork: namespace is used with IP address condition operators.
network:sourceIp
IP address of the request source. Supports exact IPs, CIDR ranges, and arrays. Used withIpAddress and NotIpAddress operators only.
Context Namespace (context:)
Keys for request-level context attributes.context:currentTime
Current date and time of the request.context:userAgent
User agent string of the request.context:multiFactorAuthPresent
Whether multi-factor authentication was used.Service-Specific Condition Keys
Session Namespace (session:)
session:proctorAccountSid
Proctor account assigned to the session.session:schedulingModule
Scheduling system used for the session.session:status
Current status of the session.session:examType
Type of exam being proctored.User Namespace (user:)
user:role
User’s role in the system.user:department
User’s department affiliation.user:accountType
Type of user account.Assessment Namespace (assessment:)
assessment:type
Type of assessment.assessment:status
Current status of the assessment.Multiple Conditions
AND Logic (Multiple Operators)
All conditions must be true.OR Logic (Multiple Values)
Any value can match.Complex Logic
Combining AND and OR logic.Common Use Cases
Time-Based Access
Business Hours Only
Exam Period Access
Location-Based Access
Campus Network Only
Only allow access from campus IP ranges.Block Specific IPs
Deny access from specific IP addresses or ranges.Subnet Carve-Out
Allow a broad range but deny a specific subnet within it. Both conditions must be true (AND logic).Deny All Except Trusted Networks
Use a Deny statement withNotIpAddress to block everything outside the allowed ranges.
Role-Based Conditions
Department-Specific Access
Instructor-Only Features
Session-Specific Conditions
Assigned Proctor Only
Specific Scheduling Systems
Security Conditions
MFA Required for Sensitive Actions
Trusted User Agents Only
Advanced Patterns
Conditional Deny
Deny access unless conditions are met.Time-Window Access
Allow access only during specific time windows.Dynamic Resource Access
Access based on resource attributes.Best Practices
1. Use Specific Conditions
2. Combine Multiple Conditions
3. Use Deny for Security
4. Test Conditions Thoroughly
Always test conditions in a development environment before deploying to production.Troubleshooting
Common Issues
- Case Sensitivity: String conditions are case-sensitive
- Date Formats: Use ISO 8601 format for dates
- IP Ranges: Use CIDR notation for IP addresses (e.g.,
192.168.1.0/24) - Multiple Values: Use arrays for OR logic
- Variable Substitution: Ensure variables are properly formatted
- IP Operator Namespace:
IpAddressandNotIpAddressoperators only work with thenetwork:namespace — they cannot be used withsession:or other namespaces - Missing Source IP: If the source IP cannot be determined from the request, the condition will fail closed (access denied)
IP Address Troubleshooting
- Invalid CIDR notation: Ensure IP ranges use valid CIDR format (e.g.,
10.0.0.0/8, not10.0.0.0/33). Invalid CIDR values will cause the condition to fail closed. - IPv4 only: Only IPv4 addresses are supported. IPv6-mapped IPv4 addresses (
::ffff:x.x.x.x) are automatically normalized, but pure IPv6 addresses are not supported. - Proxy headers: When behind a load balancer or proxy, the source IP is extracted from the
X-Forwarded-Forheader (leftmost entry). Ensure your proxy is correctly setting this header. - Unexpected denials: If requests are unexpectedly denied, verify the client’s actual IP address matches the CIDR range in the policy. Remember that a single IP like
192.168.1.50is treated as192.168.1.50/32.
Debugging Tips
- Log Condition Evaluations: Enable detailed logging
- Test Individual Conditions: Test each condition separately
- Validate Syntax: Use JSON validators for policy syntax
- Check Variable Values: Verify variable substitution works correctly
