Skip Headers
Oracle® Coherence Security Guide
Release 3.7

Part Number E18681-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
View PDF

5 Using SSL to Secure Communication

Coherence provides a Secure Socket Layer (SSL) implementation that secures TCMP communication between cluster nodes and the TCP communication between Coherence*Extend clients and proxies. Coherence supports the Transport Layer Security (TLS) 1.0 protocol which is the next version of the SSL 3.0 protocol; however, the term SSL is used in this documentation since it is the more widely recognized term.

The following sections are included in this chapter:

5.1 Overview of SSL

This section provides a brief overview of common SSL concepts that are used in this documentation and is not intended to be a complete guide to SSL. Those new to SSL should refer to the formal specification maintained at http://www.ietf.org and the Java SE Security resources located at http://java.sun.com/javase/technologies/security/index.jsp. Those familiar with SSL can skip this section.

SSL is a security protocol that secures communication between entities (typically, clients and servers) over a network. SSL works by authenticating clients and servers using digital certificates and by encrypting/decrypting communication using unique keys that are associated with authenticated clients and servers.

Establishing Identity and Trust

An entity's identity is established using a digital certificate and public and private encryption keys. The digital certificate contains general information about the entity and also contains the public encryption key embedded within it. A digital certificate is verified by a Certificate Authority (CA) and signed using the CA's digital certificate. The CA's digital certificate establishes trust that the entity is authentic.

Encrypting and Decrypting Data

An entity's digital certificate contains a public encryption key that is paired with the entity's private encryption key. Certificates are passed between entities during an initial connection. Data is then encrypted using the public key. Data that is encrypted using an entity's public key can only be decrypted by the entity's private key. This ensures that only the entity that owns the public encryption key can decrypt the data.

Using One-Way Authentication Versus Two-Way Authentication

SSL communication between clients and servers can be set up using either one-way or two-way authentication. With one-way authentication, a server is required to identify itself to a client by sending its digital certificate for authentication. The client is not required to send the server a digital certificate and remains anonymous to the server. Two-Way authentication requires both the client and the server to send their respective digital certificates to each other for mutual authentication. Two-way authentication provides stronger security by assuring that the identity on both sides of the communication are known.

Generating SSL Artifacts

The Java keytool utility that is located in the JDK_HOME/bin directory is used to generate and manage SSL artifacts. This includes: creating a key store; generating a unique public/private key pair; creating a self-signed digital certificate that includes the public key, associating the certificate with the private key; and storing these artifacts in the key store.

The following example creates a key store named server.jks that is located in the /test directory. A public and private key pair are generated for the entity identified by the -dname value ("cn=administrator, ou=Coherence, o=Oracle, c=US"). A self-signed certificate is created that includes the public key and identity information. The certificate is valid for 180 days and is associated with the private key in a key store entry referred to by the alias (admin). Passwords must be entered for both the key store and private key.

keytool -genkeypair -dname "cn=administrator, ou=Coherence, o=Oracle, c=US" 
-alias admin -keypass password -keystore /test/server -storepass password 
-validity 180

The certificate generated by this command is adequate for development purposes. However, certificates are typically verified by a trusted CA (such as VeriSign). To have the certificate verified, use the keytool utility to generate a Certificate Signing Request (CSR) file:

keytool -certreq -file admin.csr

This CSR file must be sent to the CA, which returns a signed certificate. Use the keytool utility to import the returned certificate which replaces the self-signed certificate in the key store:

keytool -importcert -trustcacerts -file signed_admin.cer

Lastly, the keytool utility is used to create a second key store that acts as a trust store. The trust store contains digital certificates of trusted CAs. Certificates that have been verified by a CA are only considered trusted if the CA's certificate is also found in the trust store. For example, in a typical one-way authentication scenario, a client must have a trust store that contains a digital certificate of the CA that signed the server's certificate. For development purposes, a self-signed certificate can be used for both identity and trust; moreover, a single keystore can be used as both the identity store and the trust store.

5.2 Using SSL to Secure TCMP Communication

