Configure conditions

Defines criteria and user actions used to control when the network resources in can be accessed. You may wish to review the Before you start. When you're ready to Configure Conditions, complete the fields in the form.

Actions

The Actions menu allows you to test access based on the settings below.

Add/Edit Condition

Access Criteria

Setting Modes

List mode provides three options to configure the criteria that need to be true in order for access in an Entitlement to be allowed. Selecting a claim will automatically display the relevant parameters.

Switch to Script Mode

NOTE

Script mode is available for very advanced use cases. However this may break compatibility with the other 3 modes.

Script mode

By using the script editor it is possible to edit existing expressions or to create your own. The JavaScript engine is run in a sandbox preventing any file system access, however it is possible to make external calls using:

HTTP PUT

HTTP POST

HTTP GET

HTTP DELETE

This would for instance allow a value to be passed to an external system for validation as part of the expression. Refer to access criteria script for more information on scripting.

Criteria Combining Mode

Criteria expressions have three different combining modes (without using scripts):

• <all criteria below must be true> - a logical AND of different criteria needs to equate to true

• <at least one of the criteria below must be true> - a logical OR of different criteria needs to equate to true

• <Criteria are met according to custom logic> - a simple Boolean expression comprising a number of different criteria needs to equate to true

Condition based access provides more information and examples

Criteria

By selecting criteria that include dynamic Claims (that change during a session), you can create access criteria expressions that enable Appgate SDP to respond to changes in a timely manner. For example, clientSrcIP claim can be used to remove access to protected resources when the user leaves the office to work from home. Conditions can include multiple criteria, so you will need to decide how to combine the access criteria. There is also a Script mode for advanced use cases.

User response claims

At the top of the pick list are three user response claims: Provided MFA, Provided Reason, or Password. Unlike all other claims, which are hard-coded or pre-configured (for instance within the identity provider), user interaction names are defined within the Condition itself. When Configured with a claim suffix (name) and time period (if required) then a new user response claim (using that name) is automatically created.

User response claims gives more details and examples about the built in check method used and how this ties into the naming of these types of claims.

Other claim types

As you build expression you will be prompted for the necessary parameters according to the claim selected.

User claims example

"groups match": use this option to check for membership of an LDAP group.

The match operator uses exact match; while testing the LDAP "groups" claim with contains operator,  you need to provide the whole FQDN of the group name. For example:

CN=group3,OU=sweden,DC=cryptzone,DC=com", "CN=group4,OU=sweden,DC=cryptzone,DC=com

We do not recommend using partial matches for security reasons but you can do this in the Javascript editor.

You can flatten "groups" claim to a single string: var all_groups = claims.users.groups.toString()  then check the group name var match= all_group.indexOf('CN=Developers,') > -1;

Note the trailing comma in the example, make sure to include trailing comma for security reasons so there are no un-intentional matches like CN=Developers Inactive, OU= vs CN=Developers, OU=..

Device claims example

"os.family": use this option to include devices with a particular OS e.g. windows.

"isFirewallEnabled": use this option to check for a device firewall

NOTE

Any device claims or on-demand claims which return yes/no, true/false, etc will be evaluated as a string. Any values that should NOT be treated as a string need to be handled using <script returns true> mode.

System Claims example

"clientSrcIP": use this option to look for an exact IP address for connecting clients e.g. 19.34.6.120.

You can include multiple user interactions in your access criteria, for example: if you want track why a user requires access, you can combine <Provided Reason> and <Provided MFA> to access a protected resource. Claims in detail provides details about all the different access criteria available.

Custom Logic

Only present when using <Criteria are met according to custom logic> mode. The numbered Criteria (set above) can be combined in a simple Boolean expression.

When using 'Custom Logic' then the only operators that are allowed are: AND OR NOT ( ). When removing access criteria from an expression you must delete (edit) the numbered line item and edit the Custom Logic to remove any reference to the numbered item or it will not be removed from the underlying JavaScript expression.

User Actions

Used to display a message or a user interaction prompt on the user's device when the access criteria expression fails.

NOTE

If the access criteria include <Provided MFA>, <Retyped password> or <Provided reason> claim(s), you must enter the same claim suffix for it to work correctly.

Example 1: if you have set an access criteria <Provided reason> with the claim suffix (name) of name1 then there must a matching <Provide reason> user interaction with a user response claim suffix of name1 - this enables the user to enter the required reason.

Example 2: if you have set an access criteria <Retyped password> with the claim suffix (name) of pass1 every 120 minutes then there must be a matching <Password> user interaction with a user response claim suffix of pass1 with message "Please enter your password".

Complete the required fields:

Type of Interaction

Select the type of user interaction required.

• Display Message

• Require MFA

• Provide Reason

• Password

Then fill any additional fields:

Message

Enter the text message to be displayed to the user. This should help explain to the user what has happened and the action required. Remember users may have more than one User Interaction configured so it is very important to be VERY clear about which one (or Collective) this is. Limited HTML and variables can be used. See Messaging the user for details.

Radius

If you are using a RADIUS identify provider, you can use %RADIUS_MESSAGE% to use the reply-message (24) from the RADIUS server. For example: Require MFA named <string> with text "%RADIUS_MESSAGE%"

Claim Suffix

This will set a user response claim with this name. The same name should be used in the related access criteria. If you are configuring MFA at sign-in and also plan to use an MFA user interaction, then if you use the same user response claim suffix for both - you can avoid the user having to perform MFA twice over a short period of time.

MFA Provider

Select the MFA provider used to validate the user interaction. The default OTP provider is shown by default.

Identity Provider

Select the Identity Provider used to validate the user's password. Defaults to the one used at sign-in.

Multiple User Actions

You can add multiple user interactions and select between one of these or all of these having to be performed by the user. For one of these; the Client will display the first user interaction with any related prompt/message and provide a link to a page where all the configured user actions are listed in the order set in the admin UI.

For all of these; the Client will display the first user interaction with any related prompt/message and then the next etc in the order set in the admin UI. The up/down arrows allow the list to be reordered.

Re-Evaluation

Access criteria expressions can be re-evaluated to enable Appgate SDP to respond to changes in a timely manner.

Periodic Re-Evaluation (UTC)

The Gateway will re-evaluate a user's claims periodically. Mainly required when using password and MFA user interactions to check if the related claims are still valid. This option forces a periodic re-evaluation on the hour, every 15minutes or every 5 minutes. For many Conditions there is no typical use case for using this option as the Gateway knows when to re-evaluates a user's Entitlements. By example: device claims are checked every 5 minutes and re-evaluated if changed. There are 2 situations where periodic evaluations might be required:

• with user interactions where the life time of the claim is set to less than the Claims Token life time. A periodic check is required to see if these have expired yet.

• with Conditions that require periodic checking: i.e. seeing if an external system is still reporting that it is doing backups.    

For more information about the use of periodic re-evaluation times, refer to: Real-time re-evaluation

Time of Day for Re-Evaluation (UTC)

The Gateway will re-evaluate a user's claims at these times. Required if the access criteria includes a temporal element such as 'only after 17:00'. This option allows you to force re-evaluation at a particular fixed time of day based on UTC. For many Conditions there is no typical use case for using this option as the Gateway knows when to re-evaluates a user's Entitlements. There are 2 situations where a specific time based re-evaluation might be required:

• used in conjunction with a particular time-based Condition such as requiring all users to be disconnected ahead of a server backup.

• with Conditions that need to be evaluated at a specific time.

For more information about the use of specific re-evaluation times, refer to: Real-time re-evaluation