|Maintenance Notice - PDF Generation|
|Dynamic PDF generation for web-based content is temporarily unavailable. This maintenance affects dynamic PDF files that are generated from either the HTML-based page or manual that you are viewing. Links that normally allow this functionality have been hidden, and will reappear as soon as the feature is restored.
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:
- Oracle: Oracle Database Advanced Security Administrator's Guide
- Microsoft SQL Server: Use the documentation that came with your database application.
- PostgreSQL: Use the documentation that came with your database application.
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:
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.
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
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.
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.
You must meet the following conditions to create a secure connection to Configuration Server:
- Create a an Auto Detect listening port for your Configuration Server with a certificate configured.
- 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.
- Create a Secured port for Message Server and Solution Control Server.
- 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.
- 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:
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:
- (Windows) setenv.bat:
set JAVA_OPTS=%JAVA_OPTS% -Dgax.configserver.validate.cert=off
- 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.
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
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.
Follow these recommendations to configure the HttpOnly and Secure flags.
Open and edit the following file: $CATALINA_HOME/conf/context.xml
To set the HttpOnly flag, add the following attribute:
The main tag should be:
Instead of: <Context>
Open and edit the following file: $CATALINA_HOME/conf/server.xml
To set the Secure flag, add the following attribute to the HTTPS connector:
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" />
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.