A Coherence cluster can be configured to use SSL with TCMP. Coherence supports both one-way and two-way authentication. Two-Way authentication is typically used more often than one-way authentication, which has fewer use cases in a cluster environment. In addition, it is important to realize that TCMP is a peer-to-peer protocol that generally runs in trusted environments where many cluster nodes are expected to remain connected with each other. The implications of SSL on administration and performance should be carefully considered.

The following topics are include in this section:

5.2.1 Defining a SSL Socket Provider

SSL for TCMP is configured in an operational override file by overriding the <socket-provider> element within the <unicast-listener> element. The preferred approach is to use the <socket-provider> element to reference a SSL socket provider configuration that is defined within a <socket-providers> node. The <socket-provider> element can also be used to define a full configuration within the <unicast-listener> element. Both approaches are demonstrated below. See Oracle Coherence Developer's Guide for a detailed reference of the <socket-provider> element.

Note:

A cluster must be configured to use well known addresses to use SSL with TCMP. See Oracle Coherence Developer's Guide for details on setting up well known addresses.

Example 5-1 demonstrates a SSL two-way authentication setup and requires both an identity store and trust store to be located on each node in the cluster. The example uses the default values for the <protocol> and <algorithm> element (TLS and SunX509, respectively). These are shown for completeness but may be left out when using the default values. The example uses the preferred approach where the SSL socket provider is defined within the <socket-providers> node and referred to from within the <unicast-listener> element.

Example 5-1 Sample SSL Configuration for TCMP Communication

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
   xsi:schemaLocation="http://xmlns.oracle.com/coherence/
   coherence-operational-config coherence-operational-config.xsd">
   <cluster-config>
      <unicast-listener>
         <socket-provider>mySSLConfig</socket-provider>
         <well-known-addresses>
            <socket-address id="1">
               <address>198.168.1.5</address>
               <port>8088</port>
            </socket-address>
         </well-known-addresses>
      </unicast-listener>

      <socket-providers>
         <socket-provider id="mySSLConfig">
            <ssl>
               <protocol>TLS</protocol>
               <identity-manager>
                  <algorithm>SunX509</algorithm>
                  <key-store>
                     <url>file:server.jks</url>
                     <password>password</password>
                     <type>JKS</type>
                  </key-store>
                  <password>password</password>
               </identity-manager>
               <trust-manager>
                  <algorithm>SunX509</algorithm>
                  <key-store>
                     <url>file:trust.jks</url>
                     <password>password</password>
                     <type>JKS</type>
                  </key-store>
               </trust-manager>
            </ssl>
         </socket-provider>
      </socket-providers>
   </cluster-config>
</coherence>

As an alternative, the SSL socket provider can also be directly defined in the <unicast-listener> element as shown below:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
   xsi:schemaLocation="http://xmlns.oracle.com/coherence/
   coherence-operational-config coherence-operational-config.xsd">
   <cluster-config>
      <unicast-listener>
         <socket-provider>
            <ssl>
               <protocol>TLS</protocol>
               <identity-manager>
                  <algorithm>SunX509</algorithm>
                  <key-store>
                     <url>file:server.jks</url>
                     <password>password</password>
                     <type>JKS</type>
                  </key-store>
                  <password>password</password>
               </identity-manager>
               <trust-manager>
                  <algorithm>SunX509</algorithm>
                  <key-store>
                     <url>file:trust.jks</url>
                     <password>password</password>
                     <type>JKS</type>
                  </key-store>
               </trust-manager>
            </ssl>
         </socket-provider>
         <well-known-addresses>
            <socket-address id="1">
               <address>198.168.1.5</address>
               <port>8088</port>
            </socket-address>
         </well-known-addresses>
      </unicast-listener>
   </cluster-config>
</coherence>

5.2.2 Using the Pre-Defined SSL Socket Provider

Out-of-box, a pre-defined SSL socket provider is included that allows for configuration of two-way SSL connections that is based on peer trust where every trusted peer resides within a single JKS key store. The proprietary peer trust algorithm (PeerX509) works by assuming trust (and only trust) of the certificates that are in the key store. The peer algorithm can increase the performance of SSL by leveraging the fact that TCMP is a peer-to-peer protocol.

