2 Enabling General Security Measures

Protect processes, local artifacts, listeners, and credentials before applying feature-specific policy.

Run members and administrative tools with dedicated, minimally privileged service identities. Restrict write access to application JARs, configuration, native libraries, persistence, snapshots, reports, and credential sources. A process that can replace trusted code or configuration can change the effective security policy.

Bind listeners only where needed and restrict network access to the intended members, clients, administrators, and scrapers. Configure and test each surface in Conceptual Overview of Oracle Coherence Security. Use supported operating-system/container resource and isolation controls for the member process and external data loaders.

Deployment baseline

  • Keep a recorded configuration and artifact inventory, including optional modules and native binaries.

  • Use TLS trust, matching peer names, and the required identity policy before transmitting credentials.

  • Configure service/storage authorization and application serialization policy explicitly.

  • Give persistence and report output dedicated protected directories; review restore/import permissions.

  • Use bounded logs and operational identifiers. Avoid logging passwords, bearer tokens, complete authorization headers, private keys, or arbitrary payload values.

  • Exercise successful and rejected operations before exposing a new listener or activating a stronger profile.

Current JDK security

Java Security Manager instructions apply only to older JDKs that still support it. Beginning with JDK 24 it is permanently disabled. Use Using Authenticated Subjects with Modern Java for current subject context, and configure Coherence's own authorization APIs independently. Keep legacy policy files only for the supported deployment that actually uses them.

  • Using the Java Security Manager
    Recognize legacy Java policy instructions and use current application and process controls on modern JDKs.
  • Using Host-Based Authorization
    Host-based authorization is a type of access control that allows you to specify which hosts (based on host name or IP address) can connect to a cluster.
  • Managing Rogue Clients
    You can use the suspect protocol to safeguard against rogue extend clients that operate outside of acceptable limits.

Using the Java Security Manager

Recognize legacy Java policy instructions and use current application and process controls on modern JDKs.

The Java Security Manager is permanently disabled beginning with JDK 24. Enabling it at startup is an error on those JDKs. Java policy files and related checks must not be presented as the security prerequisite for a current Coherence deployment.

The child topics are retained for supported older-JDK deployments that explicitly use the legacy mechanism. Check the exact JDK and Coherence release before using their flags or permissions. Do not add Security Manager flags to a modern JVM to repair a Coherence authorization failure.

JAAS login, authenticated subject context, Coherence access controllers, and StorageAccessAuthorizer have separate responsibilities. Use the supported operating-system/container boundary for process resource access and Using Authenticated Subjects with Modern Java for current Java examples.

The Security Manager Is Permanently Disabled

Parent topic: Enabling General Security Measures

Enable the Java Security Manager

These Java Security Manager instructions apply only to a supported older JDK that still implements that mechanism. The Security Manager is permanently disabled beginning with JDK 24. Use the current Coherence/application authorization and process isolation controls on newer JDKs.

To enable the Java security manager and use the COHERENCE_HOME /lib/security/security.policy file, set the following properties on a cluster member:

  1. Set the java.security.manager property to enable the Java security manager. For example:
    -Djava.security.manager
  2. Set the java.security.policy property to the location of the policy file. For example:
    -Djava.security.manager
-Djava.security.policy=/coherence/lib/security/security.policy
  3. Set the coherence.home system property to COHERENCE_HOME . For example:
    -Djava.security.manager
-Djava.security.policy=/coherence/lib/security/security.policy
-Dcoherence.home=/coherence

Note:

The security policy file assumes that the default Java Runtime Environment (JRE) security permissions have been granted. Therefore, you must be careful to use a single equal sign (=) and not two equal signs (==) when setting the java.security.policy system property.

Parent topic: Using the Java Security Manager

Specify Permissions

These Java Security Manager instructions apply only to a supported older JDK that still implements that mechanism. The Security Manager is permanently disabled beginning with JDK 24. Use the current Coherence/application authorization and process isolation controls on newer JDKs.

Modify the COHERENCE_HOME /lib/security/security.policy file to include additional permissions as required. See Permissions in the Java Development Kit (JDK) in Java SE Security.

