2 Performing a Secure ECE Installation

This chapter provides instructions for installing a secure Oracle Communications Billing and Revenue Management (BRM) Elastic Charging Engine (ECE) system and covers security-related deployment issues for each installed component of ECE.

ECE should be deployed into a secured environment; for example,

  • ECE is deployed in a closed networked environment in which any public access to the network is denied.

  • All ECE hosts are ideally connected to a single switch or in a parallel switch configuration.

  • No external processes are run on the hosts running ECE and its constituents.

  • Access to the ECE infrastructure is restricted.

ECE security can be further hardened by following the instructions in this chapter.

See BRM Elastic Charging Engine Installation Guide for information about installing ECE.

Performing a Secure ECE Installation

By default, ECE is installed in a secure mode. ECE uses security measures such as cluster security and host authorization.

When you install ECE, you are prompted to select your preferred security configuration, such as whether to enable secure socket layer (SSL). Based on the security configuration you select, ECE sets parameters in the relevant Oracle Coherence and ECE configuration files for enabling the following security levels:

  • JMX security. Clients require a JMX user name and password to connect to ECE JMX Management servers. For example, Elastic Charging Controller (ECC) can use a JMX user name and password to be authenticated to log in to the cluster.

  • Authorized host list. A process that joins the Coherence cluster has access to ECE services only if it is running on a host defined in the authorized hosts list.

  • Coherence node authentication. ECE nodes are required to authenticate themselves when trying to join the Coherence cluster. The node credentials are stored in a key store file that must be deployed on the ECE nodes.

  • SSL encryption (intra-cluster communication). Communication across ECE nodes in the Coherence cluster is encrypted.

  • BRM SSL security authentication. Communication between ECE and BRM through BRM Gateway is encrypted.

  • PDC SSL security authentication. Communication between ECE and Pricing Design Center (PDC) is encrypted.

  • EM Gateway SSL security authentication. Communication between BRM and ECE through External Manager (EM) Gateway is encrypted.

About Cluster Security

ECE uses a file based credentials store or a keystore to keep node credentials that are required to join the cluster and that are used for enabling encryption of cluster communication. The keystore is in the ECE_Home/oceceserver/config/server.jks file. Though the ECE installer creates a server.jks file, you can create your own as well if required. If you create a JKS file of your own, make sure it has very limited permissions so that unauthorized access is not allowed. ECE creates another keystore file, keystore.jks, under the ECE_Home/oceceserver/config directory which stores symmetric keys to encrypt passwords required to connect to boundary systems such as Oracle Communications Billing and Revenue Management (BRM) and Oracle Communications Pricing Design Center (PDC).

ECE bundles a jmxremote.password password file in the ECE_Home/oceceserver/config directory. The jmxremote.password file contains the boundary system password which is used to read the keystore.jks. Reading the keystore.jks is required for extracting a symmetric key that enables encryption and decryption of passwords for JMS notification services. See the discussion about managing external application passwords in BRM Elastic Charging Engine System Administrator's Guide for information about ECE clients that use the jmxremote.password file for decrypting passwords.

When you install ECE, you enter the following information:

  • The account alias for Coherence cluster security

  • The key password for Coherence cluster security (the password for the alias)

  • The key password for the boundary system alias

  • The password for accessing the keystore (the certificate store password)

  • DName details

    The DName value specifies the authorization of users for what they can do regarding cluster security.

    The DName is used for authorization as defined in ECE_Home/oceceserver/config/permissions.xml.

See BRM Elastic Charging Engine Installation Guide for more information.

About the Keystore Files and SSL Considerations

ECE maintains the following keystore files:

  • server.jks

    This file stores credentials for cluster node authentication details. It is also used for encrypting intra-cluster communication over SSL.

  • keystore.jks

    This file stores symmetric keys for boundary system password encryption.

Key and store passwords for SSL are stored by default in the ECE_Home/oceceserver/config/charging-coherence-override-secure-prod.xml file. These can, however, be overridden by defining their respective system properties in the ECE_Home/oceceserver/config/defaultTuningProfile.properties file.

Important:

