Automation Engine

This page outlines the new features and functions implemented in this version of the Automation Engine:

TLS/SSL Implementation

As of this version, the communication between the Automation Engine, the Automic Web Interface, the Java API, and the Proxy Client as well as between the Automation Engine, the TLS/SSL Agents (Java, Windows, UNIX Agents) and the TLS Gateway uses TLS/SSL through a secure WebSocket (WSS). These components establish a connection with the Java communication process (JCP) and/or the REST process (REST), which use trusted certificates to prove their identity to other communication partners. To work with these certificates, the processes require a keystore, which must be created beforehand using pkcs12 format.

Note: The TLS/SSL implementation does not apply to the HP-UX and 32 bit ZLINUX Agents, as they are no longer supported in this version.

Depending on your security needs, there are different options for certificates. However, using certificates signed by a public Certificate Authority can simplify the TLS/SSL installation and configuration. Make sure that you attach the whole chain of trust (intermediate and root certificate authority) to the certificate.

You also have to define all relevant parameters in the configuration (INI) file of each component.

The Java default cipher suite of the JCP is used to configure the TLS/SSL connection. You can change the supported cipher suites in the Java security policy.

Education

The Broadcom Software Academy provides a wide range of free online trainings. If you have not already done so, register at Broadcom Software Academy to start profiting from our education offer.

The following course on Automic Automation and TLS/SSL is available now:

  • Automic Automation TLS and Certificates

For more information, see Free Online Courses

More information:

New REST Process and Java Communication Process (JCP)

Until version 12.3, the Java communication process (JCP) was used partly to provide a REST endpoint for the Automation Engine. The new REST process covers this functionality now while the new Java communication process (JCP) functions as a communication process (CP) for components that use TLS/SSL and WebSockets.

With the TLS/SSL implementation, the Automation Engine, the Automic Web Interface, the Proxy Client, the TLS/SSL Agents (Java, Windows, UNIX Agents), and the TLS Gateway establish a connection with the new Java communication process (JCP).

This means that upgraded components that used to connect to a communication process (CP) must connect to a Java communication process (JCP).

More information:

New TLS Gateway Component

The TLS Gateway is a new component of the Automation Engine that allows non-TLS/SSL Agents to connect to the Automation Engine. This means that you can use an industry-standard communication channel between Agents from previous versions or current BS2000, NSK, OS/400, VMS and z/OS Agents and the Automation Engine. The TLS Gateway also facilitates secure file transfer with one or two non-TLS/SSL Agents.

It is recommended installing the TLS Gateway close to the Agents it supports, thus reducing the distance of your less secure communication channel. However, you can install it centrally and establish a connection with multiple Agents.

Note: Although the TLS Gateway is an Agent object, it has no Agent functionality (task execution, monitoring, reporting) built in. It only functions as a proxy that sends messages over a secure channel.

If you need to continuously support non-TLS/SSL Agents in your system after upgrading to this version, you need the TLS Gateway. In this case, it is recommended to keep your communication processes (CPs) running. Otherwise, once you have upgraded you Agents to their TLS/SSL versions, you can uninstall the communication processes (CPs) and the TLS Gateway instances.

The TLS Gateway can also be configured to provide a communication process (CP) port for non-TLS/SSL Agents, if needed. This is helpful in systems in which no communication processes (CPs) run. However, it is not recommended to operate with a mix of CPs and TLS Gateway CP ports. Therefore, this functionality is deactivated by default and must be explicitly enabled.

If you are using a TLS Gateway as a CP port, you have to define the relevant parameters in the INI file of the TLS Gateway. You can also use it in a particular net area.

You can use scripts to easily create, download and extract TLS Gateway packs, as well as start them.

Education

The Broadcom Software Academy provides a wide range of free online trainings. If you have not already done so, register at Broadcom Software Academy to start profiting from our education offer.

The following course on Automic Automation and TLS/SSL is available now:

  • Automic Automation TLS Gateway

More information:

INI File Changes

With the TLS/SSL implementation and the introduction of the new Java communication process as well as the the new TLS Gateway component and the Automic Automation Kubernetes Edition, the following INI file changes have been implemented:

AE INI File

  • The [PORTS] section now includes the WS.PORT= parameter that allows you to define the ports for incoming WebSocket connections.

  • The new [TLS] section allows you to define the relevant key and keystore parameters:

    • keystore=

    • keystorePassword=

    • keyPasssword=

    • keyAlias=

    These parameters were previously located in the [REST] section of the INI file and have been moved to the TLS section.

  • The new [CONTAINER] section is only relevant in the Automic Automation Kubernetes Edition and is automatically set by the Install Operator. The readinessFile = parameter shows if the a readiness file is written when a process inside a container is ready to run.

  • The parallelDbConnections parameter has been moved from the [REST] to the [JDBC] section of the INI file. This parameter allows you to define maximal number of parallel connections to the database so requests can be processed at the same time. Please note that this parameters must be set per server process.

  • The default value of the docu= parameter in the [REST] section has been changed to 1 (enabled). This means that, as of this version, the endpoint to request the AE REST API OpenAPI (Swagger) documentation is enabled by default.

For more information, see Automation Engine INI file.

