Configuring secure access to the data grid

Configure administrative access and specify settings for your appliance collectives to configure secure authentication and authorization to the data grid.

About this task

For optimal protection against security threats complete the following steps to help prevent external threats and unauthorized data access by employees and contractors who might have access to network segments where appliances communicate between clients and servers.
Attention: In the administrative console, when you specify collective settings for server-to-server communication and protection of data on the network, you can configure settings that control security. When you change these settings, you must restart the entire collective. To specify these settings, click Collective > Settings. For efficiency, make all the changes at one time, and then submit them, so that you restart the collective only once.

Procedure

  1. Secure administrative access.

    Configure the appliance with the administrative user ID, xcadmin, and the default administrative password, xcadmin. This user ID and password grant full access to all of the administrative functions and data of the device and collective. You must configure a root administrative password that is difficult to guess. To complete this action, in the web console, click Collective > Users. Select the Administrator user, and edit the password.

  2. Configure SSL transport security.

    The appliance comes configured with a default keystore and truststore. The default truststore includes the signer certificate from the default keystore. Because this certificate is included with every appliance, it must be replaced for the SSL configuration to be secure. Replacing the certificate takes several steps.

    1. Create a new certificate and private key. This certificate can either be self signed, or preferably it can be issued by a local certificate authority.
    2. Create or modify the truststore. One method is to download the default truststore from the appliance to remove the signer certificate from that truststore labeled IBM WebSphere DataPower XC10, and then add a certificate to establish trust with the new keystore. If the new keystore has a self-signed certificate, then that certificate must be imported into the truststore. If the new keystore has a certificate issued by a local certificate authority, then the root certificate of that authority must be added to the truststore.
    3. Upload the new keystore and truststore.
    4. Change the certificate alias setting to match the name of the certificate in the keystore. The truststore files for all data grid clients must also be updated to establish trust with the appliance certificate.

      Manage the keystore and truststore using the keytool command that is included with the Java Runtime Environment (JRE). You can use other key management tools as well. See the following administrative tasks that you complete to manage keystore and truststore files.

      • Generate a self-signed certificate.
        keytool -genkey -alias ogsample -keystore key.jks -storetype JKS -keyalg rsa -dname "CN=ogsample, OU=OGSample, O=acme, L=Your City, S=Your State, C=Your Country" -storepass ogpass -keypass ogpass -validity 3650
      • Take the default signer certificate of the appliance out of the truststore that you download from the appliance.
        keytool -delete -alias “ibm websphere datapower xc10” -keystore trust.jks -storetype JKS -keypass xc10pass
      • Export the new certificate from the keystore.
        keytool -export -alias ogsample -keystore key.jks -file temp.key -storepass ogpass
      • Import the certificate into the truststore.
        keytool -import -noprompt -alias ogsamplepublic -keystore trust.jks -file temp.key -storepass xc10pass
        The import step must be done to configure the truststore to trust a certificate exported from a keystore. It is used in several contexts. The client truststore must be updated to trust the certificate from the appliance keystore, and for some configurations, the appliance truststore must be updated to trust the certificate from the client keystore. Ideally, certificates for both the client keystore and appliance keystore will be issued by a local certificate authority, in which case trust is established by importing the root signer certificate of that certificate authority.
      • Change the password on the keystore and truststore.
        keytool -storepasswd -new newpass -keystore trust.jks -storepass xc10pass
      • Upload the new keystore and truststore to the appliance collective.
    5. Specify an SSL mode from the following options: TCP/IP, where SSL is not used for data grid communication, TLS Supported, and TLS Required.
      TLS Required is recommended for security. When TLS is not used, passwords and sensitive grid data pass unencrypted over the network links connecting the grid clients and the appliance.
      Note: When TLS communication is required, the appliance truststore must be configured to trust the certificate in the client keystore, and the client truststore must be configured to trust the certificate in the server keystore. See Configuring client security.
    6. Enable Federal Information Processing Standard (FIPS).

      You can configure the appliance collective to use FIPS 140-2 for all encrypted network communication. This standard ensures high protection of data as it is sent over the wire. Select Enable FIPS 140-2 Cryptography to enable FIPS.

      Some web browser versions do not work with a FIPS-enabled server. Current versions of most browsers, including Mozilla Firefox, Microsoft Internet Explorer, and Google Chrome, do support communication with FIPS-enabled servers. You might need to configure the browser to enable TLS, because SSLv3 is not supported in FIPS mode. For more information, see the documentation for your browser.

    7. Enable client certificate authentication.

      When this is enabled, the keystore for each client and browser that communicate with the appliance must be configured to have a certificate that is trusted by the appliance truststore. Client certificate authentication is not used for ORB transport. It is used only for HTTPS and XIO transport. It is not necessary to enable client certificate authentication to have a secure configuration.

  3. Configure server-to-server authentication.

    Data grid communication between appliances in a collective and between linked appliance domains, is authenticated using a shared secret key. The appliance is already configured with a default secret key this is hard-coded into each appliance. You must change the secret key to have a secure configuration. Select Override factory default authentication secret key to specify a unique secret key.

    The secret key must be a long passphrase that is difficult to guess. Record the secret key, and store it in a secure location. When collectives are joined in linked domains, each collective must be configured with the same secret key.

  4. Require authentication for all data grid requests.

    You can configure authentication for each client request to the data grid. By default, this authentication is not required. However, you can provide protection for data grid access by securing individual grids, and for a secure configuration, require authentication for all grid requests. When this is set, each client must be configured with a user ID and password that are recognized by appliance collective, or in the case of LDAP authentication, the user iD and password must be registered in LDAP. Only the root administrator (the xcadmin user ID) can log in without LDAP authentication.

    After you complete steps 2-4, submit the changes to restart the collective. These settings are automatically propagated to appliance that are to be assimilated into the collective. If you enabled FIPS, the FIPS is enabled on each appliance before it is assimilated into the collective.

  5. Disable Telnet access.

    The default configuration for the appliance includes an active Telnet server. Telnet communication in the appliance does not support SSL. For a secure configuration, disable the telnet server. To disable telnet, establish an SSH session to the appliance using the administrator user ID and password, and issue the command, platform service telnet disable. This is not a collective wide setting, which means that you must run this command for each appliance. The command, platform service telnet disable, starts Telnet if it has been disabled. This procedure is a manual and cannot be automated.

  6. Configure LDAP authentication.
    Authentication for browser, REST, and data grid access to the appliance is done in one of two ways. You can store the authenticated identities in the appliance collective or in LDAP. You can use either method in a secure configuration.
    Tip: Authentication of the root administrator always uses a password that is verified by the collective and not by LDAP.
    When LDAP authentication is used, protect the LDAP connection with SSL so that passwords do not pass over the network unencrypted. To enable SSL for an LDAP connection, specify an LDAPS URL, such as ldaps://ldapserver.company.com:636. Now, you must configure the appliance truststore with a certificate to establish trust with the LDAP server for SSL communication. For more information about configuring LDAP authentication, see Configuring your appliance to authenticate users with an LDAP directory.