You can compare requests, attributes, constant values, and regular expressions in conditions. Conditions can also serve as targets that define when a policy or rule applies to a decision request. For example, you can target a rule so that it applies when a payment amount is greater than or equal to a payment limit.

Screen capture showing a condition comparing a Payment Amount attribute to a Payment Limit attribute using the Greater Than Or Equal comparator.

When you define a condition, on the left side, select an attribute or request type that represents unknown or variable information to be validated. On the right side, enter known or predefined criteria in the form of an attribute, request, or constant value. This keeps logical statements consistent regardless of what’s being compared. You can drag collapsed conditions to change their order, as needed.

You can add conditions directly to resolvers and rules or define them on the Components tab of the Library as reusable named conditions.

Condition comparators

You can use the following comparators in condition comparisons.

Note:

For simplicity, the table groups logical comparator pairs together, but you can only use one comparator at a time in a condition.

Attribute comparators
Comparator Supported data types Description

Contains

Does Not Contain

Collection, String

Checks whether a string or collection contains, or doesn’t contain, another string. Use this comparator when you know part of a value that you want to check.

Note:

Matches for strings can differ from matches for collections. For example, the string 1234 contains the constant 23, but the collection [1234] does not contain this constant. One possible matching collection for the constant 23 is [21, 22, 23].

Contains Claim Pair

Does Not Contain Claim Pair

String

Add defense in depth by validating token claims as part of the authorization layer. Checks whether a JSON Web Token (JWT)JSON Web Token (JWT)JWT An IETF standard container format for a JSON object used for the secure exchange of content, such as identity or entitlement information. To read the industry standard, see RFC 7519 contains a given claim pair. Encrypted tokens are not supported.

To create a comparison:

  1. Select an attribute of type String that resolves to a JWT.
  2. Select the Contains Claim Pair or Does Not Contain Claim Pair comparator.
  3. Enter a claim pair using the syntax <claim-name>=<claim-value>.
    Note:

    The claim value has to exactly match one of the possible values of that claim contained in the token. For example, aud=api1 will match against a token containing the claim "aud": "api1" or "aud"=["api1", "api2"].

To check a multivalued claim, create a comparator for each value you want to check. Multivalued scope claims in the token must be expressed as a list of space-delimited, no-space strings.

Ends With

Does Not End With

String

Checks whether a string ends with, or doesn’t end with, another string.

Equals

Does Not Equal

Boolean, Collection, Date, Date Time, Duration, JSON, Number, Period, String, Time, XML, Zoned Date Time

Checks whether two values are equal or not equal.

Greater Than

Less Than

Boolean, Date, Date Time, Duration, Number, String, Time, Zoned Date Time

Checks whether a value is greater than, or less than, another value.

Greater Than Or Equal

Less Than Or Equal

Boolean, Date, Date Time, Duration, Number, String, Time, Zoned Date Time

Checks whether a value is greater than or equal to, or less than or equal to, another value.

Has Valid Signature For JWKS

Has Invalid Signature For JWKS

String, JSON

Add defense in depth by validating tokens as part of the authorization layer. Checks the following for a JWT:

  • Whether the signature can be verified using one of the public keys in the JSON web key set (JWKS)
  • If a token expiry was set, whether the token is expired

A valid token must have a verified signature and not be expired.

Note:

Only RSA-encoded signatures are currently supported. Encrypted tokens are not supported.

To create a comparison:

  1. Select an attribute of type String that resolves to a JWT.
  2. Select the Has Valid Signature For JWKS or Has Invalid Signature For JWKS comparator.
  3. Select a JSON attribute that resolves to a JWKS.

In CIDR Block

Not In CIDR Block

String

Simplify adding network checks to support your zero trust policies. Verifies whether a user’s IP address is in, or not in, an IP subnet range. IPv4 and IPv6 addresses are supported.

To create a comparison:

  1. Select an attribute that resolves to a valid IP address.
  2. Select the In CIDR Block or Not In CIDR Block comparator.
  3. Enter the IP address range as a constant or select an attribute that resolves to the IP address range.

You must express the IP address range in Classless Inter-Domain Routing (CIDR) notation (the bitmask indicates the size of the routing prefix):

IP address/bitmask

For example, consider a condition that checks for IP addresses between 192.0.2.0 - 192.0.2.15. CIDR notation for this range is 192.0.2.0/28. If the IP address attribute resolves to 192.0.2.1, for example, the condition evaluates to true.

Tip:

For help expressing an IP address range in CIDR notation, use a CIDR calculator.

Is In

Is Not In

Collection, String

Checks whether a string or a collection is in, or not in, another collection.

Regular Expression

String

Checks whether a string matches a regular expression.

Starts With

Does Not Start With

String

Checks whether a value starts with, or doesn’t start with, another value.
Request comparators
Comparator Description

Matches

Does Not Match

Checks whether the inbound request name starts with, or does not start with, the conditional request name.

Note:

For Matches to be true, the inbound request name must contain the entirety of the conditional request name. For example, if the conditional domain is BankingChannels.OnlineBanking, a request domain of BankingChannels evaluates to false.

Equals

Does Not Equal

Checks whether the inbound request equals, or does not equal, the conditional request.