Configuring the Secure Gateway

cloud-related topic

The Secure Gateway is a designated Platform Agent that enables software inside the customer network to securely communicate with the server-based components of RunMyJobs. The Secure Gateway runs inside the customer network, behind the customer firewall, and communicates with the RunMyJobs server components via HTTPS. All traffic between the customer network and the RunMyJobs server processes passes through the Secure Agent. All communication is initiated from inside the customer network, for additional security. The Secure Gateway is only available to RunMyJobs SaaS customers.

Note: For more information about Platform Agents, see Installing Platform Agents.

This document explains how to configure a Platform Agent to be the Secure Gateway.

Secure Gateway Overview

The Secure Gateway is a function performed by a Platform Agent that has been configured to act as a proxy for communications between a managed application and a customer's RunMyJobs SaaS environment. The Secure Gateway communicates with the customer's RunMyJobs SaaS environment through a dedicated, encrypted connection, via an exchange of credentials known only within the customer-specific environment. The following graphic shows the RunMyJobs SaaS architecture when the Secure Gateway is deployed.

The Secure Gateway can facilitate communication with various customer systems, including the following.

  • SAP systems
  • Oracle EBS applications
  • IBM iSeries (AS400)
  • Web Service based solutions
  • BusinessObjects
  • PeopleSoft
  • Database connections (via JDBC)
  • SMTP (email) connections

If you need connections to other environments, contact Redwood for advice. As can be seen in the diagram, connections from other OS Platform Agents are independent from the Secure Gateway and each other. This provides flexibility and contributes to fault tolerance (see below).

The Secure Gateway connection is initiated from the Platform Agent that is configured to act as the communication proxy instance. This connection is an established HTTPS secured TCP connection. This way, no open incoming ports in the customer firewall are required to set up connections from Redwood Server to the required applications.

The general process for configuring the Secure Gateway is as follows:

  1. Decide where to host the Secure Gateway
  2. Download and Install the Platform Agent
  3. Configure Process Server(s) for Secure Gateway
  4. Restart the preferred Secure Gateway Process Server candidate
  5. Configure application connections

The following sections describe these steps in more detail.

Decide Where to Host the Secure Gateway

The Secure Gateway establishes secure communication between managed applications and customer's dedicated Redwood SaaS environments. This includes passing instructions to the managed applications on which processes are to execute, as well as passing progress and completion status data from the applications back to the Redwood Central Server. It is, therefore, important to locate any Platform Agent that is a Secure Gateway candidate on a server that is:

  1. Located inside the corporate firewall
  2. Able to communicate through the internal network with the applications to be managed
  3. Able to connect to your Redwood *.cloud environment (verify your URL after connecting to an environment)
  4. Reliable fast network (low latency)

Fault Tolerance Considerations

The Secure Gateway is designed to be highly available. At any time only one Platform Process Server acts as the Secure Gateway, but if the active Secure Gateway becomes unavailable, any other Platform Process Server that is designated as a Secure Gateway Candidate will take over the role automatically and seamlessly.

Note: Any Platform Process Server can be configured to serve as a Secure Gateway Candidate in addition to its other roles. However, for safety, Redwood recommends having at least two dedicated Secure Gateway Candidate Platform Process Servers that do NOT have other roles.

DMZ Setup

Secure Gateways in a DMZ need to be able to connect to the central Redwood server on port 443 and to all remote systems (ERP, REST/SOAP, JDBC, IBM i, SMTP...) on the configured ports. See the remote-system specific documentation for the default ports.

Download and Install the Platform Agent

Installing the Platform Agent(s) for Secure Gateway purposes is done in exactly the same way as when installing Platform Agents for general use. Detailed instructions on how to do this can be found in the 'Supported platforms' and 'Install Platform Agents' guides available in the Help section of the Redwood Cloud portal. These documents provide information on the permissions required on the local server and pre-requisites for connecting Platform Agents across the Internet to the Redwood cloud.

Note: The Secure Gateway is only supported to run on Platform Agents on Linux x86 and Windows.

