NIO HTTPS Egress Connector
Version: 17.01
Supported Since: 17.01
What is NIO HTTPS Egress Connector?
This is simply the secure version of NIO HTTP Egress Connector. That is, this egress connector use encrypted HTTP connections to send messages to other endpoints which are accepting HTTPS connections. In order to achieve that, this connector can be configured to use SSL (Secure Socket Layer) security and TLS (Transport Layer Security).
In addition to the normal configurations required to be done in the NIO HTTP Egress Connector this connector require several other important configurations to be done. For example, since this connector is sending messages to other end points, we have to configure a trust store to tell that these are the certificates of the endpoints which are to be trusted when communicating. All those configurations required are described in the sections below.
Simple Use Case
For a NIO HTTPS Egress Connector to operate there must be an ingress connector which is delivering the messages required to be sent to other endpoints. Therefore, we will use the NIO HTTPS Ingress Connector for our simple integration flow.
Prerequisites
| Since this will be an extension to the use case provided in the NIO HTTPS Ingress Connector’s use case, having an idea about that would be very helpful to continue reading this document. |
A Simple Proxy
The integration flow shown in the figure below is an example for our ESB working as a proxy. The NIO HTTPS Ingress Connector
will be receiving messages from multiple clients. Then the ingress connector will submit the messages directly to the
NIO HTTPS Egress Connector for them to be sent to a specific endpoint. The payload of the message will be logged by the
Logger processing element in the middle. Finally, the response received by the egress connector
will be sent as the response to the original client through the ingress connector’s input after the received payload
being logged by the Logger in the response flow.
Figure 1. Integration flow
Configurations
Since we have discussed how to configure the NIO HTTPS Ingress Connector, we will look at how the NIO HTTPS Egress Connector is configured. Following figure show the basic configuration of the egress connector.
Figure 2. Egress Connector’s basic configuration
As shown, we have to set the destination host name, destination port and the destination service path. Then we have to
do the SSL Configuration. We have used an external endpoint, api.myjson.com:443/bins/54nmo
which will return the JSON string,
{"status":"success"}as the response. Therefore our port is 443, destination host is api.myjson.com and the service path is /bins/54nmo.
Figure 3. Egress Connector’s SSL configuration
As shown in the above figure we set the identity key store location, where the egress connector’s identity key-pair will
be stored. Then we have to set the trust store location where the egress connector’s trusted certificates are stored. Also we
have to specify the passwords of the key store and trust store. Also you can do advanced configurations on this egress connector
like specifying the TLS version to be used, cipher suites to be enabled and the hostname verifier to be used which are described
under Parameters in this document.
Logger Configuration
Configuring the Logger processing element can be done as shown in the following figure. Both logger elements in the
integration flow are configured in the same manner to log the payloads of the messages.
Figure 4. Logger configuration
You can refer the Logger documentation for more details.
Proxy in action
In order to check whether our integration flow is working as expected, we can run a UltraESB Server from the IDE and then
use the HTTP Client in Ultra Studio Toolbox to send a request to out testing URL, https://localhost:8443/test/path. Following figures
show the expected results.
Figure 5. HTTP/S client’s response
The complete response received is,
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Date: Thu, 08 Dec 2016 01:50:11 GMT
Content-Type: application/json
Server: UltraESB 17.01
Content-Length: 20
Connection: close
{"status":"success"}You can also see the payloads of the messages being logged in the terminal. Here the request’s payload is not blank since we we sending a GET request with not content.
Figure 6. Payloads logged by the processing elements
And that’s a very simple use of this egress connector. Following sections describe the advanced configurations available in the NIO HTTPS Egress Connector along with the ports available in the Ultra Studio when you drag and drop this connector to the integration flow.
Side Ports
Connector Operation |
This port is used to connect operational elements to the Egress Connector. By-default, user does not have to connect any operational element and the default connector operation will be used. |
Out Ports
On Exception |
The message will be sent to this outport if the processing element failed to transform the payload due to some reason |
Response Processor |
The response message received will be directed to this port. You can use this port to connect any precessing element or connector that is supposed to process/consume the response. |
Parameters
* marked are the mandatory parameters
| Parameter | Category | Description |
|---|---|---|
Destination Host* |
Basic |
The hostname of the endpoint to which this connector is supposed to send messages. |
Destination Port* |
Basic |
The port in the endpoint given by |
Service Path* |
Basic |
The service path to which this connector will be sending the messages to. |
This egress connector will be sending the messages to the URL, "Destination Host":"Port"/"Service Path".
|
Identity Store Location* |
SSL Configuration |
Path to the identity key store where the key-pair used for this egress connector’s identity is located. |
Identity Store Password* |
SSL Configuration |
Password of the identity key store located at |
Identity Key Password* |
SSL Configuration |
Password used to protect the private key of the identity key-pair. |
Trust Store Location* |
SSL Configuration |
Path to the key store where this egress connector’s trusted certificates are located at |
Trust Store Password* |
SSL Configuration |
Password used to protect the trust store located at |
Hostname Verifier* |
SSL Configuration |
Mechanism used for checking if a hostname matches the names stored inside the
server’s X.509 certificate. Available mechanisms are, 1. Default - The hostname must match either the first CN, or any of the subject-alts. A wildcard can occur in the CN,
and in any of the subject-alts. |
Prevent Remote Certificate Verification |
SSL Configuration |
Indicates whether not validate remote endpoint certificates. This parameter should be turned to |
SSL Protocol Version |
SSL Configuration |
Specify which protocol version to be used for HTTPS connections. This parameter defaults to TLS. Available values are, 1. TLS You can chose the TLS version depending on the level of security your ingress connector is expected to have when transporting data. |
Supported TLS Versions |
SSL Configuration |
The set of TLS versions to be enabled for this ingress connector. |
Supported Cipher Suits |
SSL Configuration |
The set of cipher suites to be enabled should be given here. This is an advanced SSL configuration where only the specified set of cipher suits will be used to encrypt connections between the egress connector and the remote endpoints. |
| The Failover Configuration and the Advanced Configuration of this connector are same as the corresponding configurations of the NIO HTTPS Egress Connector. You can read more about it from here |
In this topic
In this topic