Using Policies

How Policies are used in the Appgate SDP system

Use the Policies UI to create or change Policies

Policies are the front door to the Appgate SDP system and assign rights to a users/devices after a successful sign-in. There are five different classes of Policy that can be assigned:

Access via Gateways based on along with any related Conditions that apply
Admin rights to perform one or more administrative roles (admin UI & APIs)
Device controls which are pushed to the Client (Ringfence rules, Client profile settings, etc)
DNS settings comprising match-domain DNS settings along with the required Entitlements for the DNS servers specified
Stop assigning Policies and do not authenticate the user/device

Policies are enabled on a per-user basis using Claims-based assignment expressions. The Controller manages this process and the resulting settings/Entitlements are then passed to the Client.

After sign-in, the Policies in the system are evaluated to see which should be applied to the user/device. The first Policies to be evaluated are the stop Policies. If any stop Policy is matched then only that Policy is applied and the Policy evaluation process is aborted; so only the first stop Policy will be matched. If no stop Policies are matched then the other 4 classes of of Policy are evaluated. If any other class of Policy is matched then that Policy is applied and the Policy evaluation process continues; so all matched Policies will be applied to any given user/device. Because every other class of Policy will be evaluated, consideration should be given to the total number of Policies and the complexity of the assignment expressions used, as this (lengthy) process will extend sign-in times. The extra time will be about (Policy_count/15)mS; So 1500 Policies would add about 100mS to the typical sign-in time.

Policy Assignment

These claims-based expressions define which user/device a Policy will be assigned to. They are evaluated by the Controller immediately after sign-in or when tokens are renewed. Use static claims that are unlikely to change during the day - such as directory group membership, email address, etc. Each Policy can include one or more criteria expressions.

Remember - you can add access control to an Entitlement which controls whether that Entitlement is actually allowed. This will check that claims meet the relevant access criteria at the point when the user/device actually tries to send traffic to that (protected) host. To understand the differences between Policy assignment criteria and Entitlements access control, refer to What's the difference between Access control and Policy assignment.

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

These in themselves provide a powerful way to specify exactly when a Policy will be assigned. However, criteria scripts provide even more capability when none of the above meet your exact requirements. You might for instance, want to create a Policy which comes into effect at some future point in time. This can easily be done using assignment criteria scripts as shown in the example below:

var today = new Date(); var futureDate = new Date('2030-12-31'); return today > futureDate;

(Assignment) Criteria Scripts

Use the criteria scripts UI to create a new script.

The Appgate SDP system evaluates claims using assignment criteria expressions to make Policy assignment decisions. Normally Policy assignment criteria expressions can be configured within the Policy itself using the assignment tool options and claims pick-list. In such cases there is no requirement to write a separate script as the simplified UI will generate a JavaScript expression for you.

Why use?

There are several reasons why you might want to use a criteria script (as opposed to just a Boolean expression).

The complexity of the Boolean expression required goes beyond what the builder can support.
You switched from custom logic is met to script returns true and made an edit.
An external call is required to harvest claims from some other third party system.
The same criteria expression is to be re-used in several Policies.

Functionality

When a custom script is needed, it may use existing user, device and system claims. This script also executes within the native sandboxed JavaScript engine which supports external httpGet/Post/Put/Delete calls. This script should be as efficient as possible and used sparingly. After sign-in the authorization process will check every Policy (and run any script present) to determine if the related user rights apply. Imagine having a script which takes 2 seconds to run and you have 50 Policies to check - that will take 100 seconds. As an alternative, consider using a User claim script as this will only be run once per sign-in.

After 3 seconds a warning message will be posted to the dashboard naming the offending Policy.
After 15 seconds the script times out.
The Client will also fail-over to the next Controller after 15 seconds (where this process might be repeated!)

To configure

Either

Enter the script directly in Policy under assignment by selecting script returns true.

In Criteria Scripts under assignment select script returns true, create and save a re-usable script.
In Policy under assignment choose criteria script from the drop down select the script from the list.