Redwood recommends using Linux x86 64-bit for hosting the Secure Gateway, as a best practice. Follow the instructions in the Install Platform Agents guide to set up each Platform Agent that you wish to be a candidate Secure Gateway. Once installed each Platform Agent will be registered with a 'Process Server' in the customer specific Redwood Cloud environment. The Process Server name will be the same as the hostname on which the Platform Agent is installed to make identification easy, and it is the Process Server name that is used when referring to Secure Gateway connections in the Redwood user interface.

Configuring Process Servers for the Secure Gateway

To configure the Secure Gateway, you need at least one Platform Agent Process Server and the user must have been assigned to the Cloud Administrator role. Go to Environment > Process Servers and Edit the Process Server you want to use. Then check Secure Gateway Candidate as seen in Figure 2, save and restart the Process Server by choosing Restart from the context menu.

Figure 2: Checking the Secure Gateway Candidate field while editing a Process Server

  • At least one Process Server designated as a Secure Gateway must be restarted before any can be selected as the active Secure Gateway.
  • If there are multiple Process Servers designated as Secure Gateways, the first to be restarted will become the active Secure Gateway.
  • If only one Process Server has been designated as a Secure Gateway candidate, it will become the active Secure Gateway only after being restarted.
  • If more than one Process Server has been designated as a Secure Gateway, you only need to restart one of them to achieve fault tolerance. The other Process Servers do not need to be restarted.
  • The Cloud Administrator role is required to set this checkbox. This role can be configured per environment in the cloud portal and allows separation between product administrators and cloud administrators (same rights as normal administrators + ability to change cloud related settings). This role has already been described in the Managing Users and Roles document.

Identifying the Active Secure Gateway

At any time only one Secure Gateway candidate Process Server will be used as the active Secure Gateway. By adding the Secure Gateway Candidate and Secure Gateway columns in the Process Server overview you can see which Process Server(s) are Secure Gateway candidates and which Process Server is the active Secure Gateway. Only one Process Server can be the active Secure Gateway at a time. See Figure 3 for an example. Another way to confirm this is by looking at the 'System Information' for the relevant Process Servers as follows.

  1. Select the 'Environment' navigation bar group then select 'Process Servers'.
  2. Select the first Process Server you want to check.
  3. Expand 'System Information'.
  4. The IPForwarderURL highlighted below will only exist on the Process Server selected by the Redwood Central Server as the Secure Gateway. See the example at the bottom of Figure 3.

Figure 3: Process Server list view with Secure Gateway and candidates. Bottom shows IPForwardURL

When IP forwarding has been acknowledged as successfully configured from Secure Gateway (based in the customer environment) to the Process Server (in the Redwood Cloud) an Operator Message will confirm this, with the 'Sender Object' being the Process Server defined as the Secure Gateway:

Figure 4: Operator Message confirming successful IP forwarding

Configure Application Connections

Once the Secure Gateway has been configured you can set up connections to the various applications and environments that you will manage through it by creating the appropriate type of 'Process Server'. The methods used to connect to the different environments to be managed via the Secure Gateway are application specific and are described in other documents. Please refer to the Redwood portal Help section, follow a training or contact Redwood support for detailed instructions. In general Process Server creation happens via the Wizard when you create one from the Process Server screen:

Figure 5: New Process Server - Application selection

Redwood will automatically determine if it a direct connection can be used (Platform Agent) or if the Secure Gateway needs to be used (any other Process Server).

Secure Gateway Alerting

When the Secure Gateway connection between the proxy-processor in the central Redwood server and the current Platform Agent running as the client side of the secure websocket fails, then the server tries to start another proxy-processor. However this is only possible if we have another Secure Gateway candidate that is regarded as configured, meaning that there is a connection available.

If however the proxy-processor fails to establish a secure connection with this candidate after 4 minutes, then the proxy-processor exits and another Secure Gateway candidate is tried. If there are no further configured Secure Gateway candidates to try, then the following occurs:

  1. The System_Secure_Gateway event is raised. This is an internal event only for use by the Secure Gateway. This event is raised provided that Secure Gateway alerts are configured.
  2. An alert message is sent to a pre-configured URL informing SaaS that the Secure Gateway is down. The header and body that should be in the message are configurable.

Once the situation is resolved and the Secure Gateway connection is operational again:

  1. The System_Secure_Gateway event is cleared.
  2. An alert message is sent to a pre-configured URL informing SaaS that the Secure Gateway is up.

See Also