TLS/SSL Agents INI Files

  • Since the TLS/SSL Agents establish a connection to the new JCP, the connection parameter in the [TCP/IP] section of the TLS/SSL Agents has been changed from cp= to connection=.

  • The [AUTHORIZATION] section now includes the trustedCertFolder = and agentSecurityFolder = which allow you to define where the Agent should store certificate and security related files.

    Note: The UNIX Agent also includes the SSLCertDir= and SSL CertFile= parameters required to define the location of trusted CA certificates.

  • The new [JCPLIST] section is a self maintained section that displays all TLS/SSL enabled connections available to the Agent.

For more information, see Agents INI Files.

TLS Gateway INI File

The TLS Gateway is an Agent object and, as such, has its own INI file. This INI file is new in the system and allows you to define all relevant parameters for the TLS Gateway. For more information, see TLS Gateway INI file.

DB Service Agent

The DB Service Agent uses its own INI file. It has the same structure as the INI file of the SQL Agent, including the configuration for TLS/SSL.

The DB Service Agent uses its own SQL INI file. Since Variable objects with SQLI source access the AE database directly through the Automation Engine, they do not require an Agent.

More information:

Proxy Client INI File

Since the Proxy now uses TLS/SSL connections, the following changes have been made in the INI file of the Proxy Client:

  • The complete [SSL] section, including the keyStore and keyStorePwd parameters has been removed from the INI file.

    You can use the trustedCertFolder=, agentSecurityFolder=, and keyPassword= parameters in the INI file of the Proxy Client to point to the relevant certificates. If the trustedCertFolder= parameter is not set, the certificates should be installed in the Java trust store.

  • In the [GLOBAL] section, the cpSelection and cpName parameters have been removed.

  • The [CP_LIST] section has been replaced with the [JCPLIST] section. The JCP selection is defined here.

More information:

New Server Roles for the Java Work Process

As of this version, you can define server roles for Java work process (JWP) and rank the role so that it processes a specific queue or assignment, which allows to distribute the load among JWPs.

The following JWP server roles are available:

  • AUT for authentication

  • PER for periodic tasks

  • UTL for Utilities

  • IDX for indexing

    Lucene indexing is done by the JWP with the role IDX.

You can define the number of processes that you want to assign to a role and rank them using the new JWP Roles page in the Automation Engine Management section of the Administration perspective. This page is only available in Client 0.

You can also see if a JWP has a role defined for it on the Processes and Utilization page in the Administration perspective. They are listed in the Role column separated by a comma, if the JWP hast more than one role assigned.

More information:

Availability Check for JCP and JWP

To increase reliability and transparency of the Automation Engine, the system now internally checks if the minimum number of java-based processes (JCP, JWP, REST) required to log into the system or to perform operations in AWI is available. If not, the login is refused and a notification is displayed.

If the java-based processes are not available during AWI operations, the user gets a notification. To log off, stop further user activities and inform your administrator.

User Passwords Storage

The user passwords are now stored as hashes using the Argon2 algorithm.

Existing passwords are migrated automatically but the password generation (last used passwords counter) is re-initialized and starts with 1.

Passwords that were used before the migration are not taken into account when changing the password and are accepted as a new password.

LDAP Service Availability for Login

In previous versions, the last valid LDAP password was saved in the AE DB to enable a login even if the service was not available at the time. The user passwords saved were also used for the synchronization available in the User object. This behavior is seen as a security issue and is therefore no longer supported.

Now, the LDAP service must be available for the login. Also, to use the Synchronize button in the User object for manual synchronization, a Login object must be assigned. If the LDAP service is not available, the access is denied. For more information, see UC_LDAP_EXAMPLE - LDAP Connection Variable.

Separation of Privileges for UNIX Agents

The UNIX Agents no longer have a separation of privileges. Only one process is responsible for all Agent functions.

Extension of the Automation Engine REST API

The following enhancements have been implemented for the Automation Engine REST API:

  • OpenAPI: As of this version, the API reference is written in OpenAPI (Swagger).

  • REST API Authentication: Password obfuscation using UCYBCRYP.EXE is supported for inbound REST API authentication, see Obfuscating Passwords.

  • Endpoint extension: A number of endpoints have been added to the AE REST API cover different functions.

  • Object execution: As of this version you can use the AE REST API to execute objects at Activation time.

More information:

z/OS Event Monitor

The z/OS Event Monitor has been enhanced and now allows you to use extended filter criteria. For more information, see z/OS and Automatic FILE Events.

UC_VAULT_CYBERARK - Password Vault Configuration

Passwords are typically stored in the database but they can also come from a password vault. This static Variable (VARA) object allows you to configure your password vault. It has been enhanced so that you can now select from three options to configure the vault depending on whether your user name is unique or not in each safe.

If the user name is unique, you can configure your vault with a safe. The UC_VAULT_CYBERARK variable must include the VLT_SAFE<nr> key for each safe that should be configurable in the Login object. If the user name is not unique, you can now configure the vault with the object name (and safe), and use the object name (account name) as an identifier. Cyberark requires this object name to be unique within a safe. The third option is to configure your password vault with the address and the safe name. You can use the address as part of the Cyberark query. The user name is always part of the query. For details, see UC_VAULT_CYBERARK - Password Vault Configuration