When a user signs-in and there is no Policy assigned, then an admin message will be sent to the dashboard.

Policy elements

There are five types of Policy which can be provisioned to different user/device groups. Here are some more details about key elements contained in these different Policy types:

*Access Policy*	Entitlements You should pre-define the Entitlements to be included in the Policy. Entitlements can be selected by name or by tag. Include (only) the Entitlements that these particular users require for their roles; avoid using wide ranging, catch all Entitlements. Within a single Policy, you can combine several Entitlements (each with a different type of access control), for example: access at all times (i.e. Always) to essential network resources (such as email) conditional access (e.g. multi-factor authentication required) for higher risk actions (such as access to the customer database) Override Site When you configure an Entitlement a Site must always be specified (tells Appgate SDP where to find this resource). Within the Policy, the Entitlements are grouped together based on the Site setting which is then used to create one Entitlement Token for each Site. When configuring a Policy it is possible to configure the override Site; this will replace the Site(s) originally specified in the Entitlement(s). All the Entitlements specified in that Policy will be grouped together and just one Entitlement token will be created for the override Site. Override Site can be useful in a number of situations: ...from the list - might act as a stop-gap measure while migrating from a classic VPN topology to the SDP model; effectively giving a single point of entry into the Corporate network (traffic would be routed to other Sites over the WAN). ...using a claim - that returns the UUID of the Site to be used. A user claims script would typically be used to set this claim. This could allow the use of a specific Site within a global Collective in the event of some type of system outage or failover. ...nearest Site - the user is given geolocated Site access based on their nearest Site which might for instance help to reduce latency. If more than one Policy has a override Site specified, and the same Entitlement is included in these Policies, then those Entitlements will only be assigned to the Policy with its name nearest to the beginning of the alphabet.
*Admin Policy*	Administrative Roles Policies are also used to assign privileges to administrators. Ensure the Policy criteria expression identifies your administrator(s) and select the pre-defined Admin Roles to be assigned. Refer to Admin user access.
*Device Policy*	We recommend that you only assign one Device Policy. There may be issues when multiple Device Policies are assigned which can contain conflicting requirements, such as two different proxy PAC files. To provide a simple deterministic outcome, when multiple conflicting controls are assigned; the the Policy with its name nearest to the beginning of the alphabet will be used. For more information about the sorts of things that can be set using a device Policy refer to Device and Client controls.
*DNS Policy*	DNS Configuration DNS servers and Match Domains set in the DNS Policy are used by the Client to add a DNS configuration to the local operating system. This will typically comprise a match domain and the associated internal DNS server(s) capable of resolving IP addresses for the protected hosts. If there is no DNS Policy for the user then the DNS settings in the Identity Provider will be used. There may be issues when multiple DNS Policies are assigned which refer to the same match domain. To provide a simple deterministic outcome, when multiple conflicting DNS Policies are assigned; the the Policy with its name nearest to the beginning of the alphabet will be used. For more information about the way the system resolves hostnames refer to DNS and name resolution.
*Stop Policy*	Stop Policies are always evaluated first and abort the Policy matching process on the first match - so these are very quick to evaluate and reduce the load on the Controllers very considerably. We recommend that Clients are only assigned one stop Policy. If you specify more than one the outcome will be in-deterministic. Stop Policies have three main use cases: Security - Normally SPA would be sufficient to prevent unwanted access to the Controllers, however if your SPA key is very widely distributed then with some easily identified criteria (you never want to allow), you can easily set up a stop Policy. You might want to block all Mac devices (os.family = macOS) or connections from Africa (geoIp.continentCode = AF). Stop individual users/devices - You might have some users or devices which you no longer want to allow, these can easily be listed in a stop Policy. You could create assignment criteria using custom logic is met mode with <any below are true> and then add one or more ag.distinguishedName claims. By removing the Client profile, all future connection attempts can be prevented. DoS - Specific groups of users could be temporarily stopped on occasions were Controllers struggle to handle the number of inbound requests either through mis-configuration (headless Clients with no Policy) or some external event (network outage).