Use of Scripts

  • 3 minute read
Prev Next

The AppGate ZTNA system has evolved to allow almost all parts of the access control process flow to be made scriptable. This allows the system to inter-operate with countless external systems and network environments. Effectively the system can now learn who might need what access rights; which actions are allowed when; then the system goes and finds any available live hosts.

Flowchart illustrating device sign-in, token passing, and access criteria processes.

Scripts can be used throughout AppGate ZTNA and perform complex logic, string manipulations and calculations, but an important part of this capability is to allow limited https calls to be made to external systems. For these calls, there is a Secrets store built into AppGate ZTNA so that any credentials required to authenticate to these external systems are not exposed in the scripts themselves or any related logs.

The Access and Identity sections of the admin UI allow you to add a number of these scripts (before using them) in the AppGate ZTNA system. Additionally, assignment criteria scripts can optionally be created directly within policies, access criteria scripts are always created directly within conditions, and resource names are entered directly into the protected hosts field when defining entitlement actions.

Before you Start

Requirements/Considerations

Use of these advanced tools require structured design, engineering and maintenance to ensure that system performance is not impacted and to avoid potential end-user issues. Here are a few of the things that should be considered before embarking on any scripting exercise:

Things to consider

Making calls to external systems

Pre-configure trusted certificates. Certificates relating to the use of https:// to talk to external systems should be added to Trusted Certificates.

Pre-configure any Secrets. Credentials required to authenticate to these external systems should be added to the Secrets store. This ensures that these credentials are not exposed in the scripts themselves or any related logs.

NOTE

This is only used for JavaScript-based scripts, so does not apply to device claim scripts or resource names.

Security

Any appliance JavaScript code runs in a sandboxed Nashorn JavaScript engine which is built in to AppGate ZTNA. The sandboxing refers to the configuration of the JavaScript engine which runs the JavaScript code. For example the JavaScript engine does not allow access to local file system and has only a subset of available java functions (which excludes btoa  and atob).

Trust

Any script which passes through or runs on untrusted environments should be considered untrusted. The most obvious example of this is the device claim script. This is sent to an untrusted machine and is likely to be harvesting data which in itself cannot be trusted. By example the script may be reading a registry setting - but the user of the device may be able to set or influence the value of that registry setting.

Safety

The author of the JavaScript code and the customer is responsible for code safety and the review of the code. For example, programming an endless loop can bring the system down (there is no execution time limitation).

Audit

It is possible to inject log records into the audit logs from a script. This might be useful to help with diagnostics or to provide an audit trail to show how an access decision was reached. This can be done for:

  • Policy assignment scripts on Controllers

  • Condition and entitlement scripts on Gateways​

All you have to do is to include one or more audit log entries in your script such as:

var result = true;
auditLog("OK");
return result;

NOTE

event_type is a mandatory field in all audit logs - and for scripts will appear as an evaluation_log

Scripts supplied by AppGate​

Any script provided by the AppGate Professional Service team or as example scripts from the manual are delivered as is, without warranty of any kind.

AppGate disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose.

Any maintenance needs arising out of the use or performance of these sample scripts (and related documentation) remains the responsibility of the customer.

Related articles