# Encryption in IDOL

IDOL Server uses encryption in various operations. This article describes some of the methods it uses.

NOTE: In IDOL Server, the document Access Control Lists (ACLs) are obfuscated to disguise the data values, rather than encrypted.

## Transport Layer Security

You can configure the IDOL Server ACI, Service, and Index ports to use Transport Layer Security/Secure Sockets Layer (TLS/SSL). You can configure this by setting the `SSLConfig` parameter. This parameter is available in various configuration sections, to set SSL settings for the different ports. You set the `SSLConfig` parameter to a configuration section that contains the SSL settings that you want to use for that port or communication type. For more information, refer to the IDOL Server Administration Guide.

This configuration allows you to use HTTPS, rather than plain HTTP for communication between IDOL components. Certificates allow you to lock down this communication to trusted sources and destinations.

The `SSLConfig` configuration mechanism is also used to configure outgoing connections to secured components, for example in the configuration of an SSL-enabled child server in a DAH configuration.

## Application Level Encryption

IDOL can use a number of application level security methods.

GSSAPI Encryption

IDOL Server can use the Generic Security Services Application Program Interface (GSSAPI) to establish a security context between components and then encrypt messages that pass between those components. This method is available only for the ACI port. The components establish the context with an action. Further messages are encrypted by the API, and wrapped inside ACI encryption.

GSSAPI encryption requires the use of a client connection that supports persistent connections, because the context object is associated with a particular connection.

You configure GSSAPI encryption by using the `CommsEncryptionType` configuration parameter. For more information, refer to the IDOL Server Reference. The IDOL SDKs provide methods for using GSSAPI encryption with your applications.

TIP: You can also configure GSS authentication on the ACI, service, and index ports without using ACI encryption. In this case, you can use GSS authentication with standard HTTP/HTTPS libraries for encryption.

To use this option, you set the `GSSServiceName` configuration parameter for your service, and you set the `RequireGSSAuth` configuration parameter in the `[Server]`, `[Service]`, and `[IndexServer]` sections, as required.

AES Encryption

AES encryption uses the Advanced Encryption Standard. You can use AES encryption to encrypt `SecurityInfo` strings. To enable AES encryption, you can set the `SecurityInfoKeys` configuration parameter to the name of the AES key file. IDOL Server then uses this key file to encrypt and decrypt the strings.

ACI and OEM Encryption

ACI encryption is a generic mechanism for encrypting the contents of ACI communication. The `Encrypted` action allows you to send an encrypted action in the `Data` parameter, and responses include `<autn:encrypteddata>` tags with the encrypted responses. ACI encryption is always optional for components communicating on the same host.

You can configure ACI encryption if you are using GSSAPI. Older IDOL systems can also use AES or BTEA ACI encryption, but these methods are deprecated. In general, Micro Focus recommends that you use Transport Layer Security, rather than ACI encryption.

OEM encryption is enforced ACI encryption. The request must always be ACI encrypted, but the response is always sent unencrypted. All components must share the OEM encryption key.

An IDOL component running with OEM license keys (without a License Server component) is enforced by the license to use ACI encryption. You do not need to configure ACI encryption when you are using an OEM license, and any ACI encryption configuration is overridden by the OEM licensing. The IDOL SDKs provide methods to work with the OEM communication key provided with the license key.

NOTE: You can also operate ACI servers with an Enterprise OEM license. The Enterprise OEM license uses License Server to provide a standard license, and also includes an embedded OEM encryption key that allows optional ACI request encryption, without any additional configuration in your ACI components. When you use encryption for a request, it acts like OEM encryption (with an encrypted request and unencrypted response).

This option provides a way for you to migrate an OEM system to the standard licensing model without requiring you to immediately change existing applications that use OEM encryption.

SecurityInfo

The SecurityInfo string identifies the documents that a user is allowed to see, by checking user and group permissions against the document ACL for the chosen security model. You can set the `SecurityInfoKeys` configuration parameter to configure SecurityInfo strings to use either AES or BTEA encryption, by setting it to the file name of the AES key file, or a list of BTEA keys.

Micro Focus recommends that you use AES encryption, which is a more secure encryption algorithm. In this case you set `SecurityInfoKeys` to the filename and path of an AES key file. The key file must consist of exactly 64 hexadecimal characters. To prevent unauthorized access, limit access to the key file to the users that the IDOL services run under.

For older systems that use TEA encryption, you set `SecurityInfoKeys` to a comma-separated list of four signed 32-bit integers (between 0 and 2147483647). The default IDOL Server configuration file gives a default set of keys. You must always change this default value when you install IDOL Server. The BTEA keys are stored in plain text in the configuration file, so be aware of who has access to this file.

You must set `SecurityInfoKeys` to the same value for all components.

Configuration Files

Some configuration parameters accept encrypted values. You can generate encrypted values for these parameters by using the `autpassword` command-line tool.

Typically you can encrypt password parameters.

_FT_HTML5_bannerTitle.htm