1 Introduction to Oracle Coherence Security

Choose explicit controls for cluster members, external clients, management, application code, and persisted data.

This guide explains how to configure and operate Coherence security across its distributed data and administrative surfaces. Start with Understanding Security Profiles and Coherence Security Quick Start, then follow the recipes for the listeners and application behavior your deployment uses.

Treat a cluster member as trusted application infrastructure. Restrict membership and member-side code deployment. Authenticate external clients, authorize their operations, classify remotely supplied executable objects, and constrain the data and resource boundaries described in this guide. Protect management and optional components independently.

Deployment and version scope

Starting with Coherence 26.1.0.0, an unset coherence.security.mode selects the hardened security profile. Select compatibility explicitly if an upgrade plan needs a temporary compatibility phase. Match configuration to the deployed distribution, JDK, client version, and optional modules, and consult the release/patch documentation for another code line. Newer Java APIs used by an example have explicit prerequisites; older-JDK compatibility material is labeled accordingly.

The security profile does not provide every service's transport and identity setup. Use Security Behavior Matrix to distinguish profile-sensitive defaults, mode-independent protections, and separately configured policy. Use Security Configuration Reference for ownership and override details.

Start from the deployment task

• For new deployment, assemble the baseline, TLS, identity, authorization, and application-artifact configuration before exposing listeners.

• For an existing deployment, follow Rolling Upgrade to Hardened Security and exercise compatibility and hardened workflows before changing production policy.

• For a failed request, identify the boundary and signal in Security Errors and Diagnostic Signals before loosening a setting.

• Conceptual Overview of Oracle Coherence Security
  Understand the separate trust decisions made for connections, subjects, application types, operations, and stored bytes.
• Understanding Security Profiles
  Use the security profile to select compatibility-sensitive hardening behavior independently of the Coherence runtime mode.
• Coherence Security Quick Start
  Start securing a Coherence deployment by protecting local resources, configuring transport and identity, authorizing operations, and preparing application security configuration.
• Overview of Security Configuration
  Place security configuration in the owning descriptor or artifact and verify its effective value on each process.

Conceptual Overview of Oracle Coherence Security

Understand the separate trust decisions made for connections, subjects, application types, operations, and stored bytes.

Security configuration should answer five questions: which peer may connect, which identity made a request, which operation that identity may perform, which application types/behavior a receiver may accept, and which stored input a process may consume. Apply the corresponding controls together.

Boundary	Principal controls	Practical limit
Cluster member and federation peer	Network isolation, TLS/mTLS, approved participant/endpoints, supported peer proof	A cluster name or self-advertised address is not cryptographic identity.
External client/proxy	TLS, configured identity assertion, client/protocol policy	A raw subject or accepted object type does not prove a user login.
Cache operation	Service permissions, storage authorization, application policy	An allowed executable class does not grant a caller a role.
Deserialization/execution	Class and format validation, serializer limits, executable classification, lambda policy	Trusted classes can still execute application code with member process privileges.
Management/observability	Dedicated auth/transport/bind policy, target/operation/resource checks	Cache client security does not automatically cover an administrative listener.
Persistent/imported data	Protected paths, typed metadata, bounds, import validation	Structural checks are not cryptographic authenticity of all stored bytes.

Inventory enabled surfaces

Inventory cluster/federation transport and discovery, NameService, Extend cache and InvocationService proxies, Concurrent proxy/task endpoints, gRPC, REST, management HTTP, metrics, health, JMX/RMI/JMXMP, Memcached, and optional RAG APIs. For each enabled surface record the bind address, reachable networks, TLS/trust source, identity policy, authorization policy, serializer, and verification procedure.

Disable unused listeners. Keep storage and proxy/member roles deliberate. Host allowlists constrain location, and client suspect/bounds policies limit particular malformed or abusive traffic; neither replaces authentication or workload admission. See Enabling General Security Measures and the relevant protocol chapter.

Understanding Security Profiles

Use the security profile to select compatibility-sensitive hardening behavior independently of the Coherence runtime mode.

Coherence has separate settings for runtime mode and security profile. Set these properties before starting Coherence. To change the selected profile, update the startup configuration and restart the affected processes as part of a coordinated deployment.

Table 1-1 Runtime Mode and Security Profile

Property	Purpose	Values and Default
coherence.mode	Selects the runtime and license mode.	eval, dev, or prod. The aliases development and production are also accepted. The default is dev.
coherence.security.mode	Selects the security hardening profile.	compatibility or hardened. When the property is unset, the profile is compatibility.

Compatibility Profile

The compatibility profile preserves prior behavior for compatibility-sensitive checks. Some checks emit bounded warnings or diagnostic counters when an operation would be rejected under the hardened profile. Exercise the application's normal workflows and use those signals to identify configuration or application changes before enabling hardened behavior.

Protections that apply in both profiles, including built-in serialization deny rules and malformed-input checks, remain active. Explicitly configured policies also retain their own enforcement rules.