Oracle strongly recommends not overriding the default ECE_Home/oceceserver/config/charging-coherence-override-secure-prod.xml file.

Installation Settings when SSL Is Enabled

When you select the SSL options during installation, the following settings are set:

  • In ECE_Home/oceceserver/config/ece.properties:

    • tangosol.coherence.override=charging-cache-config-secure-prod.xml

    • the WKA list in the charging-cache-config-secure-prod.xml file

      This should contain the WKA host list provided during the installation.

  • In ECE_Home/oceceserver/config/charging-coherence-override-secure-prod.xml:

    • -Dtangosol.coherence.ssl.keypassword=keypassword

    • -Dtangosol.coherence.ssl.storepassword=storepassword

    where keypassword and storepassword are the key and store passwords given during the installation.

About Trusted Host Information

ECE caches contain your subscribers' data. To restrict access to this data, you must specify the machines or processes that you trust and allow to be part of the cluster.

Obtain the IP addresses or host names of all machines or processes that are allowed to access the cluster. Trusted hosts include all of the server machines across which the Coherence cluster is deployed and any other machine that is to be part of the cluster. Include the server machine that runs the Elastic Charging Controller (ECC), and if you use Oracle Enterprise Manager, include the JMX client host running it.

See BRM Elastic Charging Engine Installation Guide for more information.

About JMX Security

JMX can be secured by setting the following system parameters:

  • In ECE_Home/oceceserver/config/ece.properties:

    com.sun.management.jmxremote.authenticate=true

  • In ECE_Home/oceceserver/config/defaultTuningProfile.properties:

    -Dcom.sun.management.jmxremote.password.file=../config/jmxremote.password

The file permission of jmxremote.password must be set to 400; otherwise, Elastic Charging Server nodes will not start up.

JMX security is based on Java's standard guidelines as documented at:

http://docs.oracle.com/javase/1.5.0/docs/guide/management/agent.html

ECE bundles a jmxremote.password password file in the ECE_Home/oceceserver/config directory and contains two default accounts for JMX credentials as defined in JRE_HOME/lib/management/jmxremote.password.template:

  • monitorRole with read-only permissions

  • controlRole with read and write permissions

Passwords for these two accounts can be set in the jmxremote.password file bundled in ECE_Home/oceceserver/config. If more accounts are to be added, then those accounts should be added in the jmxremote.password file as well. Refer to the following document for information about setting up authorizations for the new accounts:

http://docs.oracle.com/javase/1.5.0/docs/guide/management/agent.html

As the JMX passwords are human readable in the jmxremote.password, the file permission must be set to 400.

Note:

The jmxremote.password file is used for more than JMX. This file is also used for storing passwords required to authenticate cluster nodes and required to encrypt and decrypt passwords for JMS notification services. See the discussion about managing external application passwords in BRM Elastic Charging Engine System Administrator's Guide for more information.

All of the Elastic Charging Controller (ECC) shell commands are JMX aware: if JMX is made secure, you must provide a user name and password with the command that starts ECE services.

If JMX is secured, commands like start server or starting a single node, such as start ecs1, start pricingLoader, start configLoader, and so on must provide a user name and password. For example:

start server username=controlRole password=password_as_defined

In secured mode, it is recommended to use the ECC shell in an interactive mode (all commands are run within the shell and not as arguments to the ECC script). The ECC command sets the file permissions of the file that saves the history of the commands executed to 600. This protects unauthorized access to old commands to retrieve passwords typed in the command line.

In applications such as JConsole, jVisualVM, or other JMX client applications, the user name and password must be specified in their respective consoles when a connection is made.

Post-Installation Security Tasks

For the most part, the Oracle Universal Installer requests you to enter security information that takes care of post-installation steps typically required for security.

After installation, verify the following in the ECE_Home/oceceserver/config/permissions.xml file:

  • The principal section has the same DName information as was defined during the installation process for creating the server.jks file.

  • A complete access to all resources is allowed for an authenticated user.

  • If the secure.access.name system property is set, the tangosol.coherence.security system property must be set to true. If the tangosol.coherence.secuity system property is set to false, the secure.access.name system property should not be set.