Jump to: navigation, search

Configuring System Security

GAX has many features that enhance your system security. This section discusses GAX security features and describes how to configure and/or use them.

Default Account Support

Genesys uses a default user account. This is a special account that always has full privileges to all objects and can perform any action. This account ensures that there is always at least one account that enables the administrator to correct permissions and access issues if other administrative accounts are deleted, disabled, or otherwise compromised.

GAX supports the default user account. The default user account always has full access to all the functions that are specified for the GAX role, even if this account does not have any role privileges or explicit permissions specified. When the default account is created during the installation of Configuration Server, it has full control over all configuration objects; however, this account might be deleted or its permissions on objects might be revoked. If this happens, GAX cannot work around the permissions. The default account must have the permissions set to write objects in the Configuration Server.

Use the default_account_dbid option to configure the actual account to be used, and that has all privileges assigned, in case the original default user account is disabled for security reasons or has been deleted.

Transport Layer Security (TLS)

GAX employs Transport Layer Security (TLS), a cryptographic protocol that provides security and data integrity for communications over networks such as the Internet. TLS encrypts the segments of network connections at the transport layer from end to end.

GAX supports TLS-enabled connections to the following Genesys servers:

  • Configuration Server
  • Solution Control Server
  • Message Server
  • Genesys Deployment Agent

GAX also supports TLS-enabled connections to the GAX database and the LRM database.

For the GAX database connection (either Oracle, Microsoft SQL Server, or PostgreSQL), the database driver and database must also support TLS. For information about configuring your GAX database, refer to the documentation that is specific to the database that you are using:

For information about TLS and detailed instructions about configuring secure connections, and creating and managing certificates, refer to the Genesys TLS Configuration chapter of the Genesys 8.1 Security Deployment Guide.

Follow the instructions to create a certificate, assign that certificate to a Host object (which is required for Genesys Server to run in TLS mode), and configure the use of a secured port for the GAX application.

Next, import the server certificate to the trust storage for GAX to enable authentication for TLS connections.

By default, trust storage is in the JRE folder at the following location: 

C:\Program Files\Java\jre6\lib\security\cacerts

The default password is "changeit".

Genesys recommends that you create a separate trust store for GAX.

Perform the procedure below to create a trust store and import the certificates.

Procedure: Creating a keystore and managing the trust store

Purpose: To create storage that is separate from the default keystores that come with Java.

Genesys recommends that you do not use the default keystores that are shipped with Java. To ensure a clean separation, you should create a separate storage. If you use a standard cacert file, you must re-import the certificates after each JVM update.

The trust store should contain only the certificates of servers that GAX should trust. If a server sends GAX its certificate during a TLS Handshake, GAX will search for a matching certificate in this keystore. If the certificate is found, the connection is accepted; otherwise, the connection is rejected.

Prerequisites

  • Your Keytool should be configured to your path.
  • You have JRE or JDK installed.

Steps

  1. To create an empty keystore, execute the following command lines on your shell: keytool -genkey -alias initKey -keystore trusted.keystore -storetype jks keytool -delete -alias initKey -keystore trusted.keystore
  2. Make the trusted.keystore file readable for the user that owns the GAX process.
  3. Set a strong password on your keystore.
  4. Add a certificate to the trust store by executing the following command line: keytool -import -alias mssql -keystore trusted.keystore -file "cert/demosrc.cer"

    Alias is a name under that the certificate. It can be addressed within the trust store. The option -keystore specifies the keystore file and the option -file specifies the certificate to be imported.

  5. To display the whole content of a keystore, execute the following command line: keytool -list -keystore trusted.keystore
  6. To display a specific certificate, execute the following command line: keytool -list -v -alias mssql -keystore trusted.keystore
  7. To delete a certificate from the keystore, execute the following command line: keytool -delete -alias mssql -keystore trusted.keystore
Important
Most systems have multiple trusted stores. You must always use the same store for GAX.

The following options must be set to configure the trust store location for GAX. The options also enable authentication on a global level for all connections that use a secured port.

The best way to set these options is by using the setenv.sh or setenv.bat script: 

set JAVA_OPTS=%JAVA_OPTS% -Djavax.net.ssl.trustStore="D:\certificates\trusted.keystore"
set JAVA_OPTS=%JAVA_OPTS% -Djavax.net.ssl.trustStorePassword=changeit
Important
GAX does not support Client Authentication. GAX will not authenticate itself by sending a certificate to the server.

Secure Socket Layer (SSL) Security

Genesys Administrator Extension supports Secure Socket Layer (SSL) communications between the GAX server and client-side connections using the web browser interface.

