.svg "Leapwork")
Blog
Read the latest blogs
The following sections walks through the security aspects of the Leapwork platform, one element at a time.
Part of designing automation flows in Studio is to run the flows in preview mode. This means running the automation flow locally without using an Agent. In preview mode, the automation flows run with the privileges of the account that opened Leapwork. This means that accessing external data sources (databases, network drives, etc.), logging in to proxies, accessing local folders, etc. are executed as if the user was doing all these actions.
The only exception to the above is when a browser is opened as part of a web automation flow. Leapwork uses Selenium as the engine for web automation, and the browser initialized is not opened with the user’s profile. Instead, it is running as ‘Local System’, which has no browser configuration attached. This includes lack of proxy settings, which means that there might be situations where a user can open a normal browser and navigate to a website, but when the browser is opened from Leapwork, the website is not available.
To handle this, specify the proxy settings to use for the web automation flows. This is done under ‘Settings’ – ‘Proxy settings’. These settings work both for running the flows locally in Preview mode and for flows executed using the Controller (e.g. scheduled flows).
The settings should match the settings in the local web browser.
In some cases, the proxy configuration for Studio differs from the one used in the Controller. Here, it is possible to create a proxy configuration for Studio alone. Per default, Leapwork assumes that the proxy configuration for Studio and Controller is identical.
To load plugins, bookmarks, extensions and more, it is possible to use a ‘User Profile’ file in Chrome and Firefox. Find more information here: https://support.leapwork.com/hc/en-us/articles/360000894951
The Controller is a Windows service and runs with the privileges of the account running the service.
All images, configurations, logs, etc. are stored in the Controller’s embedded database. The database files are encrypted using AES 256. You can find more information about the encryption/decryption here.
The database files are located in the ’Assets’ folder on the file system (typically 'c:\Program Files\LEAPWORK\Assets'). The location can be configured in the controller.config file (typically 'c:\Program Files\LEAPWORK').
In most cases, the access to the ‘Assets’ folder should be limited to the service account running the Controller and Administrators.
The only resource that is not included in the embedded database are the video files. These are located in ‘Assets\AutomationRunMedia’ as avi files. It is possible to send UNC-based links to these videos files, so if this feature is in use, the access to this folder needs to be configured accordingly.
When the Controller is sending an automation flow to an Agent, in most cases, the automation flow is executed on the Agent machine. This means that access to external resources, mapped drives, etc. are handled on the Agent machine. There are a few types of setups where the access to the external resources is handled on the Controller:
For web automation cases it is possible to create Environments that point to a Selenium Grid or to cloud based devices or instances hosted by Sauce Labs and BrowserStack. Common for all these Environments is that the automation flows are executed on machines, devices, or instances where the Leapwork Agent most likely is not installed. This means, the “Agent” in this case is the underlying Selenium engine, which does not offer access to external data sources, local command prompts, etc.
In this case, the Controller will execute the part of the flow that needs external access (reading a spreadsheet, executing a query against a database, etc.) and then send the data to the “Agent”. For this, the Controller needs access to files, folders, and databases (ODBC connections) to retrieve the requested data or execute a PowerShell script.
The Controller ships with a public REST API. This API supports integration use cases involving common ALM, CI/CD, etc., platforms such as Jenkins, VSTS and Jira. For the full list of natively supported platforms, please refer to https://www.leapwork.com/services/learning-center/integrations.
Access to the public REST API is managed on the Controller and is configured in “Settings – API Access keys”. To access the end points in the API an API Access key needs to be send as part of the request in an AccessKey header field. See more about using the REST API here: REST API.
It is possible to generate individual keys for all systems using the REST API. The reason for using individual keys, is to allow the possibility to close down/prevent one integration without affecting the other integrations.
The REST API runs with HTTP only. It is not possible to install an SSL certificate and change the protocol to HTTPS. This is because the Controller is only binding methods to the exposed end point and is not running a real web server to handle the SSL handshake. If SSL in considered necessary, it is possible to install the Controller behind a load balancer or similar, that can handle the SSL handshake and offload.
Agent
An automation flow can be run in preview mode, which is used primarily when designing the flow. In all other instances, the automation flow is executed on a machine where an Agent is installed. There are a few exceptions for web automation, see section [Link to exception earlier in this document].
The Agent service is running in ‘Session 0’ and should always be configured to run as ‘Local System’. ‘Session 0’ does not contain any UI elements, so when a flow runs, a new User session/desktop is opened, which allows for UI actions (open applications, move mouse, enter text etc.). The flow will run as the account that is logged into the user session, so sometimes it is necessary to include the Windows login as part of the actual flow.
In the rare cases in which an automation flow triggers an action that requires higher privileges than the user account has, a new secure desktop is opened. This secure desktop typically contains a popup requesting the user to either login as administrator or just approve the actions to be executed. The secure desktop runs as ‘Local System’, which has the highest privileges available, so these popups/screens can also be included as part of the flow.
The communication between the Controller and an Agent uses a remote-control protocol on a configurable port (default: TCP 6777). The connection is encrypted, but it is best practice in a production setup to protect the Agent service with a password. This will prevent misuse of the Agent service.
The password can be specified as part of the installation of the Agent or be configured directly in the agent.config on the machine hosting the Agent service. The file can be found in the LEAPWORK\Agent folder under the installation path (typically 'c:\program files\LEAPWORK\agent\agent.config'). The same password must be specified in the environment defining the Agent.
Automation flows often start by opening applications, websites, etc. where a login is required. This raises the issue of password handling and security.
Leapwork ships with a simple mechanism for securing passwords for e.g. login forms. In the building blocks that type text (“Type Text”, “Type Web Text”, and “Set UI Element Value”) it is possible to set the Type property to “Password”. This means that the text specified in the Text value field – the text that will be inserted – is shown as dots only. This way, the password cannot be picked up by viewing the automation flow or the log from the automation flow.
If a higher level of security is needed, consider setting up a Password Vault server/Secret Server that handles all passwords, and typically allows various kinds of API integration.