The pre-defined SSL socket provider is located within the <socket-providers> element in the operational deployment descriptor:

...
<cluster-config>
   <socket-providers>
      <socket-provider id="ssl">
         <ssl>
            <identity-manager>
               <key-store>
                  <url system-property="tangosol.coherence.security.keystore">
                     file:keystore.jks
                  </url>
                  <password system-property="tangosol.coherence.security.
                     password"/>
               </key-store>
               <password system-property="tangosol.coherence.security.password"/>
            </identity-manager>
            <trust-manager>
               <algorithm>PeerX509</algorithm>
               <key-store>
                  <url system-property="tangosol.coherence.security.keystore">
                     file:keystore.jks
                  </url>
                  <password system-property="tangosol.coherence.security.
                     password"/>
               </key-store>
            </trust-manager>
         </ssl>
      </socket-provider>
   </socket-providers>
</cluster-config>
...

As configured, the pre-defined SSL socket provider requires a Java key store named keystore.jks that is found on the classpath. This name can be overridden using the tangosol.coherence.security.keystore system property to specify a different key store. In addition, the tangosol.coherence.security.password system property can specify the required password for the key store and certificate. As an alternative, an operational override file may be used to modify the pre-defined SSL socket provider definition as required.

Note:

Ensure that certificates for all nodes in the cluster have been imported into the key store.

To use the pre-defined SSL socket provider, override the <socket-provider> element in the <unicast-listener> configuration and reference the SSL socket provider using it's id attribute. The following example configures a unicast listener to use the pre-defined SSL socket provider.

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
   xsi:schemaLocation="http://xmlns.oracle.com/coherence/
   coherence-operational-config coherence-operational-config.xsd">
   <cluster-config>
      <unicast-listener>
         <socket-provider>ssl</socket-provider>
         <well-known-addresses>
            <socket-address id="1">
               <address>198.168.1.5</address>
               <port>8088</port>
            </socket-address>
         </well-known-addresses>
      </unicast-listener>
   </cluster-config>
</coherence>

5.3 Using SSL to Secure Extend Client Communication

Communication between extend clients and extend proxies can be secured using SSL. SSL requires configuration on both the client side and the cluster side. SSL is supported for both Java and .NET clients but not for C++ clients.

The configuration examples in this section assume that valid digital certificates for all clients and servers have been created as required and that the certificates have been signed by a Certificate Authority (CA). The digital certificates must be found in an identity store, and the trust store must include the signing CA's digital certificate. Self-Signed certificates may be used during development as needed.

The following topics are included in this section:

5.3.1 Configuring a Cluster-Side SSL Socket Provider

SSL is configured in the cluster-side cache configuration file by defining a SSL socket provider for a proxy service. There are two options for configuring a SSL socket provider depending on the level of granularity that is required:

  • Per Proxy Service – Each proxy service defines a SSL socket provider configuration or references a pre-defined configuration that is included in the operational configuration file.

  • All Proxy Services – All proxy services use the same global SSL socket provider configuration. Proxy services that provide their own configuration override the global configuration. The global configuration can also reference a predefined configuration that is included in the operational configuration file.

5.3.1.1 Configure a SSL Socket Provider Per Proxy Service

To configure a SSL socket provider for a proxy service, add a <socket-provider> element within the <tcp-acceptor> element of each <proxy-scheme> definition. See "socket-provider" in Oracle Coherence Developer's Guide for a detailed reference of the <socket-provider> element.

Example 5-2 demonstrates a proxy scheme that configures a SSL socket provider that uses the default values for the <protocol> and <algorithm> element (TLS and SunX509, respectively). These are shown for completeness but may be left out when using the default values.

Example 5-2 configures both an identity key store (server.jks) and a trust key store (trust.jks). This is typical of two-way SSL authentication where both the client and proxy must exchange their digital certificate and confirm each other's identity. For one-way SSL authentication, the proxy server configuration must include an identity key store but need not include a trust key store.