GAX can support connections through HTTP or HTTPS simultaneously. This is defined through configuration of the supported_protocol parameter in the gax.properties file, which can be found in the conf directory of your GAX installation.

Procedure: Setting up HTTPS for use with Genesys Administrator Extension


Steps

  1. Create a keystore file to store the private key and certificate for the GAX server.

    2. To create a self-signed certificate, execute the following command:

    keytool -keystore keystore -alias gax -genkey -keyalg RSA

    As prompted, enter the information required.

  2. Start GAX in HTTP-only mode. In the gax.properties file, ensure supported_protocol=http. This is set by default.
  3. As a local user (whether in person or via a remote desktop connection), log in to GAX as the local user root.
  4. Call the webservice API by entering the following in the address bar of your web browser (for example: http://localhost:8080/gax/api/system/setkeystorepassword?password={password}). The password is stored in an obscured fashion in the gax.properties file. The password specified should be the same as the password specified for the keystore (see Step 1, above).
  5. Define the parameter https_port in gax.properties with a port number. The usual default is 443. Please see Configuring GAX Properties for more information.
  6. Update the parameter supported_protocol in gax.properties with either https or both.
  7. Define the parameter keystore_path in gax.properties with the full path to the location of the keystore file.
  8. Restart GAX in HTTPS mode.

TLS: Preparing Genesys Management Framework

To enable GAX to connect securely to Genesys servers, you must configure the Genesys Framework as described in the Genesys 8.1 Security Deployment Guide. Follow the instructions in this guide to create and manage certificates and make them usable within Genesys Framework.

Configuration Server

You must meet the following conditions to create a secure connection to Configuration Server:

  1. Create a an Auto Detect listening port for your Configuration Server with a certificate configured.
  2. Configure the GAX Server to connect when it starts up to the Configuration Server Auto Detect port by setting the GAX Server "-port" property. In the Start Info tab of the GAX_Server Properties dialog box, enter the following settings:
    • Working Directory: /path/gax
    • Command Line: ./startup.sh
    • Command Line Arguments: -host <host name> -port <auto detect port number> -app GAX_Server

Message Server and Solution Control Server

Both Message Server and Solution Control Server are configured the same way.

  1. Create a Secured port for Message Server and Solution Control Server.
  2. Configure the GAX Server to connect to Message Server and Solution Control Server by using the specific Secured ports that you have created. In the Properties dialog box for the server and in the Connections tab of the GAX_Server dialog box, secured ports are displayed with a key symbol icon.
  3. Restart GAX Server to connect over an encrypted session by using the secure ports.

Genesys Deployment Agent

Genesys Deployment Agent (GDA) does not read its configuration from Configuration Server. The TLS for the GDA process is activated by accessing the security section of the local gda.cfg file and setting the gda-tls option to a value of 1.

The Application Options tab of the related Host might or might not have a security section that contains the gda-tls option.

The gda-tls option is not relevant for the GDA runtime; it is read during the installation of LCA and GDA only. GAX reads the value of the gda-tls option to determine in what mode GDA is running, and also to determine whether it should connect using TLS or not; therefore, these values must be kept synchronized. If the system administrator changes one of the values in the local file or in the Host Application Options tab, the other option must also be changed to enable GAX to connect correctly.

Disabling Authentication for Certain Connections

The configuring steps outlined above engage authentication for Configuration Server, Message Server, and Solution Control Server. If GAX uses the secure ports to connect to Message Server and Solution Control Server, both server-side certificates will automatically be validated against the trust storage.

In certain rare cases you might want to disable authentication for one of the connections. To do this, add the following line to the Advanced tab of the Properties dialog box for the connections: 

"disableAuthentication=1"

Do not use white spaces. To separate this option from other options, use a semi-colon.

To disable TLS authentication for Configuration Server, add the following line to the following files:

  • (Linux) setenv.sh:

JAVA_OPTS="$JAVA_OPTS -Dgax.configserver.validate.cert=off"

  • (Windows) setenv.bat:

set JAVA_OPTS=%JAVA_OPTS% -Dgax.configserver.validate.cert=off

Important
  • Connections to Message Server and Solution Control Server fail if GAX does not find the received certificate in the trust store, or if Message Server and Solution Control Server do not send a certificate.
  • Connections also fail to Configuration Server and databases if they are configured for authentication and the certificate is not in the trust store.

You must configure your Oracle, Microsoft SQL, or PostgreSQL server to use TLS. Refer to the documentation that came with your database for information on how to use TLS security.

Procedure: Configuring the GAX Database for TLS (Oracle)

Prerequisites

Steps

  1. Configure Oracle as described in the related database guides, and configure a TCPS listener.
  2. Set the level of TLS control on the DAP.
    1. In the GAX section of the DAP, create an option that is named tls_mode.
    2. Specify one of the following values for the tls_mode option:
  • off—No TLS will be used.
  • required—If a server does not support TLS, revoke the connection.
  • authentication—GAX will validate the server send-certificate with the local trust store.
  • <option not set>—Same as off.

Procedure: Configuring the GAX Database for TLS (Microsoft SQL Server)

Prerequisites

Steps

  1. Configure Microsoft SQL Server as described in the related database guides.
  2. Set the level of TLS control on the DAP.
    1. In the GAX section of the DAP, create an option that is named tls_mode.
    2. Specify one of the following values for the tls_mode option:
  • off—Do not use TLS.
  • request—If the server supports TLS, it is used.
  • required—If the server does not support TLS, the connection is revoked.
  • authentication—GAX validates the server-send certificate against the local trust store.
  • <option not set>—Same as off.
  • Verify that the configured port is identical to the TLS listener port of Microsoft SQL Server
  • Due to an incompatibility between newer versions of Java and the Microsoft SQL Server driver, disable CBC Protection to enable GAX to connect to a Microsoft SQL Server database.
    • For Windows, add the following line to the setenv.bat file:

    set JAVA_OPTS=%JAVA_OPTS% -Djsse.enableCBCProtection=false

    • For Linux, add the following line to the setenv.sh file:

    JAVA_OPTS="$JAVA_OPTS -Djsse.enableCBCProtection=false"

    Procedure: Configuring the GAX Database for TLS (PostgreSQL)

    Prerequisites

    Steps

    1. Configure PostgreSQL as described in the related database guides.
    2. Set the level of TLS control on the DAP.
      1. In the GAX section of the DAP, create an option that is named tls_mode.
      2. Specify one of the following values for the tls_mode option:
    • off—Do not use TLS.
    • required—If the server does not support TLS, the connection is revoked.
    • authentication—GAX validates the server-send certificate with the local trust store.
    • <option not set>—Same as off.

    Cross-site Scripting and Cookies

    You can configure your system to improve the protection of Genesys Administrator Extension against Cross-site Scripting (XSS) attacks by configuring the HttpOnly and Secure flags on your HTTP server to further enhance the existing GAX security. These flags tell browsers how to handle cookies.

    Server-side cookies can be tagged with HttpOnly and Secure flags to tell the browser how to deal with them. To achieve a maximum level of security, administrators must make this configuration on the Application Server.

    Securing Server-side Cookies

    HttpOnly

    Setting the HttpOnly flag on cookies forces the browser to prevent (disallow) scripts from accessing the cookies. This prevents JavaScript that might be introduced through an XSS attack into a browser page to access cookie data and send it to a different person. Stolen cookie data can also be used to hijack a browser session.

    Secure Flag

    With the Secure flag set, cookies are transmitted only from the browser to the server when the connection is secured by using the HTTPS protocol. This setting is applicable to HTTPS connections only. Therefore, you must configure GAX to use an HTTPS connector, not an HTTP connector.

    Setup

    Follow these recommendations to configure the HttpOnly and Secure flags.

    HttpOnly

    Open and edit the following file: $CATALINA_HOME/conf/context.xml

    To set the HttpOnly flag, add the following attribute: 

    useHttpOnly="true"

    The main tag should be: 

    <Context useHttpOnly="true">

    Instead of: <Context>

    Secure Flag

    Open and edit the following file: $CATALINA_HOME/conf/server.xml

    To set the Secure flag, add the following attribute to the HTTPS connector: 

    secure="true"

    The flag must not be applied to any non-HTTPS connectors. If you apply the flag to an HTTP connection, it will become unusable for Genesys Administrator Extension.

    The following is an example of a valid connector: 

    <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
keystoreFile="/home/gcti/keystore.key" keystorePass="genesys"
clientAuth="false" sslProtocol="TLS" />

    Inactivity Timeout

    For security purposes, GAX can be configured to lock the application if an administrator has not used the keyboard or mouse for a period that you specify. All user input is blocked until the administrator provides login information to unlock the application. This feature ensures that no unauthorized user can access an unattended terminal that is running GAX.

    Use the inactivity_timeout option to specify the amount of time in minutes of administrator inactivity (no mouse or keyboard usage) that triggers application locking. If the administrator has been inactive longer than the number of minutes that are specified by the inactivity_timeout option, the administrator must re-authenticate to be able to use the GAX application. A value of 0 disables this functionality.

    GAX employs a keep-alive strategy to prevent session timeout; this ensures that GAX maintains your session even if the inactivity timeout feature locks the application and requires you to log in.

    This page was last edited on July 17, 2020, at 15:55.
    Comments or questions about this documentation? Contact us for support!