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.
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 scrips (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
Read about automation and orchestration.
Refer to External https calls.
Check out the Appgate SDP GitHub home page.
Refer to the Nashorn ECMAScript 6 documentation for details of the features available in the javascript expressions used in AppGate ZTNA.
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 via 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.