To specify additional permissions in the security.policy file:

  1. Edit the security.policy file and add a permission for a resource. For example, the following permission grants access to the coherence.jar library:
    grant codeBase "file:${coherence.home}/lib/coherence.jar"
    {
            permission java.security.AllPermission;
    };
  2. When you declare binaries, sign the binaries using the JDK jarsigner tool. The following example signs the coherence.jar resource declared in the previous step:
    jarsigner -keystore ./keystore.jks -storepass password coherence.jar admin

    Add the signer in the permission declaration. For example, modify the original permission as follows to add the admin signer. 

    grant SignedBy "admin" codeBase "file:${coherence.home}/lib/coherence.jar"
    {
            permission java.security.AllPermission;
    };
  3. Use operating system mechanisms to protect all relevant files from malicious modifications.

Parent topic: Using the Java Security Manager

Programmatically Specifying Local Permissions

Scope legacy local Java permission checks to JDKs that support them and use current Coherence authorization for application policy.

Local Java permission-policy examples depend on the Java Security Manager contract of the deployed JDK. That contract is unavailable on JDK 24 and later. Retain older permission configuration only for a supported older-JDK environment that explicitly requires it.

For current applications, define the resource and operation policy in the appropriate Coherence/application authorizer and establish a verified subject through the chosen identity system. Use operating-system and container controls for file, process, and network privileges. A successful subject login does not install a JVM sandbox.

See Using an Access Controller, Authorizing Access to Server-Side Operations, and Using Authenticated Subjects with Modern Java.

Parent topic: Using the Java Security Manager

Using Host-Based Authorization

Host-based authorization is a type of access control that allows you to specify which hosts (based on host name or IP address) can connect to a cluster. The feature is available for both cluster member connections and extend client connections.

This section includes the following topics:

Parent topic: Enabling General Security Measures

Overview of Host-Based Authorization

Host-based authorization uses the host name and IP address of a cluster member or extend client to determine whether a connection to the cluster is allowed. Specific host names, addresses, and address ranges can be defined. For custom processing, a custom filter can be created to validate hosts.

Host-based authorization is ideal for environments where known hosts with relatively static network addresses are joining or accessing the cluster. In dynamic environments, or when updating a DNS server, IP addresses can change and cause a cluster member or extend client to fail authorization. Cache operations may not complete if cluster members or extend clients are no longer authorized. Extend clients are more likely to have access problems because of their transient nature.

When using host-based authorization, consider the dynamic nature of the network environment. The need to reconfigure the list of authorized hosts may become impractical. If possible, always use a range of IP addresses instead of using a specific host name. Or, create a custom filter that is capable of resolving address that have changed. If host-based authorization becomes impractical, consider using extend client identity tokens or SSL. See Using Identity Tokens to Restrict Client Connections and Using TLS to Secure Communication, respectively.

Parent topic: Using Host-Based Authorization

Specify Cluster Member Authorized Hosts

The default behavior of a cluster allows any host to connect to the cluster and become a cluster member. Host-based authorization changes this behavior to allow only hosts with specific host names or IP addresses to connect to the cluster.

Configure authorized hosts in an operational override file using the <authorized-hosts> element within the <cluster-config> element. Enter specific addresses using the <host-address> element or a range of addresses using the <host-range> element. The <host-address> and <host-range> elements support an id attribute for uniquely identifying multiple elements. Additionally, an application can set the system property coherence.authorized.hosts with a comma-separated list of IP addresses and/or host names authorized as cluster members.

The following example configures a cluster to accept only cluster members whose IP address is either 192.168.0.5, 192.168.0.6, or within the range of 192.168.0.10 to 192.168.0.20 and 192.168.0.30 to 192.168.0.40.

<?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>
      <authorized-hosts>
         <host-address id="1">192.168.0.5</host-address>
         <host-address id="2">192.168.0.6</host-address>
         <host-range id="1">
            <from-address>192.168.0.10</from-address>
            <to-address>192.168.0.20</to-address>
         </host-range>
         <host-range id="2">
            <from-address>192.168.0.30</from-address>
            <to-address>192.168.0.40</to-address>
         </host-range>
      </authorized-hosts>
   </cluster-config>
</coherence>

Parent topic: Using Host-Based Authorization

Specify Extend Client Authorized Hosts

The default behavior of an extend proxy server allows any extend client to connect to the cluster. Host-based authorization changes this behavior to allow only hosts with specific host names or IP addresses to connect to the cluster.

Configure authorized hosts in a cache configuration file using the <authorized-hosts> element within the <tcp-acceptor> element of a proxy scheme definition. Enter specific addresses using the <host-address> element or a range of addresses using the <host-range> element. The <host-address> and <host-range> elements support an id attribute for uniquely identifying multiple elements. Additionally, an application can set the system property coherence.extend.authorized.hosts with a comma-separated list of IP addresses and/or host names authorized to join proxy as an extend client.