Example 5-2 Sample Cluster-Side SSL Configuration

...
<proxy-scheme>
   <service-name>ExtendTcpSSLProxyService</service-name>
   <acceptor-config>
      <tcp-acceptor>
         <socket-provider>
            <ssl>
               <protocol>TLS</protocol>
               <identity-manager>
                  <algorithm>SunX509</algorithm>
                  <key-store>
                     <url>file:server.jks</url>
                     <password>password</password>
                     <type>JKS</type>
                  </key-store>
                  <password>password</password>
               </identity-manager>
               <trust-manager>
                  <algorithm>SunX509</algorithm>
                  <key-store>
                     <url>file:trust.jks</url>
                     <password>password</password>
                     <type>JKS</type>
                  </key-store>
               </trust-manager>
            </ssl>
         </socket-provider>
         <local-address>
            <address>192.168.1.5</address>
            <port>9099</port>
         </local-address>
      </tcp-acceptor>
   </acceptor-config>
   <autostart>true</autostart>
</proxy-scheme>
...

The following example references a SSL socket provider configuration that is defined in the <socket-providers> node of the operational deployment descriptor by specifying the configuration's id attribute (ssl). See "socket-providers" in Oracle Coherence Developer's Guide for a detailed reference of the <socket-providers> element.

Note:

Out-of-box, a pre-defined SSL socket provider is included in the operational deployment descriptor and is named ssl. The pre-defined SSL socket provider is configured for two-way SSL connections and is based on peer trust where every trusted peer resides within a single JKS key store. See "Using the Pre-Defined SSL Socket Provider" for details. To configure a different SSL socket provider, use an operational override file to modify the pre-defined SSL socket provider or to create a socket provider configuration as required.
...
<proxy-scheme>
   <service-name>ExtendTcpSSLProxyService</service-name>
   <acceptor-config>
      <tcp-acceptor>
         <socket-provider>ssl</socket-provider>
         <local-address>
            <address>192.168.1.5</address>
            <port>9099</port>
         </local-address>
      </tcp-acceptor>
   </acceptor-config>
   <autostart>true</autostart>
</proxy-scheme>
...

5.3.1.2 Configure a SSL Socket Provider for All Proxy Services

To configure a global SSL socket provider for use by all proxy services, use a <socket-provider> element within the <defaults> element of the cache configuration file. With this approach, no additional configuration is required within a proxy scheme definition. See "defaults" in Oracle Coherence Developer's Guide for a detailed reference of the <default> element.

The following example uses the same SSL socket provider configuration from Example 5-2 and configures it for all proxy services:

<?xml version='1.0'?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
   xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
   coherence-cache-config.xsd">
   <defaults>
      <socket-provider>
         <ssl>
            <protocol>TLS</protocol>
            <identity-manager>
               <algorithm>SunX509</algorithm>
               <key-store>
                  <url>file:server.jks</url>
                  <password>password</password>
                  <type>JKS</type>
               </key-store>
               <password>password</password>
            </identity-manager>
            <trust-manager>
               <algorithm>SunX509</algorithm>
               <key-store>
                  <url>file:trust.jks</url>
                  <password>password</password>
                  <type>JKS</type>
               </key-store>
            </trust-manager>
         </ssl>
      </socket-provider>
   </defaults>
   ...

The following example configures a global SSL socket provider by referencing a SSL socket provider configuration that is defined in the operational deployment descriptor:

<defaults>
   <socket-provider>ssl</socket-provider>
</defaults>

5.3.2 Configure a Java Client-Side SSL Socket Provider

SSL is configured in the client-side cache configuration file by defining a SSL socket provider for a remote cache scheme and, if required, for a remote invocation scheme. There are two options for configuring a SSL socket provider depending on the level of granularity that is required:

  • Per Remote Service – Each remote service defines a SSL socket provider configuration or references a pre-defined configuration that is included in the operational configuration file.

  • All Remote Services – All remote services use the same global SSL socket provider configuration. Remote services that provide their own configuration override the global configuration. The global configuration can also reference a predefined configuration that is included in the operational configuration file.

