JMS security

You can enable the JMS security for an IBM® agent or service to authenticate to the JMS queues.

The JMS security for an IBM agent or service to authenticate to the JMS queues can be enabled in one of the following ways:

  • By adding the JMS security parameters in the agent criteria or agent Java™ command line.
  • By setting the JMS security parameters in the customer_overrides properties file.

Setting up JMS security using agent criteria or Java command line

The steps for an IBM agent or service to authenticate to the JMS queues are enabled by adding the following two parameters into the JMS Security properties dialogue in the agent criteria:
  • sci.queuebasedsecurity.userid
  • sci.queuebasedsecurity.password

JNDI security

Enable Java clients to authenticate to the JNDI by adding the following two parameters when creating the initial context:
  • java.naming.security.principal
  • java.naming.security.credentials

For IBM agents and services, you should add the two parameters above into the JMS Security properties dialogue in the agent criteria.

SSL channel encryption

Finally, in order to protect messages transiting through your network, you should ensure that your client programs use SSL to encrypt communications with message queues. Note that SSL can be used to protect messages that are in-flight or in-motion across the network; however, it does not protect messages in queues when they are at rest.

To initiate a one-way SSL session from an IBM agent or service to a JMS server, set the following -D options on the Java command line:
  • javax.net.ssl.trustStore
  • javax.net.ssl.trustStorePassword
  • com.ibm.SSL.ConfigURL
  • com.ibm.CORBA.ConfigURL
  • javax.net.ssl.trustStoreType
Note: SSL cannot be set up through agent criteria or customer overrides properties. SSL encryption must be implemented by using system properties. To accomplish this, set the sandbox.cfg variable AGENT_JAVA_DEFINES and then run <INSTALL>/bin/setupfiles.

When using the IBM JDK, you can add the following -D property to help you diagnose your SSL setup:

ssl.debug=true

Securing JMS queues

The implementation of JMS security is left to the discretion of the application server developers. As a result, the requirements differ from one vendor to the next. If using these vendors, note the following:
  • TIBCO — If queue security is enabled at the TIBCO server, the client must pass both queue security parameters and jndi security parameters. Also, TIBCO client configuration for SSL is specific to that server.
  • Oracle WebLogic — Add the wlcipher.jar, wlclient.jar, and cryptoj.jar WebLogic JARs to your client side CLASSPATH.

    With WebLogic, queue security parameters have no bearing. If a queue is secured in the WebLogic console, the JNDI security parameters must be set up at the client. Queue security parameter can be set (or not set) on the client without changing the outcome.

Setting up JMS security using customer_overrides.properties file

You can set the JMS security parameters for an IBM agent or service to authenticate to the JMS queues in the customer_overrides.properties file.

To enable Java clients to authenticate to the JNDI set the following two parameters:

  • java.naming.security.principal
  • java.naming.security.credentials

SSL encryption for JMS cannot be set up through customer overrides properties and has to be set up through system properties.

To enable an IBM agent or service to authenticate to the JMS queues set the following two parameters:

  • yfs.sci.queuebasedsecurity.userid
  • yfs.sci.queuebasedsecurity.password
Note: To use the properties that are provided in the customer_overrides.properties file, in the JMS Security Properties tab the Enable JMS Security flag must be selected and make sure that no other flag is selected.