The following example configures an extend proxy to accept only client connections from clients whose IP address is either 192.168.0.5, 192.168.0.6, or within the range of 192.168.0.10 to 192.168.0.20 and 192.168.0.30 to 192.168.0.40.

<proxy-scheme>
   <service-name>ExtendTcpProxyService</service-name>
   <thread-count>5</thread-count>
   <acceptor-config>
      <tcp-acceptor>
         ...
         <authorized-hosts>
            <host-address id="1">192.168.0.5</host-address>
            <host-address id="2">192.168.0.6</host-address>
            <host-range id="1">
               <from-address>192.168.0.10</from-address>
               <to-address>192.168.0.20</to-address>
            </host-range>
            <host-range id="2">
               <from-address>192.168.0.30</from-address>
               <to-address>192.168.0.40</to-address>
            </host-range>
         </authorized-hosts>
         ...
      </tcp-acceptor>
   </acceptor-config>
   <autostart>true</autostart>
</proxy-scheme>

Parent topic: Using Host-Based Authorization

Use a Filter Class to Determine Authorization

A filter class determines whether to accept a particular host connection. Both extend client connections and cluster member connections support using filter classes. A filter class must implement the com.tangosol.util.Filter interface. The evaluate() method of the interface is passed the java.net.InetAddress of the host. Implementations should return true to accept the connection.

To enable a filter class, enter a fully qualified class name using the <class-name> element within the <host-filter> element. Set initialization parameters using the <init-params> element.

The following example configures a filter named MyFilter, which determines if a host connection is allowed. 

<authorized-hosts>
   <host-filter>
      <class-name>package.MyFilter</class-name>
         <init-params>
            <init-param>
               <param-name>sPolicy</param-name>
               <param-value>strict</param-value>
            </init-param>
         </init-params>
   </host-filter>
</authorized-hosts>

Note:

If <host-filter> is provided, all <host-address> and <host-range> elements are superseded by that filter and have no effect. Setting the system properties coherence.authorized.hosts and coherence.extend.authorized.hosts is ignored if the corresponding <authorized-hosts><host-filter> has been provided, it takes complete precedence.

Parent topic: Using Host-Based Authorization

Managing Rogue Clients

You can use the suspect protocol to safeguard against rogue extend clients that operate outside of acceptable limits. Rogue clients are slow-to-respond clients or abusive clients that attempt to overuse a proxy— as is the case with denial of service attacks. In both cases, the potential exists for a proxy to run out of memory and become unresponsive.

The suspect algorithm monitors client connections looking for abnormally slow or abusive clients. When a rogue client connection is detected, the algorithm closes the connection to protect the proxy server from running out of memory. The protocol works by monitoring both the size (in bytes) and length (in messages) of the outgoing connection buffer backlog for a client. Different levels determine when a client is suspect, when it returns to normal, or when it is considered rogue.

Configure the suspect protocol within the <tcp-acceptor> element of a proxy scheme definition. See tcp-acceptor in Developing Applications with Oracle Coherence. The suspect protocol is enabled by default.

The following example demonstrates configuring the suspect protocol and is similar to the default settings. When the outgoing connection buffer backlog for a client reaches 10 MB or 10000 messages, the client is considered suspect and is monitored. If the connection buffer backlog for a client returns to 2 MB or 2000 messages, then the client is considered safe and the client is no longer monitored. If the connection buffer backlog for a client reaches 95 MB or 60000 messages, then the client is considered unsafe and the proxy closes the connection.

<proxy-scheme>
   <service-name>ExtendTcpProxyService</service-name>
   <thread-count>5</thread-count>
   <acceptor-config>
      <tcp-acceptor>
         ...
         <suspect-protocol-enabled>true</suspect-protocol-enabled>
         <suspect-buffer-size>10M</suspect-buffer-size>
         <suspect-buffer-length>10000</suspect-buffer-length>
         <nominal-buffer-size>2M</nominal-buffer-size>
         <nominal-buffer-length>2000</nominal-buffer-length>
         <limit-buffer-size>95M</limit-buffer-size>
         <limit-buffer-length>60000</limit-buffer-length>
      </tcp-acceptor>
   </acceptor-config>
   <autostart>true</autostart>
</proxy-scheme>

Parent topic: Enabling General Security Measures