5.3.2.1 Configure a SSL Socket Provider Per Remote Service

To configure a SSL socket provider for a remote service, add a <socket-provider> element within the <tcp-initiator> element of a remote scheme definition. See "socket-provider" in Oracle Coherence Developer's Guide for a detailed reference of the <socket-provider> element.

Example 5-3 demonstrates a remote cache scheme that configures a socket provider that uses SSL. The example uses the default values for the <protocol> and <algorithm> element (TLS and SunX509, respectively). These are shown for completeness but may be left out when using the default values.

Example 5-3 configures both an identity key store (server.jks) and a trust key store (trust.jks). This is typical of two-way SSL authentication where both the client and proxy must exchange their digital certificate and confirm each other's identity. For one-way SSL authentication, the client configuration must include a trust key store but need not include an identity key store, which indicates the client does not exchange its digital certificate to the proxy and remains anonymous. The client's trust key store must includes the CA's digital certificate that was used to sign the proxy's digital certificate.

Example 5-3 Sample Java Client-Side SSL Configuration

<?xml version="1.0"?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
   xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
   coherence-cache-config.xsd">
   <caching-scheme-mapping>
      <cache-mapping>
         <cache-name>dist-extend</cache-name>
         <scheme-name>extend-dist</scheme-name>
      </cache-mapping>
   </caching-scheme-mapping>

   <caching-schemes>
      <remote-cache-scheme>
         <scheme-name>extend-dist</scheme-name>
         <service-name>ExtendTcpSSLCacheService</service-name>
         <initiator-config>
            <tcp-initiator>
               <socket-provider>
                  <ssl>
                     <protocol>TLS</protocol>
                     <identity-manager>
                        <algorithm>SunX509</algorithm>
                        <key-store>
                           <url>file:server.jks</url>
                           <password>password</password>
                           <type>JKS</type>
                        </key-store>
                        <password>password</password>
                     </identity-manager>
                     <trust-manager>
                        <algorithm>SunX509</algorithm>
                        <key-store>
                           <url>file:trust.jks</url>
                           <password>password</password>
                           <type>JKS</type>
                        </key-store>
                     </trust-manager>
                  </ssl>
               </socket-provider>
               <remote-addresses>
                  <socket-address>
                     <address>198.168.1.5</address>
                     <port>9099</port>
                  </socket-address>
               </remote-addresses>
               <connect-timeout>10s</connect-timeout>
            </tcp-initiator>
            <outgoing-message-handler>
               <request-timeout>5s</request-timeout>
            </outgoing-message-handler>
         </initiator-config>
      </remote-cache-scheme>
   </caching-schemes>
</cache-config>

The following example references a SSL socket provider configuration that is defined in the <socket-providers> node of the operational deployment descriptor by specifying the configuration's id attribute (ssl). See "socket-providers" in Oracle Coherence Developer's Guide for a detailed reference of the <socket-providers> element.

Note:

Out-of-box, a pre-defined SSL socket provider is included in the operational deployment descriptor and is named ssl. The pre-defined SSL socket provider is configured for two-way SSL connections and is based on peer trust where every trusted peer resides within a single JKS key store. See for "Using the Pre-Defined SSL Socket Provider" for details. To configure a different SSL socket provider, use an operational override file to modify the pre-defined SSL socket provider or to create a socket provider configuration as required.
<?xml version="1.0"?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
   xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
   coherence-cache-config.xsd">
   <caching-scheme-mapping>
      <cache-mapping>
         <cache-name>dist-extend</cache-name>
         <scheme-name>extend-dist</scheme-name>
      </cache-mapping>
   </caching-scheme-mapping>

   <caching-schemes>
      <remote-cache-scheme>
         <scheme-name>extend-dist</scheme-name>
         <service-name>ExtendTcpSSLCacheService</service-name>
         <initiator-config>
            <tcp-initiator>
               <socket-provider>ssl</socket-provider>
               <remote-addresses>
                  <socket-address>
                     <address>198.168.1.5</address>
                     <port>9099</port>
                  </socket-address>
               </remote-addresses>
               <connect-timeout>10s</connect-timeout>
            </tcp-initiator>
            <outgoing-message-handler>
               <request-timeout>5s</request-timeout>
            </outgoing-message-handler>
         </initiator-config>
      </remote-cache-scheme>
   </caching-schemes>