Hardened Profile

The hardened profile enforces compatibility-sensitive hardening checks. These include serialization allowlisting, remote-executable classification, and finite default serializer container limits. Applications may need generated security configuration, executable declarations, or other configuration changes before their workflows pass these checks.

For example, add the following JVM options before the application main class or -jar argument to select production runtime mode and the hardened security profile:

-Dcoherence.mode=prod
-Dcoherence.security.mode=hardened

To retain the compatibility profile while selecting production runtime mode, use:

-Dcoherence.mode=prod
-Dcoherence.security.mode=compatibility

Setting coherence.mode=prod alone leaves the security profile at its default. Invalid values for either property cause configuration resolution to fail.

Configure the Required Security Controls

Configure TLS, authentication, and authorization for each exposed service according to the deployment's requirements. The hardened profile does not configure TLS or install a storage authorizer, and some service policies require their own explicit settings. Review each service's defaults and overrides.

For an existing deployment, complete the patch or version upgrade using the existing configuration and compatibility profile. Prepare and test application artifacts, credentials, and service policies before a coordinated change to hardened behavior. Include every member and client that participates in the affected workflow.

See Coherence Security Quick Start for the security configuration starting points.

Coherence Security Quick Start

Start securing a Coherence deployment by protecting local resources, configuring transport and identity, authorizing operations, and preparing application security configuration.

Coherence security combines input protections, security-profile defaults, and controls that you configure for individual services. Choose the controls needed for every exposed service and test both permitted access and the requests that should be rejected.

• Protect configuration files, application artifacts, persistence directories, keystores, and credential sources with operating-system permissions. Restrict listener access to the required networks and disable services that the deployment does not use.

• Configure TLS for cluster and external-client communication. Configure trust and identity material, hostname verification, and client certificates where mutual TLS is required. See Using SSL to Secure Cluster Communication, Using SSL to Secure Extend and gRPC Client Communication, and Using SSL Authentication With Oracle Coherence REST.

• Configure authentication and identity validation for the services that clients use. For Extend, configure identity transformers and asserters appropriate to the application's authentication system. See Securing Extend Client Access with Identity Tokens.

• Configure authorization for the operations and resources each identity may access. Use a storage access authorizer where storage-side operation checks are required, and configure any necessary client-service authorization. See Authorizing Access to Server-Side Operations and Implementing Extend Client Authorization.

• Prepare application serialization and remote-execution policy. Include the required generated META-INF/coherence/security-config.xml in each artifact that contributes serialized application types or remote executables. Classify the application objects that execute remotely. Test the workflows that use processors, aggregators, filters, extractors, and remote tasks.

• Prepare the required application and service configuration before starting Coherence. Starting with 26.1.0.0, coherence.security.mode defaults to hardened; coherence.mode=prod remains the independent runtime/license selection. If an existing deployment needs a temporary compatibility phase, explicitly select coherence.security.mode=compatibility before upgrading. See Understanding Security Profiles and Rolling Upgrade to Hardened Security.

Apply the same review to management, metrics, health administration, and optional application endpoints. Configure their authentication, transport, and network exposure explicitly, and verify access from the intended clients and monitoring tools.

Use the deployment recipes in Assembling Secure Deployment Recipes to combine these controls. Before changing an existing deployment, follow Rolling Upgrade to Hardened Security. For the gRPC client path, see Securing gRPC Client Connections.

Overview of Security Configuration

Place security configuration in the owning descriptor or artifact and verify its effective value on each process.

Coherence security settings belong to several configuration sources. A setting in the wrong descriptor, a resource absent from the receiving classpath, or an overridden default can leave a deployment behaving differently from the intended policy.

Source	Responsibility
Operational override	Member/network/socket providers, password providers, security framework, identity transformer/asserter, storage-authorizer declarations, peer-provider configuration.
Cache configuration	Cache mappings and schemes, backing-map authorizer references, proxy acceptors, remote initiators/channels, serializers and service-local limits.
META-INF/coherence/security-config.xml	Per-artifact allowed application classes, executable classes, and lambda-target classification. All visible resources are validated and merged.
POF configuration	Supported type IDs and serializers for application/product values; explicit compatibility choices.
REST configuration	Published resources, named/direct queries, expression aliases, marshallers, and approved aggregator/processor registrations.
JAAS configuration	Named login-module entries, provider options, and the credential validation contract.
Credentials and trust sources	Private keys, certificates, trust anchors, password-provider material, and component-specific API credentials.

Select coherence.override and coherence.cacheconfig deliberately for each process. Review system-property-backed XML defaults and explicit overrides. Do not assume a property's documented shipped default applies after an application supplies its own configuration without the shipped marker.

Generate application security resources during the build and verify the JAR actually deployed. Keep configuration, code, native binaries, and credentials consistent across the relevant clients and members. Use Security Configuration Reference and the owning feature's precedence rules rather than applying one global override rule to every feature.