Skip to main content
日本語 简体中文 繁體中文

[Access Control] How to Write Access Condition Expressions

Target

  • This article is intended for admins who perform initial setup and operational management of Access Control.

Purpose

  • This article explains how to write Access Control access filter conditions.

Notes

  1. The content of this article is based on the product specifications as of April 2026 and may be changed without notice.
  2. Global admin privileges for Access Control are required to view the actual screens or make configuration changes.
  3. For instructions on how to access the Administration, please refer to the following article.
    　How to Access the Access Control Administration
  4. Write all access filter conditions in half-width lowercase letters.

Procedure 

Use the filter conditions described in this article when configuring the following two items.

1. [Access Control] Create / Edit Access Policy Templates
2. Entrance Pass Issue Condition

1. Available Access Filter Conditions

By combining the following descriptions, you can define the necessary conditions for user access.

IPv4 Range+

ip4:{{CIDR notation}} : If accessed from the specified global IP address, it is considered "Allow".
@{{IP Sets ID}}@ : If accessed from an IP address within the specified IP Sets, it is considered "Allow".

* CIDR reference: Classless Inter-Domain Routing
* IPv6 is not supported at this time.

For instructions on how to create IP Sets, please refer to the following article.
Create IP Sets

[Example 1]

ip4:1.1.1.1　

If the source global IP address of the user attempting to log in is 1.1.1.1, it is considered "Allow".

[Example 2]

ip4:1.1.1.1/25　

If the source global IP address of the user attempting to log in is within the range 1.1.1.1/25, it is considered "Allow".

* "/32" can be omitted.

[Example 3]

@office_tokyo@

If the source global IP address of the user attempting to log in is within the range of IP addresses registered in the office_tokyo IP Sets, it is considered "Allow".

Access Using Device Certificates / Tenant Certificates+

* Cannot be used in the Access Policy Groups setting item [Condition to allow legacy authentication].
If there are two description patterns for a condition, either can be used as they behave the same.

Filter Conditions Pattern 1
(Recommended)		 Pattern 2 Description
Allow access using Device Certificates or Tenant Certificates cert:any None -
Allow access using Device Certificates device_cert:any None Login with Tenant Certificates is not possible.
Allow access using Tenant Certificates cert:tenant None Login with Device Certificates is not possible.
Allow access using Personal Device Certificates cert:personal device_cert:personal -
Allow access using Shared Device Certificates cert:shared device_cert:shared -
Allow access using Passwordless Device Certificates cert:passwordless device_cert:passwordless -
Allow access when neither Device Certificates nor Tenant Certificates are used cert:none None -
Allow access when Device Certificates are not used device_cert:none None -

Access from Secure Browser+

* Cannot be used in the Access Policy Groups setting item [Condition to allow legacy authentication].

hsb:{{true / false}}

[Example]

hsb:true

If accessed using Secure Browser, it is considered "Allow".

Presence of Entrance Pass+

* Cannot be used in the Access Policy Groups setting item [Condition to allow legacy authentication].

has_pass:{{true / false}}

[Example]

has_pass:true

If an Entrance Pass has been distributed to the browser of the user attempting to log in, it is considered "Allow".

Days Since Entrance Pass Issuance+

* Cannot be used in the Access Policy Groups setting item [Condition to allow legacy authentication].

has_pass_within:{{days}}

[Example]

has_pass_within:30

If there is an Entrance Pass cookie issued within 30 days in the browser of the user attempting to log in, it is considered "Allow".

Username+

login_name:{{Access Control Username}} : If a specific username logs in, it is considered "Allow".

[Example] 

login_name:hacadmin

If the username of the user attempting to log in is "hacadmin", it is considered "Allow".

Time Range+

time:HHmm-HHmm:TZ

* Both ends of the specified time range are inclusive.
* If ":TZ" (timezone) is omitted, the default timezone is UTC.

[Example]

time:0900-1800:America/New_York

If the login time of the user attempting to log in is between 9:00 and 18:00 America/New_York time, it is considered "Allow".

Date Range+

date:YYYYMMDD-YYYYMMDD:TZ
date:MMDD-MMDD:TZ

* Both ends of the specified time range are inclusive.
* If ":TZ" (timezone) is omitted, the default timezone is UTC.

[Example]

date:20200101-20200131:America/New_York

If the login time of the user attempting to log in is between January 1, 2020 and January 31, 2020 America/New_York time, it is considered "Allow".

Day of the Week+

day:{{English day abbreviation}}:TZ

* English day abbreviations: sun, mon, tue, wed, thu, fri, sat
* If ":TZ" (timezone) is omitted, the default timezone is UTC.

[Example]

day:wed:America/New_York

If the login time of the user attempting to log in is Wednesday America/New_York time, it is considered "Allow".

Custom User Attributes+

attribute:(ATTRIBUTE_IDENTIFIER):"(Value)"

You can use created custom user attributes to control access.
You can add them to access filter conditions in the following format.

(ATTRIBUTE_IDENTIFIER) is the ID specified when creating the custom user attribute.
For instructions on how to create custom user attributes, please refer to the following article.

Create / Edit Custom User Attributes

Set (Value) to the value of the custom user attribute you want to specify as an access condition.

[Example]

If you set "custom_user_attribute" as the ID of the custom user attribute and want to allow access for users who have the value [allowed_user] for that attribute:

attribute:custom_user_attribute:"allowed_user"

2. Available Operators and Others

Logical Operators (Binary)+

and : If the access status matches both the left and right filter conditions, it is considered "Allow".

[Example]

ip4:1.1.1.1 and device_cert:any

If both "the source global IP address is 1.1.1.1" and "Device Certificate is used" are true, it is considered "Allow".

or : If the access status matches either the left or right filter condition, it is considered "Allow".

[Example 1]

ip4:1.1.1.1 or ip4:2.2.2.2

If either "the source global IP address is 1.1.1.1" or "the source global IP address is 2.2.2.2" is true, it is considered "Allow".

[Example 2]

ip4:1.1.1.1 or device_cert:any

If either "the source global IP address is 1.1.1.1" or "Device Certificate is used" is true, it is considered "Allow".

[Example 3]

@office_tokyo@ or device_cert:any

If either "the source global IP address is within the IP Sets registered as office_tokyo" or "Device Certificate is used" is true, it is considered "Allow".

Logical NOT Operator (Unary)+

not : Negates the result of the filter condition that follows. (not true is "Deny", not false is "Allow".)

[Example]

not ip4:1.1.1.1

If the source global IP address is anything other than 1.1.1.1, it is considered "Allow".

Grouping Filter Conditions+

() : Parentheses group the enclosed filter conditions, giving them processing priority.

[Example]

(ip4:1.1.1.1 or ip4:2.2.2.2) and device_cert:any

In Access Control, (ip4:1.1.1.1 or ip4:2.2.2.2) is evaluated first, and then the result is combined with and device_cert:any to determine the final result. For example, if a user accesses with global IP address 1.1.1.1 and uses a HENNGE Device Certificate, the result is ("true" or "false") and "true", which results in "Allow".

Related Articles 

・Access Control Admin Help