</cache-config>

5.3.2.2 Configure a SSL Socket Provider for All Remote Services

To configure a global SSL socket provider for use by all remote services, use a <socket-provider> element within the <defaults> element of the cache configuration file. With this approach, no additional configuration is required within a remote scheme definition. See "defaults" in Oracle Coherence Developer's Guide for a detailed reference of the <default> element.

The following example uses the same SSL socket provider configuration from Example 5-3 and configures it for all remote services:

<?xml version='1.0'?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
   xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
   coherence-cache-config.xsd">
   <defaults>
      <socket-provider>
         <ssl>
            <protocol>TLS</protocol>
            <identity-manager>
               <algorithm>SunX509</algorithm>
               <key-store>
                  <url>file:server.jks</url>
                  <password>password</password>
                  <type>JKS</type>
               </key-store>
               <password>password</password>
            </identity-manager>
            <trust-manager>
               <algorithm>SunX509</algorithm>
               <key-store>
                  <url>file:trust.jks</url>
                  <password>password</password>
                  <type>JKS</type>
               </key-store>
            </trust-manager>
         </ssl>
      </socket-provider>
   </defaults>
   ...

The following example configures a global SSL socket provider by referencing a SSL socket provider configuration that is defined in the operational deployment descriptor:

<defaults>
   <socket-provider>ssl</socket-provider>
</defaults>

5.3.3 Configure a .NET Client-Side Stream Provider

SSL is configured in the .NET client-side cache configuration file by defining an SSL stream provider for remote serviceS. The SSL stream provider is is defined using the <stream-provider> element within the <tcp-initiator> element.

Note:

Certificates are managed on Window servers at the operating system level using the Certificate Manager. The sample configuration assumes that the extend proxy's certificate is included in the Certificate Manager and that the CA's certificate that was used to sign the proxy's certificate is included as a trusted certificate authority. For more information on managing certificates, see http://technet.microsoft.com/en-us/library/cc782338(WS.10).aspx.

Example 5-4 demonstrates a remote cache scheme that configures a SSL stream provider. Refer to the cache configuration XML schema (INSTALL_DIR\config\cache-config.xsd) for details on the elements used to configure a SSL stream provider.

Example 5-4 Sample .NET Client-Side SSL Configuration

<?xml version="1.0"?>

<cache-config xmlns="http://schemas.tangosol.com/cache"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://schemas.tangosol.com/cache
   assembly://Coherence/Tangosol.Config/cache-config.xsd">
   <caching-scheme-mapping>
      <cache-mapping>
         <cache-name>dist-extend</cache-name>
         <scheme-name>extend-dist</scheme-name>
      </cache-mapping>
   </caching-scheme-mapping>

   <caching-schemes>
      <remote-cache-scheme>
         <scheme-name>extend-dist</scheme-name>
         <service-name>ExtendTcpSSLCacheService</service-name>
         <initiator-config>
            <tcp-initiator>
               <stream-provider>
                  <ssl>
                     <protocol>Tls</protocol>
                     <local-certificates>
                        <certificate>
                           <url>C:\</url>
                           <password>password</password>
                           <flags>DefaultKeySet</flags>
                        </certificate>
                     </local-certificates>
                  </ssl>
               </stream-provider>
               <remote-addresses>
                  <socket-address>
                     <address>198.168.1.5</address>
                     <port>9099</port>
                  </socket-address>
               </remote-addresses>
               <connect-timeout>10s</connect-timeout>
            </tcp-initiator>
            <outgoing-message-handler>
               <request-timeout>5s</request-timeout>
            </outgoing-message-handler>
         </initiator-config>
      </remote-cache-scheme>
   </caching-schemes>
</cache-config>