Configure administrative access and specify settings for your appliance collectives to configure secure authentication and authorization to the data grid.
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.
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.
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.
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
keytool -delete -alias “ibm websphere datapower xc10” -keystore trust.jks -storetype JKS -keypass xc10pass
keytool -export -alias ogsample -keystore key.jks -file temp.key -storepass ogpass
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.keytool -storepasswd -new newpass -keystore trust.jks -storepass xc10pass
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.
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.
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.
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.
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.