This document covers the following topics:
The EntireX Adapter uses adapter services to send synchronous or asynchronous requests to various back-end systems. Access to these systems can be secured in the following ways:
Provide security credentials in the adapter connection for
security-protected back-end systems
If access to a back-end system is security protected, security
credentials (user ID and password) have to be provided in the corresponding
adapter connection. This can be done when the connection is configured or
edited, see EntireX Adapter Connections. This security support is optional and not
available for all connection types, see the overview of available connection
parameters in Editing Adapter Connections.
The credentials can also be provided dynamically when calling the adapter service, see EntireX Adapter Services.
Set access control permissions for the adapter service
Using the Designer you can set access control
permissions to restrict the right to execute an adapter service to a particular user group of the Integration Server:
To set access control permissions using the Designer
Choose Service Development > Package Navigator > Permissions.
Set Enforce Execute ACL to When top-level service only to select the group that is specified on the top-level service. This way, access control is already checked when executing the top-level service.
Or:
Set Enforce Execute ACL to Always and select a user group in Execute ACL.
Adapter listeners receive synchronous or asynchronous requests from external RPC clients. If the RPC request is sent to the EntireX Adapter using a broker that is configured to use security, the credentials of the RPC clients are checked to see if the client is permitted to call the adapter listener.
By enabling the listener property Execute Service with Client Credentials, an adapter listener can be configured to use the credentials (user ID and password) provided by the RPC client to execute the Integration Server service:
Then the RPC client has to provide credentials (RPC user ID and RPC password) which are used to execute the Integration Server service.
Communication between the Adapter and the back-end systems is done using TCP/IP or, for secure communication, SSL/TLS. The configuration of SSL depends on the connection type:
| Connection Type | Description | Notes |
|---|---|---|
| Connection types using the EntireX Broker | Use the URL-style syntax by which Broker IDs are defined to
select SSL as transport method and to define the SSL parameters. For example:
ssl://host:1958?definition_of_sslparameters.
The syntax for defining SSL parameters is described in the notes below.
|
1,2,3,4,5 |
| IMS Connect, CICS IPIC, CICS ECI and CICS Socket Listener | Specify the SSL port in the Port property and the SSL parameters in the SSL Parameters property as described in Editing a Connection. The syntax for defining SSL parameters is described in the notes below. | 1,3 |
| Direct RPC | Specify the SSL port and SSL parameters in the configuration wizard for Direct RPC. | 1,5 |
To operate with SSL, certificates need to be provided and maintained. Depending on the platform, Software AG provides sample certificates, but we strongly recommend that you create your own. See SSL/TLS Sample Certificates Delivered with EntireX in the EntireX Security documentation.
Specify Broker ID and SSL parameters.
SSL transport will be chosen if the Broker ID starts with the string ssl://. Example of a typical URL-style Broker ID:
ssl://host:1958?definition_of_sslparameters
If no port number is specified, port 1958 is used as default.
If the SSL client checks the validity of the SSL server only, this is known as one-way SSL. Two SSL parameters must be specified on the SSL client side: trust_store and trust_passwd. The mandatory trust_store parameter specifies the file name of a PKCS#12 certificate store that must contain the certificate chain of the trusted certificate
authority (CA) that issued the SSL server's certificate.
To unlock this certificate store, the password has to be set with SSL parameter trust_passwd.
By default a check is made that the certificate of the SSL server is issued for the hostname specified in the Broker ID.
The common name of the subject entry in the server's certificate is checked against the hostname. If they do not match, the
connection will be refused.
You can disable this check with SSL parameter verify_server=no.
If the SSL server additionally checks the identity of the SSL client, this is known as two-way SSL. In this case the SSL server requests a client certificate
(the parameter verify_client=yes is defined in the configuration of the SSL server).
Two additional SSL parameters must be specified on the SSL client side: key_store and key_passwd.
This keystore must contain the private key of the SSL client. The password that protects the private key is specified with
key_passwd.
The ampersand (&) character cannot appear in the password.
SSL parameters are separated by ampersand (&). See also SSL/TLS Parameters for SSL Clients.
Example of one-way SSL:
ssl://host:1958?trust_store=/temp/ExxCACert.p12&trust_passwd=ExxCACert&verify_server=no
Example of two-way SSL:
ssl://host:1958?trust_store=/temp/ExxCACert.p12&trust_passwd=ExxCACert&key_store=/temp/ExxJavaAppCert.p12&key_passwd=ExxJavaAppCert
Make sure the SSL server to which the EntireX Adapter (service or listener) connects is prepared for SSL connections as well. The SSL server can be EntireX Broker or Broker SSL Agent. See:
For information on how to configure other EntireX components using SSL/TLS, see Using SSL/TLS with EntireX Components.
| Service | Parameter | I/O | Description |
|---|---|---|---|
|
userId | I | The RACF User ID used to generate the PassTicket. |
| applicationName | I | Application name used to generate the PassTicket. | |
| securedSignonKey | I | Secured signon key used to generate the PassTicket. | |
| passTicket | O | The generated PassTicket. |