Open topic with navigation
Secure communications allow IDOL components to share information with other IDOL components, and with external components. It ensures that:
third parties cannot read communications.
the communication occurs between trusted entities.
The first option for secure communications is to use authorization roles to allow access by IP address, SSL identity, or GSS principal.
You define the allowed identities of systems or users that IDOL has permission to communicate with. You can use the
[AuthorizationRoles] configuration sections to define access separately for different types of actions (for example, standard roles allow you to define authorization restrictions for administrative actions, index actions, queries, and service actions), or for specific sets of actions. You also define the IP addresses, SSL identities, and GSS principals that each authorization role applies to. A user can send a particular action if they use one of the allowed methods to access IDOL Server.
You can also bind IDOL Server components to an explicit network interface in systems with multiple interfaces, by using the
ExplicitHost configuration parameter.
Main Topic: SSL in IDOL
Transport Layer Security (TLS/SSL) provides both transport encryption (HTTPS), and endpoint authentication.
In the most basic configuration, TLS encrypts the communication channel to and from the IDOL Server component so that third parties cannot decrypt the information. In more advanced configurations, you can use client and server certificates to check that communication happens only between trusted clients and servers (with certificates signed by a trusted authority).
You configure TLS/SSL by using the
SSLConfig configuration parameter, and the associated
[SSLOptionN] configuration sections, which you can use to configure one or more sets of SSL options for your components to use.
IDOL can plug in to an existing Kerberos system, by using the Generic Security Services Application Program Interface (GSSAPI). Kerberos provides end-user identification, and you can use it with ACI encryption to provide secure channel encryption, if you prefer this method to TLS/SSL.
In general, a Kerberos system is more complicated to set up and troubleshoot than a TLS/SSL system.
For ACI port communications, you can configure Kerberos by using the
CommsEncryptionType configuration parameter. This option uses ACI encryption, and requires external access to the IDOL system through one of the ACI API libraries provided by Micro Focus, rather than using a standard HTTP/HTTPS library.
You can also configure a GSSAPI authentication requirement, without using ACI encryption. In this case, you set the
GSSServiceName configuration parameter for your service, and you set the
RequireGSSAuth configuration parameter in the
[IndexServer] sections, as required. This method provides an authentication requirement only, and you can use a standard HTTP/HTTPS library for communication encryption.
Secure communications using TLS or GSSAPI have a minor performance impact, because they need to negotiate encryption protocols and encrypt the responses. You can reduce the overhead by using persistent HTTP/HTTPS connections to reuse an established connection.