Managing Gated Security Features

Determining the Security Behavior

Use WebLogic Remote Console or WLST to set a feature gate and change the security behavior.

FeatureCompatibilityMBean provides configurable Boolean gates and numeric limits. For a configurable Boolean gate, true enables the protection and false selects the documented compatibility behavior. Numeric limits, including SerializedWorkContextMaximumSize and WorkContextInputMaximumASCIIFieldSize, use the values and special cases described in their individual topics.

In WebLogic Server 26.1.0.0.0 and later, StrictReplicationAuthorizationEnabled and StrictClusterCompatibilityEnabled are deprecated, always enabled, and cannot be configured.

Some feature gates require additional configuration on other MBeans to fully implement the new behavior. In these cases, the FeatureCompatibility attribute enables the feature but the attributes on another MBean determine the actual behavior.

To set a feature gate using WebLogic Remote Console, see Setting Security Feature Gates in Oracle WebLogic Remote Console Online Help.

For examples on how to use WLST to change a feature gate, see Example 5-1 and Example 5-2.

Example 5-1 demonstrates how to configure WebLogic Server so that it can only create a new route to a trusted destination that it already knows or that has been identified through local WebLogic Server configuration. See T3RouteOnlyToTrustedServersEnabled for more information.

Example 5-1 Configure FeatureCompatibilityMBean.T3RouteOnlyToTrustedServersEnabled

connect('username', 'password', 'adminServerURL')
edit()
startEdit()
cmo.getFeatureCompatibility().setT3RouteOnlyToTrustedServersEnabled(True)
save()
activate(block='true')
disconnect()

Example 5-2 demonstrates how to set WebLogic Server to limit server-side JNDI factories to only use the built-in factories and factories explicitly listed in the corresponding allowlists. See JNDIAdditionalFactoriesAllowListsEnabled for more information.

Example 5-2 Configure FeatureCompatibilityMBean.JNDIAdditionalFactoriesAllowListsEnabled and its associated allowlists

connect('username', 'password', 'adminServerURL')
edit()
startEdit()

cmo.getFeatureCompatibility().setJNDIAdditionalFactoriesAllowListsEnabled(True)

cmo.getSecurityConfiguration().setJNDIAdditionalInitialContextFactoriesAllowed('com.example.MyInitialContextFactory,com.example.FactoryOne')
cmo.getSecurityConfiguration().setJNDIAdditionalReferenceFactoriesAllowed('com.example.MyReferenceFactory,com.example.FactoryTwo')

save()
activate(block='true')
disconnect()

Handling Security Hardening Changes

Learn how to identify potential obstacles and develop strategies to mitigate or rectify them so your environment remains up-to-date and secure.

General Guidance

Identify the failing protocol and operation. Read the complete exception on the side receiving the request or response, and distinguish among a policy rejection, authentication failure, or missing client class.
Confirm the effective MBean value on the installed WebLogic Server release and build. Settings may be absent or have different default values in different releases.
Check whether the value is application-supplied or already declared in trusted deployment configuration.
Try a targeted application, classpath, script-location, or configuration correction first, then rerun the affected integration with secure default values enabled.
If a temporary compatibility setting is necessary, change one control at a time in the affected domain and record its original value.
Test the affected integration, including any EJB or transaction flow, and restore the stronger setting once the legacy dependency is removed.

Here are some possible scenarios that may occur as a result of the secure by default approach:

Custom WorkContext Is Rejected

Aspect	Details
Issue	An application-defined WorkContext class is rejected when EJB or transaction data crosses a server boundary.
Symptoms	The process reading the data reports `InvalidClassException` or "WorkContext implementation is not allowed." The remote call may fail before the business method runs.
Recommended solution	Identify the rejected class in the complete exception. Move the required value to a supported built-in WorkContext type, such as a string, ASCII, or long context, where possible.
Example	An application propagates a custom tracing object with an EJB call. The receiving server rejects that class. The application instead propagates the trace identifier as a built-in string context.
Temporary compatibility option	If the custom class cannot yet be migrated, setting `FeatureCompatibilityMBean.WorkContextClassValidationEnabled=false` restores legacy class handling on the affected domain and reduces inbound validation. Other deserialization checks still apply.
Affected area	EJB and transaction integrations

Cross-Domain Transaction Peer Is Not Trusted

Aspect	Details
Issue	A legacy credential-signed T3 identity does not establish trusted-server status.
Symptoms	A cross-domain EJB call, transaction coordination, or XA recovery operation fails after the domains connect.
Recommended solution	Verify server identity, cross-domain credentials, and trust configuration on both domains. Use an authenticated peer relationship and distinguish this failure from a WorkContext rejection.
Example	Domain A can connect to Domain B, but B rejects A's legacy server identity during a distributed transaction. Administrators correct the cross-domain trust configuration before retrying.
Temporary compatibility option	If migration from legacy global-domain trust is still in progress, `FeatureCompatibilityMBean.T3LegacyCrossDomainCredentialJVMIDReplayProtectionEnabled=false` restores that legacy behavior on the affected domain and weakens replay protection.
Affected area	EJB and transaction integrations

Cross-Domain JMS Migration Uses Anonymous T3

Aspect	Details
Issue	A JMS or JNDI workflow calls another domain without an accepted identity.
Symptoms	The receiving server logs `BEA-000582` or "Anonymous RMI access not allowed."
Recommended solution	Configure a service identity for the remote JNDI and transaction calls when the integration supports authenticated access. Verify that the identity reaches the receiving domain.
Example	A migration service in Domain A looks up a JMS destination in Domain B without credentials. Configuring credentials for the remote lookup removes the anonymous-call dependency.
Temporary compatibility option	When the legacy workflow intentionally requires anonymous T3, `SecurityConfigurationMBean.RemoteAnonymousRMIT3Enabled=true` permits anonymous T3 RMI across the domain. Assess this broader permission before enabling it.
Affected area	EJB and transaction integrations

Foreign JNDI or Foreign JMS Lookup Is Denied

Aspect	Details
Issue	A server-side JNDI lookup needs an outbound destination that does not match the active policy or configured provider.
Symptoms	An EJB or MDB cannot resolve a foreign connection factory, destination, or JNDI link. A `NamingException` may identify a rejected provider URL or URL-shaped name.
Recommended solution	Verify the Foreign JNDI or Foreign JMS provider, URL, credentials, and every failover host. Where an allowlist entry is required, add only the needed scheme and host to `SecurityConfigurationMBean.JNDIOutboundConnectionsAllowed` while keeping `FeatureCompatibilityMBean.JNDIOutboundConnectionsAllowListEnabled=true`. Check the exact hostname used by the application; DNS aliases may not match an entry for a different name.
Example	An MDB uses `t3://jms-a.example.com:7001` and can fail over to `jms-b.example.com`. The administrator checks both provider hostnames and permits only the required destinations.
Affected area	EJB and transaction integrations

EJB Application Cannot Change a JNDI Binding

Aspect	Details
Issue	The effective caller does not meet the authorization requirements for a server-side JNDI write.
Symptoms	`bind`, `rebind`, `unbind`, or `rename` fails while `lookup` still succeeds.
Recommended solution	Identify the caller and the JNDI name being changed. Prefer a binding created through application deployment. If a runtime write is required, use an identity with the required WebLogic Server role and permission for that specific name.
Example	EJB startup code can read `services/Orders` but cannot replace its binding. The application moves that binding into deployment configuration.
Temporary compatibility option	`FeatureCompatibilityMBean.JNDIBindingAuthorizationPolicyEnabled=false` removes the additional role check and restores legacy policy behavior. Existing per-name policies and anonymous-user restrictions still apply.
Affected area	EJB and transaction integrations

EJB Client T3 Call Is Denied as Anonymous

Aspect	Details
Issue	A remote EJB client makes a T3 call without an identity accepted by the receiving server.
Symptoms	The receiving server logs `BEA-000582` or "Anonymous RMI access not allowed," and the client invocation fails.
Recommended solution	Supply valid credentials for the client's JNDI/RMI connection and verify which identity reaches the server. Check the client connection setup before changing server policy.
Example	A standalone client looks up and invokes an EJB over T3 without credentials. The client is configured with a service identity that the server can authenticate.
Temporary compatibility option	If anonymous calls are an intentional legacy requirement, assess the domain-wide effect of `SecurityConfigurationMBean.RemoteAnonymousRMIT3Enabled=true` before enabling it.
Affected area	EJB client behavior

EJB Client Cannot Deserialize an IIOP Proxy

Aspect	Details
Issue	A serialized IIOP wrapper is incompatible with the declared wire type before `readResolve()` runs.
Symptoms	The client or receiving server fails during proxy unmarshalling, before the EJB business method is invoked.
Recommended solution	Verify the client's supported WebLogic Server version, its remote interfaces and value types, and the deployed EJB contract. Update an incompatible client or serialized wrapper.
Example	An older client expects one remote interface but receives a wrapper that resolves to a different proxy type. It is rebuilt against the deployed remote contract.
Temporary compatibility option	`FeatureCompatibilityMBean.IIOPTypedReadResolveProxyValidationEnabled=false` preserves legacy typed-proxy behavior on the affected domain while the client is migrated.
Affected area	EJB client behavior

EJB Client Remote Interface Is Rejected

Aspect	Details
Issue	A client presents a plain business interface that the server does not recognize as a remote interface.
Symptoms	IIOP stub creation or remote invocation fails.
Recommended solution	Use a supported remote business interface in the EJB deployment and client, then regenerate or update the client artifacts.
Example	A client uses a local-only business interface for a cross-domain EJB call. The application exposes and uses a remote interface instead.
Temporary compatibility option	For a legacy client whose IOR has no codebase, `FeatureCompatibilityMBean.IIOPStrictRemoteBusinessInterfaceValidationEnabled=false` can temporarily preserve the older interface behavior.
Affected area	EJB client behavior

EJB Client Cannot Load a Response Class

Aspect	Details
Issue	The client does not have a class needed to read a response or application exception. This is a client packaging problem, even if it appears after a security change.
Symptoms	`ClassNotFoundException` or `NoClassDefFoundError` occurs while unmarshalling a response. The server may already have reached the EJB.
Recommended solution	Place the matching remote interface, value classes, and application exception classes on the client classpath. Keep the client API JAR aligned with the deployed EJB version.
Example	A remote EJB returns an application exception, but the client lacks that exception class and fails while reading the response.
Affected area	EJB client behavior

An Application Still Needs IIOP or CORBA Naming

Aspect	Details
Issue	IIOP support is disabled by default for servers and server templates in a new 26.1.0.0.0 domain. A non-EJB application may still use IIOP, CORBA naming, or a remote service reached through an IIOP URL.
Symptoms	The application cannot connect to or resolve the intended IIOP service. Check the server's effective IIOP setting and the exact protocol in the client URL before attributing a lookup failure to the JNDI allowlist.
Recommended solution	Explicitly enable IIOP only on the domain, servers, or server templates that need it. Review the separate outbound JNDI policy if server-side code then looks up an external IIOP name.
Example	A server-side integration uses `iiop://partner.example.com` for naming. The administrator enables IIOP on the participating WebLogic Server instance and separately checks whether that external lookup needs a scoped outbound entry.
Affected area	Protocol and naming integrations

A Direct Server-Side External JNDI Lookup Is Denied

Aspect	Details
Issue	Application code constructs a provider URL or URL-shaped name and asks WebLogic Server to perform an outbound lookup. The enabled outbound JNDI policy checks that destination.
Symptoms	A `NamingException` identifies an invalid or disallowed provider URL or lookup name, even though the remote naming service is reachable.
Recommended solution	Identify the actual lookup scheme and host, including any failover peers or aliases. Where required, allow only those destinations through `SecurityConfigurationMBean.JNDIOutboundConnectionsAllowed`. Retain `FeatureCompatibilityMBean.JNDIOutboundConnectionsAllowListEnabled=true`. Confirm that the application is making a direct lookup rather than resolving a provider already declared in trusted deployment configuration.
Example	A server-side naming application directly queries a GlassFish IIOP host and an opaque `corbaname:` URL. Its test domain permits that host and scheme rather than opening outbound naming generally.
Affected area	Protocol and naming integrations

A SOAP/JMS Application Uses a Custom JNDI Initial-Context Factory

Aspect	Details
Issue	The application supplies an initial-context factory class that is outside WebLogic's built-in set. The additional-factory policy is enabled by default.
Symptoms	JNDI context creation or a SOAP/JMS lookup fails with a factory-policy rejection. Check the factory class named in the exception; a provider-URL rejection is a separate check.
Recommended solution	Use a built-in supported factory when possible. If the integration requires a custom one, add its exact class name to `SecurityConfigurationMBean.JNDIAdditionalInitialContextFactoriesAllowed`. Review the provider URL separately and keep the additional-factory gate enabled.
Example	A SOAP/JMS integration uses `com.example.jms.MyInitialContextFactory`. The administrator permits that one class rather than disabling factory validation for the domain.
Affected area	Protocol and naming integrations

A Web Application Propagates WorkContext to a Work Manager

Aspect	Details
Issue	A custom WorkContext implementation propagated through web requests or asynchronous work can be rejected by strict class validation.
Symptoms	The receiving path reports an `InvalidClassException` or a WorkContext class-validation error; a task may run without the expected contextual value.
Recommended solution	For simple values, use a supported built-in WorkContext type. If a serialized application object is essential, review the specific payload and serialization filter. See Custom WorkContext is Rejected for the separate remote-call case.
Example	A servlet needs to pass a trace identifier to asynchronous work. It propagates the identifier as a built-in string context rather than a custom WorkContext class.
Affected area	Application data and diagnostics

A WLDF Watch Invokes a Script Outside the Permitted Directory

Aspect	Details
Issue	With the script-action path restriction enabled, the script path must resolve beneath `DOMAIN_HOME/bin/scripts`.
Symptoms	The watch action reports an invalid script path or a message that the script must be located underneath the domain directory; the intended action does not run.
Recommended solution	Place the script under `DOMAIN_HOME/bin/scripts` and update the WLDF action path. Check the resolved path, including symbolic links, for each domain that executes the action.
Example	A watch calls `/opt/app/alerts/notify.sh`. The administrator places the approved script under `DOMAIN_HOME/bin/scripts/alerts/notify.sh` and points the action there.
Affected area	Application data and diagnostics

An Unset Feature Compatibility Value Is Still Enabled

Aspect	Details
Issue	Several `FeatureCompatibilityMBean` checks are enabled by default in 26.1.0.0.0. A domain configuration file may contain no explicit entry for a gate even though the gate is active.
Symptoms	A migration review treats an absent `FeatureCompatibility` element as an opt-out, but runtime behavior or WLST readback shows the protection enabled.
Recommended solution	Check the effective MBean value on the installed release, not just whether an override is present in `config.xml`. Inventory explicit legacy overrides separately from inherited defaults.
Example	A freshly generated domain has no explicit `WorkContextClassValidationEnabled` setting. Its effective value is still enabled under the 26.1.0.0.0 default.
Affected area	Configuration interpretation and product corrections

A Deployment Configured Foreign Provider Needs No Duplicate Exception

Aspect	Details
Issue	Outbound JNDI restrictions can reject Foreign JMS or Foreign JNDI providers even when they are already specified in trusted deployment configuration, leading administrators to add unnecessary allowlist entries.
Symptoms	Unpatched releases can report a rejected provider URL or initial-context factory while resolving a deployed foreign reference.
Recommended solution	Use a release containing the product correction and verify that the provider and factory are explicitly configured in the deployment. Do not add a duplicate allowlist entry solely for this case. Ordinary application-supplied URLs and factories remain subject to outbound policy.
Example	A deployed Foreign JMS resource declares its provider URL and factory. On the corrected product, WebLogic Server authorizes the exact configured values while unrelated direct lookups remain restricted.
Affected area	Configuration interpretation and product corrections

JNDIAdditionalFactoriesAllowListsEnabled

The FeatureCompatibilityMBean.JNDIAdditionalFactoriesAllowListsEnabled feature gate controls the enhanced validation of JNDI initial context and reference factories, using the corresponding allowlist settings in the SecurityConfigurationMBean.

Note:

If you do not see this feature gate, confirm that you have applied the latest available Patch Set Update (PSU) or Critical Security Patch Update (CSPU). Security fixes and their feature gates are delivered on an as-needed basis through PSUs and CSPUs to ensure that your system is protected against vulnerabilities. To determine when this feature gate was delivered, see Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

JNDI uses factory classes to create naming contexts and convert stored descriptions into usable Java objects.

For example:

An initial context factory creates the context used to contact a JNDI provider.
An object or reference factory converts a stored JNDI Reference into an object such as a data source, connection factory, or service proxy.
A state factory converts an application object into the form stored during bind or rebind.

FeatureCompatibilityMBean.JNDIAdditionalFactoriesAllowListsEnabled controls whether WebLogic Server limits these server-side JNDI factories to built-in factories and factories explicitly listed in the SecurityConfigurationMBean.JNDIAdditionalInitialContextFactoriesAllowed and SecurityConfigurationMBean.JNDIAdditionalReferenceFactoriesAllowed attributes.

The SecurityConfigurationMBean.JNDIAdditionalInitialContextFactoriesAllowed lists permitted InitialContextFactory implementation classes while the SecurityConfigurationMBean.JNDIAdditionalReferenceFactoriesAllowed lists permitted reference, object, and state factory classes.

WebLogic Server has a built-in set of factories that remain permitted when FeatureCompatibilityMBean.JNDIAdditionalFactoriesAllowListsEnabled is enabled. The SecurityConfigurationMBean attributes add customer or third-party classes to those built-in sets.

When FeatureCompatibilityMBean.JNDIAdditionalFactoriesAllowListsEnabled is set to true, the covered WebLogic Server JNDI paths validate a factory before permitting JNDI to use it.

The initial context check applies to caller-supplied environments. WebLogic Server separately preserves the exact initial context factory and provider URL taken from trusted deployment or server configuration by carrying internal proof of their configured origin. That proof authorizes only the exact configured pair. It does not authorize a substituted factory, a caller-supplied environment, an object or state factory supplied later, or a Reference returned by the provider; those values remain subject to the applicable factory checks.

A factory is permitted when either:

It is in the applicable WebLogic Server built-in list.
Its fully qualified class name appears in the applicable SecurityConfigurationMBean attribute.
The applicable SecurityConfigurationMBean attribute contains the reserved value *.

For example:

com.example.naming.CompanyInitialContextFactory

can be added to:

JNDIAdditionalInitialContextFactoriesAllowed

A custom reference factory such as:

com.example.naming.CompanyObjectFactory

must instead be added to:

JNDIAdditionalReferenceFactoriesAllowed

Passing the allowlist check does not guarantee that the factory will work. The class must still be available to the appropriate class loader, implement the required JNDI interface, and operate correctly with the supplied environment or reference.

When FeatureCompatibilityMBean.JNDIAdditionalFactoriesAllowListsEnabled is set to false, the SecurityConfigurationMBean.JNDIAdditionalInitialContextFactoriesAllowed and SecurityConfigurationMBean.JNDIAdditionalReferenceFactoriesAllowed attributes are not enforced. Initial context factory behavior continues to use the built-in compatibility list and any configuration supplied through:

wls.jndi.jndiAllowedFactories
wls.jndi.jndiAllowAllFactories

The new reference, object, and state factory checks are not applied when the feature is disabled. Other JNDI validation and normal class-loading requirements remain in effect.

Property	Value
Type	Boolean
Default	`true`
Dynamic	Yes

All three attributes are dynamic so you can change their values without restarting the server. Subsequent JNDI operations use the updated configuration after the change is activated.

Potential Impacts

This attribute applies to server-side WebLogic JNDI operations that:

Create a JNDI context using a caller-supplied initial context factory
Bind or rebind an object using a configured state factory
Bind, rebind, or retrieve a JNDI Reference
Retrieve an object implementing Referenceable
Materialize an existing reference during lookup
Use factories listed in Context.OBJECT_FACTORIES
Use factories listed in Context.STATE_FACTORIES
Continue a federated JNDI lookup through a reference
Resolve references, object factories, or state factories returned through Foreign JNDI or Foreign JMS configurations; the exact configured initial context factory itself is separately authorized

It does not directly control:

The destination URL contacted by an allowed factory
Authorization to bind or unbind a JNDI name
Ordinary Java object construction outside JNDI
JDBC driver loading that does not occur through JNDI
Application code that calls a factory class directly

Outbound provider destinations are controlled separately by JNDIOutboundConnectionsAllowListEnabled. Namespace changes are controlled separately by JNDIBindingAuthorizationPolicyEnabled.

An application or integration is more likely to be affected if it uses:

A third-party InitialContextFactory
An LDAP factory not included in the built-in list
A custom Reference or Referenceable implementation
A resource adapter that stores custom JNDI references
A third-party data source or connection-pool object factory
A framework that sets Context.OBJECT_FACTORIES
A framework that sets Context.STATE_FACTORIES
A caller-supplied JNDI environment using a non-built-in initial context factory
A Foreign JNDI or Foreign JMS object that returns a reference using a vendor-specific object factory
A reference whose factory class location is nonempty
An existing JNDI binding whose custom factory runs only during lookup

Applications that use only standard WebLogic Server JNDI factories generally should not require additional configuration.

An unlisted initial context factory can cause:

Failure to create an InitialContext
Failure to resolve a factory supplied by or returned through a Foreign JNDI Provider
Failure to resolve a factory supplied by or returned through a Foreign JMS resource
Application startup or deployment failure

An unlisted state factory can cause:

bind or rebind to fail
A resource registration to be omitted
A later lookup to fail because the expected name was never registered

An unlisted reference or object factory can cause:

Lookup of an existing binding to fail
A Reference to be returned or rejected instead of being converted into the expected object
A data source, connection factory, service proxy, or other resource to be unavailable
An application to fail only when it first uses a lazily resolved resource

Mitigate the Effects of the Enabled Setting

Inventory server-side JNDI environments that specify Context.INITIAL_CONTEXT_FACTORY.
Inventory custom Reference and Referenceable classes.
Search application and framework configuration for java.naming.factory.object and java.naming.factory.state.
Review caller-supplied JNDI environments and the references, object factories, and state factories that Foreign JNDI Provider and Foreign JMS operations can return or use beyond their exact configured initial context factory.
Identify references that specify an external factory class location.
Classify each required factory as an initial context factory or a reference/object/state factory.
Populate the appropriate SecurityConfigurationMBean attribute while the feature gate is still false.
Use exact fully qualified class names.
Migrate required entries from the legacy factory properties.
Enable JNDIAdditionalFactoriesAllowListsEnabled.
Test initial context creation, new binds and rebinds, and lookup of existing reference-based objects.

Test both the creation of new bindings and the lookup of bindings that already exist. The two operations exercise different factory categories and can fail independently.

Use * only as a controlled diagnostic or when all factory classes are intentionally permitted. It does not permit a nonempty reference factory class location.

Troubleshooting Issues

An initial context factory rejection produces a NamingException containing:

JNDI environment is invalid. Please check if the JNDI Factory specified
is valid. If it's valid factory, configure
SecurityConfigurationMBean.JNDIAdditionalInitialContextFactoriesAllowed.

A reference factory rejection contains:

JNDI Reference factory class '<factory-class>' is not permitted.
Configure SecurityConfigurationMBean.JNDIAdditionalReferenceFactoriesAllowed
to allow additional factories.

An object factory rejection contains:

JNDI object factory '<factory-class>' is not permitted.
Configure SecurityConfigurationMBean.JNDIAdditionalReferenceFactoriesAllowed
to allow additional factories.

A state factory rejection contains:

JNDI state factory '<factory-class>' is not permitted.
Configure SecurityConfigurationMBean.JNDIAdditionalReferenceFactoriesAllowed
to allow additional factories.

WebLogic Server also logs BEA-050009 when it rejects a reference, object, or state factory class:

Rejected JNDI Reference factory class "<factory-class>" because it is
not on the allowlist. Codebase: <location>

WebLogic Server suppresses repeated BEA-050009 messages for the same rejected factory-class name during the server process lifetime. Therefore, the absence of a repeated message does not prove that a later operation succeeded.

If FeatureCompatibilityMBean.JNDIAdditionalFactoriesAllowListsEnabled is set to true while either of the legacy properties (wls.jndi.jndiAllowedFactories or wls.jndi.jndiAllowAllFactories) are set, WebLogic Server logs BEA-050010, explaining that the MBean configuration takes precedence and the legacy properties are ignored.

A factory named in wls.jndi.jndiAllowedFactories does not automatically appear in either new MBean list. Add it to the appropriate SecurityConfigurationMBean attribute before enabling the feature.

To determine whether the attribute caused the issue, perform the following steps:

Confirm the live runtime value of JNDIAdditionalFactoriesAllowListsEnabled.
Identify the factory class named in the NamingException or BEA-050009 message.
Determine which kind of factory it is:
- Initial context factory
- Reference or object factory
- State factory
Read the live value of the corresponding SecurityConfigurationMBean attribute.
Compare the complete, case-sensitive class name with the built-in and configured entries.
If the factory came from Context.OBJECT_FACTORIES or Context.STATE_FACTORIES, inspect every class in the colon-separated environment value.
If the rejected object is a Reference, check whether it contains a nonempty factory class location.
Determine whether the failure occurred during context creation, bind or rebind, or lookup.
Check the server log for BEA-050009 and BEA-050010.
Temporarily enable JNDI debug output, including DebugJNDI, to inspect the effective feature and allowlist values.

Because the feature gate and related SecurityConfigurationMBean attributes are dynamic, add the exact required class to the appropriate list in a controlled environment and repeat the same operation.

If the operation succeeds after adding the exact class, the factory allowlist caused the original failure.

If JNDIAdditionalReferenceFactoriesAllowed=* still does not permit a Reference, check its factory class location. A non-empty location is rejected regardless of *.

Distinguishing related JNDI failures

The JNDI compatibility switches are independent:

A message naming JNDIAdditionalInitialContextFactoriesAllowed concerns an initial context factory.
A message naming JNDIAdditionalReferenceFactoriesAllowed concerns a reference, object, or state factory.
A message naming JNDIOutboundConnectionsAllowed concerns the destination URL.
A NoPermissionException for bind, rebind, or another namespace change concerns binding authorization or an existing JNDI resource policy.

Checks can occur in sequence. For example, when a caller-supplied remote JNDI environment uses both a custom initial context factory and a remote provider URL:

The initial context factory must be permitted.
The provider URL must be permitted by the outbound connection allowlist.

Correcting the factory list can therefore expose a separate URL rejection on the next attempt.

For a bind or rebind operation, an authorization failure can occur before state or reference factory validation. Resolve the first reported failure and then repeat the complete operation.

Configuring JNDIAdditionalInitialContextFactoriesAllowed and JNDIAdditionalReferenceFactoriesAllowed

Configure the SecurityConfigurationMBean.JNDIAdditionalInitialContextFactoriesAllowed and SecurityConfigurationMBean.JNDIAdditionalReferenceFactoriesAllowed attributes using a comma-separated list of fully qualified class names.

Note:

The SecurityConfigurationMBean.JNDIAdditionalInitialContextFactoriesAllowed and SecurityConfigurationMBean.JNDIAdditionalReferenceFactoriesAllowed attributes were introduced in the August 2026 Critical Security Patch Update (CSPU). See Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

For example:

com.example.naming.CompanyInitialContextFactory,com.vendor.naming.VendorInitialContextFactory

Class names are matched exactly and are case-sensitive.

Package wildcards are not supported. For example, this is not valid:

com.example.naming.*

The reserved value * allows all factory class names for that category and must be the only configured entry. It cannot be combined with explicit class names.

An empty value means that no additional customer or third-party factories are permitted. Built-in factories remain permitted.

Built-in Initial Context Factories

When the feature is enabled, the following initial context factories are permitted without being added to JNDIAdditionalInitialContextFactoriesAllowed:

weblogic.jndi.WLInitialContextFactory
weblogic.jms.WLInitialContextFactory
weblogic.jndi.T3InitialContextFactory
weblogic.jndi.TengahInitialContextFactory
oracle.jakarta.jms.AQjmsInitialContextFactory

The two weblogic.jndi aliases preserve compatibility with existing WebLogic JNDI configurations. The Oracle AQ JMS factory supports the corresponding Oracle AQ integration.

A different caller-supplied factory, such as an LDAP or third-party naming-provider factory, must be added explicitly when the feature is enabled. The exact initial context factory/provider pair taken from trusted deployment or server configuration is separately authorized and does not need an entry solely for that configured use.

Built-in Reference, Object, and State factories

The following factory classes are permitted without being added to JNDIAdditionalReferenceFactoriesAllowed. WebLogic Server uses this same built-in list when validating a factory named by a Reference, an object factory supplied through Context.OBJECT_FACTORIES, or a state factory supplied through Context.STATE_FACTORIES:

kodo.ee.KodoObjectFactory
oracle.j2ee.ws.common.naming.ServiceReferenceResolver
org.apache.wsif.naming.WSIFServiceObjectFactory
weblogic.application.naming.MessageDestinationObjectFactory
weblogic.application.naming.URLObjectFactory
weblogic.application.naming.URLReference$URLObjectFactory
weblogic.jdbc.common.internal.UCPDataSourceManager
weblogic.cacheprovider.coherence.jndi.CoherenceObjectFactory
weblogic.connector.deploy.JNDIHandler
weblogic.connector.deploy.TransportableJNDIHandler
weblogic.corba.application.binding.ORBObjectFactory
weblogic.corba.j2ee.naming.url.corbaname.corbanameURLContextFactory
weblogic.deployment.JmsPooledConnectionObjectFactory
weblogic.deployment.MailSessionObjectFactory
weblogic.jms.application.bindings.PooledDefaultJMSConnectionFactoryObjectFactory
weblogic.j2eeclient.java.javaURLContextFactory
weblogic.jndi.factories.domain.domainURLContextFactory
weblogic.jndi.factories.http.httpURLContextFactory
weblogic.jndi.factories.https.httpsURLContextFactory
weblogic.jndi.factories.java.javaURLContextFactory
weblogic.jndi.factories.partition.partitionURLContextFactory
weblogic.jndi.factories.sharable.sharableURLContextFactory
weblogic.jndi.factories.t3.t3URLContextFactory
weblogic.jndi.internal.BuiltinTransportableObjectFactory
weblogic.management.mbeanservers.partition.PartitionedDomainRuntimeMbsRefObjFactory
weblogic.management.mbeanservers.partition.PartitionedEditMbsRefObjFactory
weblogic.management.mbeanservers.partition.PartitionedMbsRefObjFactory
weblogic.management.mbeanservers.partition.PartitionedRuntimeMbsRefObjFactory
weblogic.persistence.PersistenceManagerFactoryObjectFactory
weblogic.persistence.PersistenceManagerObjectFactory

Object and State Factory Lists in a JNDI Environment

The standard JNDI environment properties for object and state factories can contain multiple class names separated by colons.

For example:

com.example.FirstObjectFactory:com.example.SecondObjectFactory

When the feature is enabled, every nonempty factory class in that environment value must be permitted. The operation is rejected if even one entry is not built in or included in JNDIAdditionalReferenceFactoriesAllowed.

The MBean attribute itself remains comma-separated. The colon separator applies only to the JNDI environment properties.

Reference Factory Class Locations

A JNDI Reference can contain both:

A factory class name
A factory class location, sometimes called a codebase

When this feature is enabled, WebLogic Server rejects a Reference that specifies a nonempty factory class location. This remains true even when:

JNDIAdditionalReferenceFactoriesAllowed=*

The factory class must already be available through the server or application class-loading environment. Adding the class name to the allowlist does not permit WebLogic Server to obtain the factory from a location specified by the Reference.

When validation occurs

The point of validation depends on the factory type.

Factory Type	Validation Point
Initial context factory	Before WebLogic Server creates the JNDI context
State factory	During `bind` or `rebind`, before the factory converts the object for storage
Reference factory named by a `Reference`	When the reference is accepted or materialized
Object factory from `Context.OBJECT_FACTORIES`	Before the object factory is used during lookup
Factory on an existing binding	When an application looks up and materializes that binding

This means that an existing binding created before the feature was enabled can remain in the JNDI tree but fail when an application later looks it up.

Similarly, an application can deploy successfully and fail only when it first creates a remote context or retrieves a lazily materialized resource.

JNDIBindingAuthorizationPolicyEnabled

The FeatureCompatibilityMBean.JNDIBindingAuthorizationPolicyEnabled feature gate enables binding-origin protection and tightened authorization for JNDI namespace modifications, including T3 and IIOP CosNaming operations.

Note:

If you do not see this feature gate, confirm that you have applied the latest available Patch Set Update (PSU) or Critical Security Patch Update (CSPU). Security fixes and their feature gates are delivered on an as-needed basis through PSUs and CSPUs to ensure that your system is protected against vulnerabilities. To determine when this feature gate was delivered, see Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

WebLogic Server's JNDI namespace is a directory of names and the objects or services associated with those names. Applications commonly use JNDI to find data sources, JMS resources, EJBs, and other server-managed objects.

When enabled, JNDIBindingAuthorizationPolicyEnabled distinguishes bindings installed by WebLogic Server or trusted local server code from bindings created through a naming client. An ordinary naming client can create and manage a client-origin binding when the applicable JNDI resource policy permits the operation, but it cannot replace, remove, shadow, or rename a protected server-origin binding.

This protection applies to namespace-changing operations such as bind, rebind, unbind, rename, and subcontext operations. It does not itself change read operations such as lookup and list; their existing JNDI resource policies still apply.

A caller in the WebLogic Admin, Deployer, or Operator security role, or the kernel identity, is not treated as an ordinary naming client for binding-origin protection. This does not bypass the JNDI resource policy for the affected name. A privileged caller can still be denied by that policy.

When the attribute is false, WebLogic Server preserves the legacy mutation and protocol behavior. Existing per-name JNDI authorization policies, remote-anonymous-user restrictions, naming rules, and transport authorization remain in effect.

Property	Value
Type	Boolean
Default	`true`
Dynamic	Yes
Primary area	Authorization of server-side JNDI namespace changes

Because the attribute is dynamic, a server restart is not required. A naming call snapshots the gate when the call begins, so an activated change applies to subsequently admitted calls rather than changing the policy in the middle of an in-progress call.

Potential Impacts

The FeatureCompatibilityMBean.JNDIBindingAuthorizationPolicyEnabled attribute affects JNDI namespace modification operations such as:

bind
rebind
unbind
rename
createSubcontext
destroySubcontext
IIOP CosNaming bind, rebind, unbind, and context-creation operations
WebLogic CosNaming bind_any and rebind_any
Changes to global, partition-scoped, and sharable JNDI namespaces

It does not change the binding-origin classification of:

lookup
list
Normal use of an object that has already been obtained from JNDI
Standard application resources installed by WebLogic Server from deployment metadata; these remain server-origin bindings
Internal WebLogic Server registrations and other trusted local server installations; these remain server-origin bindings

An ordinary authenticated naming client is not categorically barred from namespace changes: it can create, rebind, and remove client-origin bindings when the applicable modify policy permits those operations. A lookup can still fail for other reasons, including an existing JNDI resource policy, a missing name, an outbound-connection restriction, or a JNDI factory restriction.

Binding-Origin Protection

WebLogic Server records whether a binding was installed by the server or created through a naming client. The classification follows the binding across protected namespace operations and clustered replication.

An ordinary naming client can create a new client-origin binding and later rebind or remove it, subject to the applicable JNDI modify policy. If trusted local server code later replaces that slot with a server-origin binding, an ordinary naming client can no longer replace or remove it. After the server-origin binding is removed by an authorized server or privileged operation, a client can create a new client-origin binding at that name.

A caller's administrative role does not turn a newly created client binding into a server-origin binding. Binding origin describes how the binding was installed, not which user created it. The role affects whether the client is subject to origin protection; the per-name JNDI policy remains authoritative for the requested operation.

Sharable Namespace Changes

WebLogic Server has a sharable namespace used by server services and certain cross-partition or replicated facilities. Binding-origin protection and the applicable JNDI resource policy also apply to mutations routed through that namespace.

An ordinary client cannot modify a protected server-origin entry merely by reaching it through a sharable or alternate naming path. Administrative roles do not bypass the applicable per-name policy. Ordinary applications should not normally set the internal weblogic.jndi.createUnderSharable option.

IIOP CosNaming Behavior

The policy also applies when a CORBA client changes the WebLogic Server naming namespace through IIOP CosNaming.

WebLogic Server preserves the original IIOP caller and applies the same binding-origin and per-name policy checks before performing operations such as:

bind
rebind
unbind
bind_new_context
bind_any
rebind_any

An unauthorized CORBA caller generally receives a CORBA NO_PERMISSION exception derived from the WebLogic JNDI authorization failure.

CosNaming resolve and list are read operations and are not subject to this attribute's binding-origin protection. Existing lookup and list policies still apply.

An application or administrative utility is more likely to be affected if it:

Connects remotely and registers objects using bind or rebind
Removes registrations using unbind
Renames bindings
Creates or destroys JNDI subcontexts
Attempts to replace or remove a binding that was installed by deployment or other trusted local server code
Uses CORBA CosNaming to register objects in WebLogic Server
Uses a retained naming context whose local policy attachment or binding target has been removed or replaced
Depends on legacy alias, rename, or subcontext behavior that did not preserve the canonical binding origin
Attempts to write to the sharable namespace

Common examples include custom service registries, bootstrap programs, integration products, and applications that publish dynamically created remote objects in the server's JNDI tree.

Applications that only look up server-configured data sources, JMS resources, EJBs, or other deployed objects generally are not affected.

If an application is affected, it may:

Fail during startup while attempting to register an object
Continue starting but omit a custom JNDI registration
Fail later when another component attempts to look up the missing name
Be unable to replace or remove an existing registration
Report a javax.naming.NoPermissionException
Receive a CORBA NO_PERMISSION exception through CosNaming
Report a deployment or integration failure whose underlying cause is a JNDI permission error

A later NameNotFoundException can be a secondary symptom. In that case, inspect earlier logs to determine whether the application's original bind or rebind operation was denied.

Mitigate the Effects of the Enabled Setting

Inventory code and utilities that call JNDI bind, rebind, unbind, rename, createSubcontext, or destroySubcontext.
Include CORBA clients that use CosNaming mutation operations.
Identify the effective identity used for each operation.
Record whether each operation arrives through a naming client or trusted local server code.
Review existing policies for the JNDI names being modified.
Replace remote application-managed registrations with deployment-time or server-managed configuration where practical.
Where a client must manage a name, give it an appropriate per-name JNDI modify policy and ensure that the name is intended for client-origin bindings. Use an administrative identity only when the client must manage a protected server-origin binding.
Remove application use of the sharable-namespace environment property unless it is part of a supported WebLogic Server internal integration.
Test application startup, shutdown, failover, redeployment, and any dynamic registration or deregistration workflows.

Do not test only lookups. The compatibility change is visible when an application attempts to create, replace, rename, or remove a binding.

Troubleshooting Issues

A failure associated with a specific JNDI resource can contain:

User <user-name> does not have permission on <jndi-name>
to perform modify operation.

For example:

User application-user does not have permission on services/MyRegistry
to perform modify operation.

For an unidentified caller, the message can use <unknown> as the user name.

A binding-origin denial can instead state that the caller cannot modify or shadow a server-created JNDI binding. These messages distinguish protected-origin enforcement from an ordinary per-name policy denial.

The following separate message indicates the existing remote-anonymous-user restriction rather than binding-origin protection:

A remote anonymous user does not have permission to perform this JNDI operation.

To determine whether the attribute caused the issue, perform the following steps:

Confirm that the failed operation changes the JNDI namespace. A failure limited to lookup or list is not caused by this attribute.
Confirm the current runtime value of JNDIBindingAuthorizationPolicyEnabled.
Identify the effective user under which the JNDI operation runs.
Determine whether the target is a client-origin binding or a protected server-origin binding, and whether the caller has the WebLogic Admin, Deployer, or Operator security role.
Determine whether the call arrived through a naming client or trusted local server code.
Review the applicable modify policy for the canonical JNDI name, including the source and destination when troubleshooting a rename.
Check whether the JNDI environment enables weblogic.jndi.createUnderSharable.
Review the complete NoPermissionException or CORBA NO_PERMISSION cause.
If the caller has an accepted security role but the operation is still denied, review the JNDI resource policy for the affected name.
Temporarily enable JNDI debug output, including DebugJNDI, if the effective operation, identity, or namespace is unclear.

In a controlled environment, change the attribute dynamically and repeat the same modification using the same caller and JNDI environment. If the operation succeeds with the attribute set to false but fails with a server-origin protection message when it is true, this attribute caused the difference.

A failure that remains when the attribute is false points instead to an existing JNDI resource policy, the remote-anonymous-user restriction, an invalid namespace, or another JNDI configuration issue.

JNDIOutboundConnectionsAllowListEnabled

The FeatureCompatibilityMBean.JNDIOutboundConnectionsAllowListEnabled feature gate controls enhanced JNDI URL validation and enforcement of the outbound connection allowlist configured in the SecurityConfigurationMBean.

Note:

If you do not see this feature gate, confirm that you have applied the latest available Patch Set Update (PSU) or Critical Security Patch Update (CSPU). Security fixes and their feature gates are delivered on an as-needed basis through PSUs and CSPUs to ensure that your system is protected against vulnerabilities. To determine when this feature gate was delivered, see Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

A server-side JNDI operation can sometimes cause WebLogic Server to connect to another server. For example, an application might look up an object through a remote JNDI provider, a Foreign JNDI Provider might contact another domain, or a locally bound JNDI reference might contain a URL that is followed when the object is retrieved.

FeatureCompatibilityMBean.JNDIOutboundConnectionsAllowListEnabled controls whether WebLogic Server limits those outbound JNDI connections to destinations listed in the SecurityConfigurationMBean.JNDIOutboundConnectionsAllowed attribute.

In this attribute, "outbound" means that WebLogic Server may open a connection while processing a server-side JNDI operation.

When FeatureCompatibilityMBean.JNDIOutboundConnectionsAllowListEnabled is set to true, WebLogic Server checks relevant external JNDI URLs against those listed in SecurityConfigurationMBean.JNDIOutboundConnectionsAllowed. The operation continues only when the URL's scheme and host match an allowlist entry. If the SecurityConfigurationMBean attribute is empty, WebLogic Server rejects external URL destinations handled by this policy. Local names, names without a URL scheme, and java: names remain allowed.

When FeatureCompatibilityMBean.JNDIOutboundConnectionsAllowListEnabled is set to false, the SecurityConfigurationMBean.JNDIOutboundConnectionsAllowed value is ignored. WebLogic Server instead preserves the existing behavior, including any configuration supplied through these legacy system properties:

wls.jndi.jndiAllowedSchemes
wls.jndi.jndiAllowAllScheme

Disabling JNDIOutboundConnectionsAllowListEnabled does not necessarily mean that every scheme is accepted. A legacy system property may still restrict the operation.

When JNDIOutboundConnectionsAllowListEnabled is set to true, the MBean configuration takes precedence and those corresponding legacy properties are ignored.

WebLogic Server separately preserves administrator-approved destinations created from trusted deployment or server configuration. The exact configured factory/provider pair, deployment-created link target, or WebLogic-created configured reference can carry internal proof of that origin and bypass this allowlist for that configured destination. The proof does not authorize a caller-supplied replacement URL, a different factory/provider pair, a URL-shaped lookup supplied later, or a reference returned by the remote provider. Those later values remain subject to the applicable outbound check.

For example:

`FeatureCompatibilityMBean.JNDIOutboundConnectionsAllowListEnabled`	`SecurityConfigurationMBean.JNDIOutboundConnectionsAllowed`	Result
`false`	Empty	The new MBean allowlist is not enforced.
`false`	`ldap:directory.example.com`	The MBean list is stored but is not used by this feature.
`true`	Empty	External JNDI URL destinations are rejected.
`true`	`ldap:directory.example.com`	LDAP JNDI connections to that host are permitted.
`true`	`:`	All schemes and hosts are permitted by this allowlist.

A permitted destination can still fail later because of DNS, networking, TLS, credentials, provider configuration, or another JNDI policy.

A simplified flow is:

Application performs JNDI operation
              ↓
WebLogic Server encounters an external URL
              ↓
Scheme and host are checked against JNDIOutboundConnectionsAllowed
              ↓
Connection is permitted or the JNDI operation fails

This attribute is not a general network firewall. It does not control every socket or HTTP connection created by application code.

Default Behavior

Property	`FeatureCompatibilityMBean.JNDIOutboundConnectionsAllowListEnabled`	`SecurityConfigurationMBean.JNDIOutboundConnectionsAllowed`
Default	`true`	Empty string
Dynamic?	Yes	Yes

Both attributes are dynamic. After an activated configuration change is received by the server, subsequent JNDI operations use the new setting without requiring a restart.

Potential Impacts

The attribute applies to outbound-capable inputs handled by the WebLogic Server JNDI implementation, including:

Context.PROVIDER_URL values used by server-side JNDI contexts
Caller-supplied provider URLs used while resolving through Foreign JNDI or Foreign JMS objects; the exact administrator-configured provider destination is separately authorized
URLs discovered or supplied after WebLogic Server begins resolving a Foreign JNDI or Foreign JMS object
Delegate JNDI environments created by WebLogic Server
WebLogic T3, HTTP, and HTTPS URL contexts
URL-shaped remote names in foreign JNDI references
JNDI LinkRef objects whose link names are resolved through a WebLogic URL context or another covered outbound JNDI validation path
A Reference containing a factory class location
A Reference containing a StringRefAddr whose type is URL
An existing object in the local JNDI tree that is materialized by following an external reference during lookup

These checks apply at WebLogic Server JNDI paths that validate provider URLs, URL contexts, foreign references, or reference materialization. They are not a guarantee that arbitrary application or third-party code invoked outside those JNDI paths cannot create a network connection.

It does not directly control:

JDBC connection URLs
Application HTTP clients
Application-created sockets
Direct calls to third-party networking libraries
Ordinary local JNDI names such as jdbc/MyDataSource
java: component-environment names
JNDI names that contain no URL scheme
Which JNDI factory classes may run
Who may bind or unbind objects in the WebLogic JNDI namespace

Factory classes are controlled separately by FeatureCompatibilityMBean.JNDIAdditionalFactoriesAllowListsEnabled. Namespace changes are controlled separately by FeatureCompatibilityMBean.JNDIBindingAuthorizationPolicyEnabled.

When a required destination is absent from the allowlist, an application may experience:

Failure to create an InitialContext
Failure while resolving an unapproved URL supplied through or returned from a Foreign JNDI Provider
Failure while a Foreign JMS resource resolves a URL beyond its exact administrator-configured provider destination
A lookup failure for a locally bound foreign object
A LinkException while following a LinkRef
Application startup or deployment failure
A NamingException reported only when a lazily resolved object is first used
Failover failure because one host in a multi-host provider URL was omitted

The application may work on one server but fail on another if the servers use different host aliases, DNS names, or generated provider URLs.

Mitigate the Effects of the Enabled Setting

Inventory caller-supplied JNDI environments, external references and links, and server-side code that uses remote JNDI. Record Foreign JNDI and Foreign JMS URLs that can be supplied or discovered beyond their exact administrator-configured provider destination.
Record each provider URL, including all failover hosts.
Inventory JNDI Reference objects containing external URLs and LinkRef objects whose resolution enters a covered external WebLogic JNDI path.
Include objects that resolve lazily only when an application performs a lookup.
Populate SecurityConfigurationMBean.JNDIOutboundConnectionsAllowed while the feature gate is still false.
Use exact scheme-and-host entries where practical.
Include both a base domain and its wildcard subdomains when both are required.
Include every DNS alias or IP-address form that applications actually use.
Migrate relevant values from the legacy scheme properties to the MBean allowlist.
Enable JNDIOutboundConnectionsAllowListEnabled.
Test application startup, foreign-resource initialization, normal lookup, provider failover, and lookup after a server restart.

Avoid using *:* as a permanent compatibility solution unless unrestricted outbound JNDI destinations are intentionally required. It is useful as a diagnostic value because it distinguishes allowlist matching from other JNDI failures, but it removes the scheme-and-host restriction supplied by this feature.

Troubleshooting Issues

A rejected provider URL can produce:

JNDI provider URL is invalid - <url>

A rejected URL contained in a JNDI Reference can produce:

JNDI name is invalid. Configure
SecurityConfigurationMBean.JNDIOutboundConnectionsAllowed
to allow outbound JNDI provider URLs.

A rejected foreign remote name or link can produce:

JNDI name is invalid - <remote-name>

Some URL-context paths can still produce a legacy message that refers to:

wls.jndi.jndiAllowedSchemes

When JNDIOutboundConnectionsAllowListEnabled is set to true, do not follow that part of the legacy message. The effective configuration is SecurityConfigurationMBean.JNDIOutboundConnectionsAllowed.

Legacy Property Warning

If JNDIOutboundConnectionsAllowListEnabled is set to true while either of these legacy properties is set:

wls.jndi.jndiAllowedSchemes
wls.jndi.jndiAllowAllScheme

WebLogic Server logs message BEA-050010, explaining that the MBean configuration takes precedence and the legacy properties are ignored.

For example, a legacy value that allowed the ldap scheme does not automatically populate the new host-aware allowlist. An equivalent broad MBean entry would be:

ldap:*

A narrower and preferable entry identifies the actual host:

ldap:directory.example.com

To determine whether the attribute caused the issue, perform the following steps:

Confirm that the operation is being handled by the WebLogic Server JNDI implementation.
Confirm the live runtime value of JNDIOutboundConnectionsAllowListEnabled.
Read the live value of SecurityConfigurationMBean.JNDIOutboundConnectionsAllowed.
Identify the complete URL that WebLogic Server is attempting to use.
Separate the URL into its scheme and host.
For a provider URL containing multiple hosts, evaluate every host.
Compare the literal hostname in the URL with the configured entry; do not assume that a DNS alias or equivalent IP address will match.
Check whether the failure occurs while resolving an existing Reference, a LinkRef through a covered WebLogic JNDI path, a Foreign JNDI object, or a Foreign JMS object.
Review the complete NamingException chain for JNDI provider URL is invalid or JNDI name is invalid.
Check the server log for BEA-050010.
Temporarily enable JNDI debug output, including DebugJNDI, to see the effective gate and allowlist values.

Because both attributes are dynamic, a narrowly scoped allowlist entry can be added in a controlled environment and the same operation repeated. If adding the exact scheme-and-host entry allows the operation to proceed, the outbound destination check caused the original failure.

Alternatively, the feature gate can be changed dynamically for a controlled comparison. If the operation succeeds when the switch is false and fails with an outbound JNDI validation message when it is true, this attribute is involved.

The three JNDI feature gates are independent:

An error naming JNDIOutboundConnectionsAllowed concerns the destination URL.
An error naming JNDIAdditionalInitialContextFactoriesAllowed or JNDIAdditionalReferenceFactoriesAllowed concerns a factory class.
A NoPermissionException for bind, rebind, or another modification concerns JNDIBindingAuthorizationPolicyEnabled or an existing JNDI resource policy.

An application may need to satisfy more than one check. For example, a caller-supplied remote JNDI environment can require both:

An allowed initial context factory
An allowed provider URL

Changing only the URL allowlist will not correct a factory rejection.

Configuring JNDIOutboundConnectionsAllowed

Configure the SecurityConfigurationMBean.JNDIOutboundConnectionsAllowed attribute using a comma-separated list. Each entry describes an allowed combination of URL scheme and host.

Note:

The SecurityConfigurationMBean.JNDIOutboundConnectionsAllowed attribute was introduced in the August 2026 Critical Security Patch Update (CSPU). See Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

The usual form is:

scheme:hostname

For example:

ldap:directory.example.com

permits URLs such as:

ldap://directory.example.com/ou=people

but does not permit:

ldaps://directory.example.com/ou=people
ldap://other.example.com/ou=people

Multiple entries are separated by commas:

ldap:directory.example.com,
ldaps:secure-directory.example.com,
t3:remote-domain.example.com

Whitespace surrounding entries is ignored.

The exact destination taken from trusted deployment or server configuration is separately authorized for that configured use. Add allowlist entries for caller-supplied provider URLs, URL-shaped lookup inputs, and URLs discovered in references or links beyond that exact configured destination.

Entry form	Meaning
`ldap:directory.example.com`	Permit one scheme and one exact host.
`ldap/s:directory.example.com`	Permit both `ldap` and `ldaps` to that host.
`*:directory.example.com`	Permit any URL scheme to that host.
`:directory.example.com`	Also permit any URL scheme to that host.
`ldap:*`	Permit LDAP to any host.
`ldap:`	Also permit LDAP to any host.
`ldap:*.example.com`	Permit LDAP to subdomains of `example.com`.
`ldap:192.0.2.25`	Permit LDAP to one IPv4 address.
`ldap:192.0.2.0/24`	Permit LDAP to an IPv4 CIDR range.
`ldap:2001:db8:100::/48`	Permit LDAP to an IPv6 CIDR range.
`:`	Permit every scheme and host.

The *:* entry must be the only configured entry. WebLogic Server rejects a configuration that combines it with other entries.

Secure and non-secure scheme shorthand

A scheme ending in /s permits both the base scheme and the base scheme with s appended.

For example:

ldap/s:directory.example.com

is equivalent to:

ldap:directory.example.com,
ldaps:directory.example.com

Similarly:

t3/s:remote.example.com

permits both t3 and t3s connections to that host.

Host Wildcard Behavior

A hostname beginning with *. matches subdomains, but not the base domain itself.

For example:

ldap:*.example.com

permits:

ldap://directory.example.com
ldap://east.directory.example.com

It does not permit:

ldap://example.com
ldap://example.com.other-domain.test

If both the base domain and its subdomains are needed, configure both:

ldap:example.com,
ldap:*.example.com

Partial IP-address wildcards such as 192.168.*.* are not supported. Use an exact IP address or CIDR range instead.

Case and Internationalized Hostnames

Scheme and hostname comparisons are case-insensitive.

For example:

LDAP:Directory.EXAMPLE.COM

matches:

ldap://directory.example.com

Internationalized domain names are converted to their ASCII/Punycode form before comparison. An internationalized hostname and its equivalent Punycode hostname therefore match the same entry.

How URLs are Compared

Matching uses the URL scheme and host.

For a host-specific entry, WebLogic Server parses the candidate URL as a URI and compares the host component produced by that URL form. If a malformed or non-hierarchical URL does not produce a host, it cannot match a hostname-specific allowlist entry. Entries with a wildcard or empty host, such as ldap:* or ldap:, perform a scheme-only check; passing that allowlist check does not establish that the JNDI provider will otherwise accept the URL.

The following URL components are not used to distinguish allowlist entries:

Port
Path
Query string
Fragment
User name
Password

For example, this entry:

ldap:directory.example.com

permits both:

ldap://directory.example.com:389/ou=people
ldap://directory.example.com:1389/ou=applications

The allowlist cannot permit port 389 while rejecting port 1389 on the same scheme and host. If port-level control is required, it must be implemented through network or service configuration outside this attribute.

Hostnames and IP Addresses are not Interchangeable

WebLogic Server compares the host written in the URL. It does not perform DNS resolution to determine whether two names lead to the same address.

Therefore:

ldap:localhost

does not permit:

ldap://127.0.0.1/object

Similarly:

ldap:directory.example.com

does not automatically permit:

ldap://directory-alias.example.com/object

even if DNS resolves both names to the same system.

Configure every hostname or IP-address form that legitimate JNDI URLs actually use.

Provider URLs containing Multiple Hosts

A WebLogic provider URL can identify multiple hosts for failover, for example:

t3://admin.example.com:7001,managed.example.com:7001

Every host in the provider URL must be allowed. The entire provider URL is rejected if any member is not matched.

For example, this list permits the preceding URL:

t3:admin.example.com,
t3:managed.example.com

This list also permits it:

t3:*.example.com

However, the wildcard entry does not permit the base host example.com itself.

Application Configurations most Likely to be Affected

Applications and resources are more likely to be affected if they use:

A Foreign JNDI Provider
A Foreign JMS Server that performs remote JNDI lookups
A provider URL pointing to another WebLogic domain
LDAP or another external naming provider
A provider URL containing multiple failover hosts
Hostname aliases that differ from the configured allowlist name
IP-address URLs while the allowlist contains only DNS names
A LinkRef whose link name is resolved through a covered external WebLogic JNDI path
A JNDI Reference containing an external URL
A JNDI object that connects externally only when it is retrieved
A dynamically supplied provider URL or URL-shaped remote name

A local lookup can be affected even when the lookup name itself is not a URL. For example, an application might perform:

lookup("jms/RemoteConnectionFactory")

The local binding can contain a foreign reference that causes WebLogic Server to connect to a remote provider while materializing the returned object.

As a result, deployment or binding might succeed, but the first application lookup can fail later.

T3RouteOnlyToTrustedServersEnabled

The FeatureCompatibilityMBean.T3RouteOnlyToTrustedServersEnabled feature gate controls whether T3 routing should only forward to known or configured trusted server destinations.

Note:

If you do not see this feature gate, confirm that you have applied the latest available Patch Set Update (PSU) or Critical Security Patch Update (CSPU). Security fixes and their feature gates are delivered on an as-needed basis through PSUs and CSPUs to ensure that your system is protected against vulnerabilities. To determine when this feature gate was delivered, see Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

WebLogic Server can sometimes act as an intermediate router for T3 messages. Instead of the caller connecting directly to the server that hosts an object or service, the communication path can be:

Caller → intermediate WebLogic Server → destination WebLogic Server

Previously, if an accepted server-to-server message must be forwarded and no route already existed, the intermediate server might create a route using the destination address and port carried with that message. This enabled certain older or implicitly configured routing topologies to work without a corresponding local-domain or RMI-forwarding entry on the intermediate server.

When FeatureCompatibilityMBean.T3RouteOnlyToTrustedServersEnabled is set to true, the intermediate server (that is, WebLogic Server) can only create a new route to a destination or "trusted server" that it already knows or that has been identified through local WebLogic Server configuration.

A destination can be recognized when, for example:

An appropriate connection or route to the destination already exists.
The destination is a configured server in the local domain.
The destination matches a configured WebLogic RMI forwarding target.
The destination can be resolved through another supported WebLogic routing configuration.

If no existing route or supported configuration identifies the destination, the intermediate server does not create a new outbound connection using only the address supplied with the routed message. Instead, it rejects the routing request as having an unknown destination.

The attribute does not require every caller to connect directly to every server. Supported indirect routing continues to work when the destination is known or properly configured.

For steps on setting T3RouteOnlyToTrustedServersEnabled, see Determining the Security Behavior.

Property	Value
Type	Boolean
Default	`true`
Dynamic	Yes
Primary area	Indirect T3 server routing

Potential Impacts

The FeatureCompatibilityMBean.T3RouteOnlyToTrustedServersEnabled attribute affects indirect T3 server routing performed by the WebLogic Remote Method Invocation (RMI) infrastructure.

Indirect routing may be used by:

Cluster-aware RMI or EJB clients
Server-to-server RMI calls
Cross-domain calls
Applications operating across firewalls or network address translation
Kubernetes environments in which individual Managed Servers are not directly addressable
Configurations using WebLogic RMI forwarding
Other topologies in which a caller reaches a destination through another WebLogic Server

This attribute does not directly affect:

HTTP routing through a web server or load balancer
WebLogic proxy plug-in behavior
A client that connects directly to the destination server
The selection of a cluster member by a load-balancing algorithm
Application authentication or authorization
The application object or method being invoked

However, it can affect whether the caller can reach the server selected by a cluster-aware stub or another WebLogic service.

Enabling the attribute does not close routes or server connections that already exist. Consequently, existing calls may continue working until a connection is closed, a server is restarted, a different destination is selected, or a new route is otherwise required.

Most applications that use ordinary direct T3 connections or standard same-domain cluster communication should not notice a change.

Applications are more likely to be affected when they depend on an intermediate WebLogic Server learning a previously unknown destination from the routed connection information. Examples include:

A cluster-aware EJB or RMI client that can reach one cluster member but cannot directly reach other members
A caller behind a firewall that relies on its first WebLogic connection to reach additional servers
A topology in which servers advertise addresses that are not reachable from the original caller
A cross-domain call whose destination has not been configured for RMI forwarding
A Kubernetes topology in which calls depend on an incomplete or incorrect RMI forwarding configuration
A legacy routing arrangement that works without explicitly defining its destination servers

A typical failure can be intermittent. Calls to one cluster member may succeed while calls to another member fail. An application might work normally until:

Load balancing selects a different server
The original target server fails
A client reconnects
An existing routed connection expires or is closed
The intermediate server restarts
A new server joins the cluster and becomes a possible target

The application method normally is not entered when routing fails. The caller may receive a connection-related exception, an RMI RemoteException, or another service-specific exception whose underlying cause is a failed T3 route.

For stateful services, routing failure can also prevent a caller from reaching the server that holds its state. The application-level symptom may therefore appear to be a failover or state-recovery problem even though the immediate cause is that the destination server could not be reached.

Mitigate the Effects of the Enabled Setting

Identify applications and services that use T3 communication across clusters, domains, firewalls, network address translation, or Kubernetes environments.
Determine whether callers can connect directly to every possible destination server.
Identify intermediate WebLogic Servers that may be asked to forward T3 messages.
Verify that same-domain destination servers are correctly represented in the domain configuration.
Review WebLogic RMI forwarding configuration for cross-domain or Kubernetes routes.
Ensure that each forwarding entry identifies the correct destination name or prefix and forwarding URL.
Verify that the intermediate server has a suitable outbound network channel and can resolve and reach the configured forwarding address.
Exercise new connections to every relevant destination, including failover and load-balancing scenarios.

The feature attribute itself is dynamic, but RMI forwarding mappings are initialized when the server's RMI service starts. If RMI forwarding entries are added or changed while preparing for the enabled behavior, restart the affected servers so that those mappings are loaded.

Troubleshooting Issues

If a new route is rejected because the destination is not known, the sending side can receive a ConnectException containing text similar to:

Unknown routing destination: '<destination>'

When T3 routing debug output is enabled on the intermediate server, the server can report:

Rejecting route request for unknown destination: <destination>

For a proxy-style route, the debug output may instead contain:

Ignoring proxy route request for untrusted destination: <destination>

These messages are strong indicators that T3RouteOnlyToTrustedServersEnabled affected the routing decision. To determine whether the attribute caused the issue, perform the following steps:

Confirm the current runtime value of T3RouteOnlyToTrustedServersEnabled.
Determine whether the failing call uses a direct connection or passes through an intermediate WebLogic Server.
Identify the destination server named in the exception or routing debug output.
Determine whether the intermediate server already has a connection to that destination.
Confirm that the destination is a configured server in the local domain or matches an appropriate RMI forwarding configuration.
Check whether the failure occurs only for particular cluster members, remote domains, or destination addresses.
Check whether the problem began only after a reconnect, failover, server restart, or selection of a new target.
Temporarily enable T3 routing debug output, including DebugRouting, on the intermediate server and reproduce one failing connection.
Look for Unknown routing destination or Rejecting route request for unknown destination.

Note:

Existing routes are not removed when the attribute changes so a useful comparison must exercise a new route. Merely repeating a call over an existing connection may not demonstrate whether the attribute is responsible.

In a controlled environment, change the attribute dynamically and create a fresh connection to the same destination. If the new route succeeds with the attribute set to false but fails with Unknown routing destination when it is true, the destination-recognition requirement is the likely cause.

Not every T3 connection error is caused by this attribute. For example:

Untrusted routing source indicates that the routing source did not satisfy a separate routing requirement.
No outbound channel available for routing to means the destination was recognized, but the intermediate server could not select a suitable outbound channel.
DNS errors, connection refusals, and connection timeouts generally mean that WebLogic Server attempted to contact the destination, so the route passed this attribute's destination check.

WorkContextClassValidationEnabled

The FeatureCompatibilityMBean.WorkContextClassValidationEnabled feature gate controls which WorkContext implementation classes WebLogic Server constructs when it receives WorkArea data. It does not disable WorkArea propagation, determine which WorkArea keys may be used, or control the size of a WorkContext.

Note:

If you do not see this feature gate, confirm that you have applied the latest available Patch Set Update (PSU) or Critical Security Patch Update (CSPU). Security fixes and their feature gates are delivered on an as-needed basis through PSUs and CSPUs to ensure that your system is protected against vulnerabilities. To determine when this feature gate was delivered, see Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

In WebLogic Server, you can employ context propagation to enable an application or WebLogic component to attach contextual information to the work being performed by the current thread. Depending on its propagation mode, that information can travel automatically with operations such as T3/RMI calls, EJB calls, JMS messages, and IIOP calls.

Each value stored in a WorkArea is represented by a class that implements the WebLogic WorkContext interface. Applications can use WebLogic's built-in WorkContext implementations or provide their own implementation.

Enforcement occurs in the process that reads the WorkArea input. For a request or message, this is normally the receiving WebLogic Server. For a response, it is the caller: a WebLogic Server acting as a client applies its own domain's setting when it reads the response. This domain attribute does not configure a standalone or thin-client JVM; those clients retain their client-side compatibility behavior, although their existing class-loading and object-input filters still apply. Some collocated and internal paths also serialize and read WorkContexts again within a server process.

When WorkContextClassValidationEnabled is set to true, then WebLogic Server validates both the class name received from the connection and the Java class to which that name resolves before it constructs an incoming WorkContext. On input paths governed by this attribute, WebLogic accepts the following built-in WorkContext implementations:

String WorkContext
ASCII WorkContext
Long WorkContext
WebLogic diagnostic context

On an incoming path governed by this attribute, an application-defined class that implements weblogic.workarea.WorkContext is rejected. This remains true even when the class is deployed with the application or is otherwise available in the server's class path.

The validation occurs before WebLogic calls the WorkContext constructor or reads the WorkContext's serialized data. Consequently, a rejected context can cause the enclosing remote call or message operation to fail before the application receives it.

This validation applies principally when WorkArea data is read from:

T3 and WebLogic RMI calls, including EJB calls
JMS messages carrying propagated WorkArea data
IIOP and RMI-IIOP calls

Note:

Some WebLogic-internal and web-services input paths already accept only product-provided WorkContext classes independently of this attribute. Enabling or disabling this attribute does not relax those independently enforced restrictions.

WebLogic Server does not reapply this ingress class restriction when restoring WorkArea data that the server previously saved as trusted local data. This internal trusted-data path does not apply to caller-supplied input. A locally created custom WorkContext can also propagate through a collocated RMI call; a WorkContext originally received from an external input remains untrusted when copied through that collocated path and is validated again.

When WorkContextClassValidationEnabled is set to false, WebLogic preserves the legacy behavior for incoming custom WorkContext implementations. A custom class can be loaded and constructed if it:

Is available to the applicable class loader
Implements the WorkContext interface
Meets the WorkContext construction requirements
Passes the other serialization and object-input checks that apply to the connection

A value of false therefore does not disable all WorkContext or serialization validation. Existing object-input filters, class-loading rules, and product-specific input restrictions continue to apply.

For steps on setting WorkContextClassValidationEnabled, see Determining the Security Behavior.

Property	Value
Type	Boolean
Default	`true`
Dynamic	Yes

Serializable WorkContexts

PrimitiveContextFactory.create(Serializable) places an application object inside WebLogic's built-in SerializableWorkContext wrapper. This is different from an application implementing the WorkContext interface directly.

When class validation is enabled, WebLogic continues to accept SerializableWorkContext on selected trusted, authenticated, internal, and locally originated compatibility paths. It is not accepted on every WorkArea input path. For example, an application that propagates a serializable object as WorkArea data with a JMS message can experience a rejection when the receiving server reads that message.

Even when the SerializableWorkContext wrapper is accepted, its enclosed application object remains subject to WebLogic's object-input filtering. It may also be subject to the limit configured by SerializedWorkContextMaximumSize. This attribute controls the outer WorkContext implementation class; it does not automatically approve the classes or size of an object contained inside a SerializableWorkContext.

Potential Impacts

Applications are most likely to be affected if they or one of their libraries:

Define a class that implements weblogic.workarea.WorkContext
Store instances of that class in the current WorkContextMap
Propagate that context with RMI, EJB, JMS, or IIOP work
Use a custom WorkContext for correlation, tracing, tenant information, routing information, security-related application metadata, or other request context
Use PrimitiveContextFactory.create(Serializable) on a path that does not retain the SerializableWorkContext compatibility behavior

An application can continue to work while using a custom WorkContext locally and then fail only when that context crosses a process, server, or protocol boundary. Adding an object to the local WorkContextMap is not itself affected; the validation occurs when another input path attempts to reconstruct the propagated context.

Applications that use only WebLogic's built-in string, ASCII, or long WorkContexts should not normally be affected.

There is no configuration attribute for adding application-defined WorkContext implementation classes to the permitted set. An affected application generally must replace its custom WorkContext implementation with a built-in WorkContext type. Where appropriate, the application may use a built-in string representation for its metadata. A SerializableWorkContext may be another option only when the applicable propagation path supports it and the enclosed object satisfies the separate filtering and size requirements.

Troubleshooting Issues

A server-side rejection normally contains an InvalidClassException similar to:

application.class.Name; WorkContext implementation is not allowed

Other validation failures can include:

application.class.Name; WorkContext implementation required

On an independently strict product input path, the message can instead include:

Unsupported WorkContext class for binary WorkContext input

The exception presented to the application depends on where the WorkContext was being read:

An RMI or EJB client may receive a marshal, unmarshal, remote-call, or connection exception.
A JMS producer, consumer, or message-driven bean may receive a JMSException, a message-delivery failure, or repeated unsuccessful delivery attempts.
An IIOP client may receive a CORBA MARSHAL, COMM_FAILURE, or an RMI-IIOP unmarshalling exception.
The target business method or message listener may never be called because WorkArea processing occurs first.

If a WebLogic Server acting as a remote caller rejects a WorkContext while reading a response, the remote business operation may already have completed. The caller server's domain setting controls that response-side validation. A standalone or thin client does not apply this domain attribute, although a separate client-side filter can still reject response data. Applications should therefore avoid automatically retrying a non-idempotent operation until they determine whether the failure occurred while sending the request or reading the response.

To determine whether the attribute caused the issue, perform the following steps:

Confirm that WorkContextClassValidationEnabled is true in the active domain configuration.
Examine the complete exception chain in the process that read the WorkArea data. For a request or message, this is normally the receiving server. For a response read by a WebLogic Server acting as a client, it is the caller server. The strongest indication is an InvalidClassException that names an application-defined WorkContext class and contains:
```
WorkContext implementation is not allowed
```
Determine whether the named class is itself a WorkContext implementation or is merely an object contained inside a SerializableWorkContext. This attribute controls the former. A rejection of the enclosed object is normally caused by object-input filtering or another serialization setting.
Identify how the WorkArea crossed into the receiving process. Look for an RMI or EJB invocation, a JMS message, or an IIOP call immediately before the failure. Also verify that the application method or message listener was not entered.
If WorkContext debugging is enabled, use the send and receive information to identify the WorkArea entry and propagation path associated with the failure.
In a controlled environment, dynamically disable the attribute and repeat the same operation with a newly issued call or message. A server restart is not required. If the same custom WorkContext succeeds only while the attribute is disabled, the attribute is the likely cause.

Changing the setting does not rewrite serialized WorkArea data. If a queued message or other retained data is read again after false is active, the feature gate uses the new value. The read can still fail because the class is unavailable, another object-input filter rejects it, or the input path independently requires WebLogic-provided WorkContext classes.

After restoring service, migrate the affected custom WorkContext usage before enabling the attribute again.
If the error says Unsupported WorkContext class for binary WorkContext input, the operation may be using a path that is always restricted to WebLogic product classes. In that case, changing this attribute may have no effect.

WLProxyClientCertificateChainValidationEnabled

The FeatureCompatibilityMBean.WLProxyClientCertificateChainValidationEnabled attribute controls how WebLogic Server processes a client certificate received in the WL-Proxy-Client-Cert HTTP header.

This header is used when a web server or reverse proxy accepts the client’s HTTPS connection and then forwards the client certificate to WebLogic Server:

Client -- client-certificate HTTPS --> Proxy
Proxy  -- WL-Proxy-Client-Cert -----> WebLogic Server

Note:

If you do not see this feature gate, confirm that you have applied the latest available Patch Set Update (PSU) or Critical Security Patch Update (CSPU). Security fixes and their feature gates are delivered on an as-needed basis through PSUs and CSPUs to ensure that your system is protected against vulnerabilities. To determine when this feature gate was delivered, see Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

When the attribute is enabled, WebLogic Server validates the complete certificate chain supplied in the header before making the certificates available to the web application or using them for X.509 identity assertion.

This attribute does not control certificates presented directly to a WebLogic Server HTTPS listener. Those certificates are validated as part of the normal TLS connection.

Property	Value
Type	Boolean
Default	`true`
Dynamic	Yes

Related Configuration

This attribute adds validation to an existing proxy-client-certificate configuration. It does not, by itself, cause WebLogic Server to honor the WL-Proxy-Client-Cert header.

The following configuration must also allow the header to be used:

WeblogicPluginEnabled must be enabled. This tells the web container to process WebLogic proxy plug-in headers.
If WeblogicPluginAllowedProxyHosts is configured, the network peer sending the request must match that list. A request from a peer that is not allowed is rejected before certificate-chain validation occurs.
ClientCertProxyEnabled must be enabled for the target web application. This setting determines whether WebLogic Server uses the certificate supplied in WL-Proxy-Client-Cert. Its effective value can come from the web application container, cluster, server, or the client-cert-proxy-enabled setting in the application’s weblogic.xml deployment descriptor.

If any of these prerequisites prevents WebLogic Server from accepting the header, changing WLProxyClientCertificateChainValidationEnabled will have no effect on that request.

When WLProxyClientCertificateChainValidationEnabled is set to true, WebLogic Server:

Base64-decodes the WL-Proxy-Client-Cert header.
Reads all X.509 certificates contained in the decoded value.
Constructs a certificate path using the certificates in the order supplied by the proxy.
Validates that path using the certificate-path validators configured for the current WebLogic security realm.
Uses the trusted certificate authorities configured for the server as the trust anchors for the validation.
Places the complete validated certificate chain in the jakarta.servlet.request.X509Certificate request attribute.

The proxy should forward the client’s end-entity certificate first, followed by any intermediate certificates needed to reach a certificate authority trusted by WebLogic Server. The trusted root certificate generally does not need to be included in the header if it is already present in the server’s trust configuration.

WebLogic Server rejects the request if the forwarded value:

Is not valid Base64-encoded certificate data.
Does not contain an X.509 certificate.
Contains a certificate chain in an unusable order.
Omits an intermediate certificate required to validate the chain.
Chains to a certificate authority that WebLogic Server does not trust.
Contains an expired or not-yet-valid certificate.
Cannot be validated by the certificate-path providers configured for the current security realm.

The rejection produces an HTTP 403 Forbidden response before WebLogic Server dispatches the request to the web application. The application’s servlets and normal request-processing path therefore do not receive the request.

Successfully validating the certificate chain does not, by itself, authenticate the user. After validation, WebLogic Server still performs its normal X.509 identity-assertion and user-mapping processing. A certificate can pass chain validation but later fail authentication because it cannot be mapped to a user or because of other security-realm configuration.

When WLProxyClientCertificateChainValidationEnabled is set to false, WebLogic Server preserves the previous proxy-client-certificate behavior.

WebLogic Server Base64-decodes the WL-Proxy-Client-Cert header and parses the first X.509 certificate found in it. The resulting certificate is placed in a one-element array in the following servlet request attribute:

jakarta.servlet.request.X509Certificate

WebLogic Server does not validate a certificate path from the forwarded certificate to one of the server’s configured trusted certificate authorities.

If the header cannot be decoded or the certificate cannot be parsed, WebLogic Server ignores the forwarded certificate and continues processing the request. Depending on the application’s security configuration, the request may proceed without a client identity, use another authentication mechanism, or subsequently receive an authentication failure.

A parsing failure in this mode can produce message BEA-101257, indicating that WebLogic Server could not parse the certificate in the WL-Proxy-Client-Cert header and ignored it.

Potential Impacts

This attribute primarily affects web applications that:

Run behind a WebLogic proxy plug-in, Oracle HTTP Server, Oracle Traffic Director, load balancer, or another reverse proxy that supplies WL-Proxy-Client-Cert.
Use CLIENT-CERT authentication with the client's TLS connection terminated at the proxy.
Use X.509 identity assertion based on the forwarded certificate.
Read jakarta.servlet.request.X509Certificate directly.
Depend on a private or organization-specific certificate authority.
Depend on a proxy that forwards only the client certificate instead of the complete chain.

Applications that receive client certificates directly through a WebLogic Server HTTPS listener, without using WL-Proxy-Client-Cert, are not affected by this attribute.

Troubleshooting Issues

After the attribute is enabled, clients may begin receiving HTTP 403 responses even though the same requests previously reached the application. Common compatibility causes include:

The proxy forwards only the client certificate, but WebLogic Server requires one or more intermediate certificates to complete the chain.
The proxy sends the certificates in the wrong order.
The issuing certificate authority is trusted by the proxy but is not present in the WebLogic Server trust configuration.
Different servers in a cluster have different trust stores or certificate-path provider configurations. Requests may then succeed or fail depending on which server receives them.
A custom certificate-path validator applies requirements that the forwarded chain does not meet.
An application assumes that jakarta.servlet.request.X509Certificate always contains exactly one certificate. With validation enabled, the attribute contains the complete forwarded chain and can contain multiple certificates.
A malformed forwarded certificate was previously ignored, allowing another authentication mechanism to run. With validation enabled, the malformed certificate causes the request to be rejected immediately instead.

To determine whether the attribute caused the issue, first confirm that the problem occurs only for requests containing WL-Proxy-Client-Cert. A direct HTTPS request that does not use this header is outside the scope of the attribute.

Check the following:

Confirm the live value of WLProxyClientCertificateChainValidationEnabled.
Confirm that WeblogicPluginEnabled and the effective ClientCertProxyEnabled value are both enabled.
If WeblogicPluginAllowedProxyHosts is configured, confirm that the proxy’s actual socket address is allowed. A failure of this check also produces HTTP 403, but occurs before certificate-chain validation.
Enable DebugHttp. A chain-validation rejection records a message beginning with:
```
Rejecting request with invalid WL-Proxy-Client-Cert certificate
```
The accompanying exception normally identifies the parsing or certificate-path validation failure.
Enable DebugSecurityCertPath when additional certificate-validation detail is required. This can help identify the certificate-path provider, trust anchor, validity, or chain relationship that caused validation to fail.
Inspect exactly what the proxy places in the header. Verify the certificate order, required intermediate certificates, validity dates, and issuing certificate authorities.
Compare the trust and security-realm configuration on every server that can receive the request. Intermittent failures across a cluster frequently indicate inconsistent server trust configuration.
In a controlled environment, dynamically disable only this attribute and repeat the same request. If the HTTP 403 disappears and the request returns to the previous behavior, this attribute is responsible for the difference. No server restart is required for this comparison.

An HTTP 401 or an authentication-related error after successful certificate validation generally points to X.509 identity assertion or user mapping rather than this attribute. An HTTP 403 accompanied by the DebugHttp certificate-rejection message is the clearest indication that this validation switch rejected the request.

WorkContextInputMaximumASCIIFieldSize

A WorkContext is metadata that WebLogic Server can propagate with work, such as a request or message. In one WorkArea binary encoding, some ASCII fields consist of a four-byte signed integer specifying their length followed by that number of bytes. The FeatureCompatibilityMBean.WorkContextInputMaximumASCIIFieldSize feature gate specifies the maximum declared length, in bytes, that WebLogic Server will accept for these fields. WebLogic Server checks the length before it allocates a byte array or reads the field contents.

Note:

If you do not see this feature gate, confirm that you have applied the latest available Patch Set Update (PSU) or Critical Security Patch Update (CSPU). Security fixes and their feature gates are delivered on an as-needed basis through PSUs and CSPUs to ensure that your system is protected against vulnerabilities. To determine when this feature gate was delivered, see Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

The setting applies separately each time the shared WorkArea binary decoder reads an ASCII field. It is not a limit on the combined size of a WorkArea, the complete WorkContext header, or the enclosing request or message.

On an input path governed by this attribute, the affected fields include:

The WorkContext implementation class name
The value contained in an AsciiWorkContext
An ASCII field that another WorkContext implementation reads through the same WorkContextInput.readASCII() method

The attribute does not directly limit:

A WorkArea entry name, which uses a different string encoding
The value contained in a StringWorkContext
A value contained in a LongWorkContext
The serialized payload inside a SerializableWorkContext (use FeatureCompatibilityMBean.SerializedWorkContextMaximumSize instead).
The total number of WorkContext entries
The size of the enclosing SOAP message, HTTP request, JMS message, or other transport payload

Property	Value
Type	Integer, measured in bytes
Default	`65535`
Configured cap (max field length)	Any value from `-1` through `2147483647`
Dynamic	Yes. A server restart is not required.
Scope	Domain-wide. Enforced by a server when it uses the shared WorkArea binary decoder

When FeatureCompatibilityMBean.WorkContextInputMaximumASCIIFieldSize is set to a positive integer (such as 65535, its default), that is a literal byte cap. A field whose declared length is equal to or less than the configured value is accepted. A field whose declared length is larger is rejected before its payload bytes are allocated or read.

For example, when WorkContextInputMaximumASCIIFieldSize = 65535, an affected decoder accepts each ASCII field containing up to 65,535 bytes. It rejects a field declaring 65,536 bytes with:

Invalid binary WorkContext ASCII field length: 65536

The exception reports the rejected wire length; it does not include the configured maximum.

Because this attribute is dynamic, an activated configuration change applies to subsequent reads without a server restart. It does not affect a field that a server has already decoded.

When FeatureCompatibilityMBean.WorkContextInputMaximumASCIIFieldSize is set to -1, the attribute does not impose a maximum on a nonnegative ASCII-field length. This preserves the earlier size-handling behavior for compatibility. Values below -1 are not legal configuration values and are rejected by the MBean. The input decoder also fails closed if it encounters such an effective value.

The underlying exception contains:

Invalid binary WorkContext ASCII field length: <length>

Thin or standalone client code that does not have access to the server's FeatureCompatibilityMBean also retains the -1 behavior. The server-side value governs input decoded by an applicable server path; it does not establish a corresponding outbound limit in every client.

Note:

0 is not another spelling of the disabled value. It permits only zero-length ASCII fields.

A normal binary WorkContext entry contains at least a nonempty WorkContext implementation class name. Consequently, setting the attribute to 0 will generally reject valid binary WorkContext entries. Use -1 to preserve the uncapped legacy behavior, or use a positive value for a practical limit.

The production mode compatibility warning framework treats both -1 and 0 as disabled numeric values. Therefore, a value of 0 can impose a literal runtime cap while still producing the disabled feature warning.

Input Paths Governed by the Attribute

The attribute governs paths that decode the affected four-byte-length WorkArea binary representation through WebLogic Server's shared WorkContext input implementation. This includes the binary WorkContext representation accepted in applicable JAX-WS SOAP WorkContext headers and can include other product integrations that delegate to the same decoder.

The configured cap is not applied when WebLogic Server restores WorkArea data that the server previously saved as trusted local data. A negative field length remains invalid. This internal trusted-data path does not apply to caller-supplied input.

The attribute does not govern transport-specific WorkContext encodings that use separate decoders. In particular, it does not apply to the T3 or IIOP WorkContext encodings.

Do not assume that a successful T3 or IIOP test proves that the configured cap is ineffective. First establish which WorkContext decoder the failing or successful operation uses.

Potential Impacts

An application or integration is most likely to be affected if it:

Sends a binary SOAP WorkContext header
Propagates an AsciiWorkContext through a path that uses the shared binary decoder
Uses unusually long WorkContext implementation class names or ASCII values
Provides a custom WorkContext implementation that calls WorkContextInput.readASCII()
Generates WorkArea data outside WebLogic Server and declares field lengths directly
Uses a configured cap smaller than the class-name field required for an otherwise valid WorkContext

Applications that do not send WorkArea data, or whose WorkContext path uses a separate T3 or IIOP decoder, are not affected by this attribute.

Start with 65,535 bytes and increase the value only when a legitimate WorkContext field requires more space. The configured value should still be large enough for the WorkContext class names and ASCII values used by the application.

Troubleshooting Issues

When an affected field exceeds the configured cap, WebLogic Server rejects the WorkContext while decoding it. Because WorkArea processing normally occurs before application dispatch, the target application operation may never be invoked.

The externally visible result depends on the integration. For a binary WorkContext carried in a SOAP request, the caller can receive an HTTP 500 SOAP fault. Other shared-decoder paths can expose an IOException, message-processing failure, or a transport-specific wrapper exception.

The strongest underlying diagnostic is:

Invalid binary WorkContext ASCII field length: <length>

Do not confuse this message with these separate conditions:

Invalid serialized WorkContext length concerns the payload governed by SerializedWorkContextMaximumSize.
A message stating that a WorkContext implementation is not allowed concerns class validation, including behavior governed by WorkContextClassValidationEnabled or an independently strict input path.
An object-input-filter or InvalidClassException failure can concern a class inside a serialized WorkContext rather than an ASCII-field length.

To determine whether the attribute caused the issue, perform the following steps:

Check the active WorkContextInputMaximumASCIIFieldSize value under the domain's FeatureCompatibilityMBean. When troubleshooting a cluster, verify the effective runtime value on each server that can receive the operation.
Identify how the WorkArea data entered the server. Confirm that the operation uses the shared four-byte-length binary decoder rather than a separate T3 or IIOP decoder.
Examine the complete server-side exception chain for Invalid binary WorkContext ASCII field length.
Compare the length in the message with the configured cap. A negative length is always invalid; a nonnegative length is rejected when the configured cap is 0 or greater and the length exceeds that cap.
Determine which field was being read. The first affected field in a binary WorkContext entry is normally its implementation class name. An AsciiWorkContext then contains another affected field for its value.
Check whether the cap is smaller than a legitimate WorkContext class name or ASCII value used by the application.
In a controlled environment, dynamically raise the cap and repeat the operation with a newly issued request or message. If the exact operation succeeds after the cap is raised, this attribute caused the earlier rejection.
If necessary, compare with -1 only as a controlled compatibility test. Leaving the value at -1 restores legacy behavior without an attribute-imposed cap on nonnegative field lengths.

If the operation still fails after the ASCII-field length is within the configured cap, investigate class validation, serialized WorkContext sizing, object-input filtering, and the enclosing protocol independently.

Relationship to Other WorkContext Compatibility Settings

WorkContextInputMaximumASCIIFieldSize controls only the lengths of the ASCII fields described above. It does not replace the other WorkContext controls:

SerializedWorkContextMaximumSize limits the byte payload of each SerializableWorkContext and can also activate stricter filtering for the object inside that wrapper.
WorkContextClassValidationEnabled controls which WorkContext implementation classes may be constructed on the input paths it governs.

A single incoming WorkContext can be subject to more than one check. Passing the ASCII-field cap does not guarantee that its implementation class or serialized contents will be accepted, and passing those checks does not bypass the ASCII-field cap.

WSATIgnoreUnknownReplayCompletionEnabled

The FeatureCompatibilityMBean.WSATIgnoreUnknownReplayCompletionEnabled feature gate controls how WebLogic Server, acting as the Web Services Atomic Transaction (WS-AT) transaction coordinator, handles a WS-AT replay-completion request for which no matching local transaction exists.

Note:

If you do not see this feature gate, confirm that you have applied the latest available Patch Set Update (PSU) or Critical Security Patch Update (CSPU). Security fixes and their feature gates are delivered on an as-needed basis through PSUs and CSPUs to ensure that your system is protected against vulnerabilities. To determine when this feature gate was delivered, see Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

WS-AT recovery allows a participant to notify a transaction coordinator that it is prepared and to request completion of an interrupted transaction. The coordinator uses the transaction identifier in the request to find the corresponding local transaction. If the transaction is still known, normal recovery processing arranges for the participant to receive the transaction's eventual completion outcome.

The recovery sequence is:

Prepared or replay-completion request arrives
Coordinator extracts the transaction identifier and ReplyTo endpoint
Coordinator looks up the local transaction:
- Transaction found: continue normal completion-retry processing
- Transaction not found and attribute is false:
  - Send Rollback to ReplyTo and wait for the reply.
- Transaction not found and attribute is true:
  - Log and ignore the replay-completion request.

WSATIgnoreUnknownReplayCompletionEnabled controls only the behavior taken when the coordinator cannot find a local transaction matching a WS-AT replay-completion request. It applies both to a direct replay-completion request and to the replay path entered when a Prepared request refers to an unknown transaction.

The attribute applies to the common WS-AT recovery processing used by the WS-AT 1.0 and WS-AT 1.1 coordinator endpoints.

This attribute does not:

Change recovery behavior for a transaction that the coordinator can find.
Authenticate the caller or validate the transaction identifier as belonging to the caller.
Validate, sanitize, or restrict WS-Addressing ReplyTo endpoints generally.
Change other WS-AT protocol operations or non-WS-AT JTA transactions.
Enable the optional WS-AT deployment if WS-AT is otherwise disabled.

Property	Value
Type	Boolean
Default	`true`
Dynamic	Yes
Scope	Domain-wide. Evaluated by the WebLogic Server WS-AT coordinator that processes a replay-completion request.

When WSATIgnoreUnknownReplayCompletionEnabled is set to true and the coordinator cannot find a matching local transaction, WebLogic Server:

Records an informational message identifying the ignored unknown replay-completion request.
Returns without invoking rollback on the recovery resource.
Does not send a Rollback callback to the request's ReplyTo endpoint.
Does not wait for an outbound callback exchange or its reply timeout.

The request is ignored rather than rejected solely because of this attribute. Do not expect this condition by itself to produce a SOAP fault or HTTP error response.

If the coordinator finds the transaction, the attribute has no effect. The normal completion-retry mechanism continues and may later send the appropriate transaction outcome to the participant.

Enabling this attribute prevents an unknown replay-completion request from causing the coordinator to use its caller-supplied ReplyTo endpoint for an outbound rollback callback. It also prevents the request-processing thread from waiting for that callback exchange.

The coordinator still parses the inbound WS-Addressing data and constructs the recovery resource before it determines that no matching transaction exists. The protection is specifically that rollback is not invoked on that resource after the failed transaction lookup.

This attribute does not:

Authenticate or authorize a WS-AT recovery caller.
Reject malformed or unauthorized requests that fail elsewhere in the protocol stack.
Validate or allowlist ReplyTo destinations for other WS-AT messages.
Prevent outbound callbacks associated with known transactions.
Replace network controls, endpoint access controls, transport security, request-rate controls, or WS-AT operational monitoring.

Treat the attribute as a hardening control for unknown WS-AT replay-completion requests, not as a general WS-Addressing endpoint-validation mechanism or a complete WS-AT security policy.

When WSATIgnoreUnknownReplayCompletionEnabled is set to false, WebLogic Server preserves the legacy WS-AT recovery behavior. If no matching local transaction exists, the coordinator treats the unknown transaction as rolled back. It invokes rollback on a recovery resource created from the WS-Addressing ReplyTo endpoint supplied in the request. That resource sends an outbound WS-AT Rollback callback to the supplied endpoint and waits for the callback exchange to complete.

The wait is bounded by the WS-AT reply timeout configured through the weblogic.wsee.wstx.wsat.reply.timeout system property. The default timeout is 120 seconds. An unreachable or unresponsive ReplyTo destination can therefore retain the request-processing thread until the call succeeds, fails, or times out.

Dynamic Behavior and Requests Already in Progress

The attribute is evaluated when the coordinator processes replay completion. Changing it dynamically affects later requests that reach this check and does not require a server restart.

Enabling the attribute does not cancel an outbound rollback callback that began while the attribute was disabled, and it does not release a thread that is already waiting for that callback to complete. Disabling the attribute restores the legacy rollback behavior for subsequent unknown replay-completion requests.

In a cluster or mixed-version environment, ensure that every server that may receive WS-AT coordinator recovery traffic has the supporting update and observes the intended domain configuration. Otherwise, the same unknown transaction can be ignored on one server but cause an outbound rollback callback on another.

Potential Impacts

Applications and integrations are most likely to notice this setting when they use:

WS-AT recovery between WebLogic Server and a non-WebLogic transaction manager or participant.
A custom WS-AT implementation, bridge, or recovery service.
Bottom-up recovery in which a prepared participant contacts a recovered coordinator.
Long-running or in-doubt distributed transactions whose coordinator state may no longer be available when a participant retries.
Participant recovery logic that depends on receiving an immediate presumed-abort Rollback response for an unknown transaction.
Repeated Prepared or replay-completion messages after server failure, migration, or recovery-record cleanup.

Ordinary local JTA transactions, applications that do not use WS-AT, and WS-AT recovery requests for transactions still known to the coordinator are not affected by this compatibility boundary.

After the attribute is enabled, an affected participant may experience:

No Rollback callback after it sends Prepared or replay completion for a transaction unknown to the coordinator.
Repeated recovery attempts because the participant continues waiting for a definitive outcome.
An in-doubt branch or participant recovery record that remains pending longer than it did with the legacy behavior.
A recovery request that completes promptly instead of waiting for an unreachable ReplyTo endpoint or the WS-AT reply timeout.
Different behavior between coordinator-capable servers if their patch levels or effective attribute values are inconsistent.

The absence of an immediate rollback for an unknown transaction does not mean that known-transaction recovery has been disabled. If the local transaction exists, normal completion retry remains in effect.

Mitigate the Effects of the Enabled Setting

Inventory applications and integrations that use WS-AT recovery, including non-WebLogic transaction managers, custom bridges, and participants that can remain prepared across a coordinator restart.
Determine whether participant recovery logic requires an immediate presumed-abort Rollback callback when the coordinator no longer has the transaction.
Verify that affected participants tolerate an ignored unknown replay request, retry safely, and eventually resolve or administratively expose any remaining in-doubt work.
Apply the supporting update consistently to every server that may process WS-AT coordinator recovery traffic.
In a representative test environment, exercise WS-AT 1.0 and WS-AT 1.1 crash recovery, bottom-up recovery, known transaction identifiers, stale or unknown transaction identifiers, and repeated recovery requests.
Confirm that enabling the attribute prevents outbound callbacks for unknown transactions while leaving normal recovery for known transactions unchanged.
Verify that the attribute is enabled in production and monitor WLS-WSEE-WSAT-00112, participant retry rates, in-doubt transactions, and retained participant recovery records.
Establish an operational procedure for participants that cannot resolve an unknown transaction without a coordinator-supplied rollback outcome.

Reducing the WS-AT reply timeout can shorten the legacy wait but is not equivalent to enabling this attribute. The timeout still permits an outbound callback attempt, whereas this attribute prevents the rollback callback from being invoked for an unknown local transaction.

Troubleshooting Issues

When the attribute is enabled and an unknown replay-completion request is ignored, the coordinator writes message WLS-WSEE-WSAT-00112 with text similar to:

WLSTransactionServicesImpl replayCompletion() tid=<transaction-identifier> (<xid>) no matching transaction; ignoring replay request

This message is the strongest indication that this attribute selected the ignore behavior for a particular request.

When the attribute is disabled, logs may instead show an outbound rollback attempt, a callback timeout, or an XAException associated with rolling back the recovery resource. DebugWSAT output can provide additional protocol-path detail, but it is not required for the informational ignored-request message.

To determine whether the attribute caused the issue, perform the following steps:

Confirm the live value of WSATIgnoreUnknownReplayCompletionEnabled on the domain's FeatureCompatibilityMBean.
Identify the server acting as the WS-AT coordinator and confirm that the activity is a Prepared or replay-completion recovery request, rather than a normal application call or participant registration.
Identify the WS-AT protocol version and coordinator endpoint receiving the request. The common recovery path can be reached through both WS-AT 1.0 and WS-AT 1.1 endpoints.
Determine whether the transaction identifier in the request still maps to a local coordinator transaction. If it does, this attribute does not control the subsequent recovery behavior.
Search the coordinator log for WLS-WSEE-WSAT-00112 and the text no matching transaction; ignoring replay request. Correlate the transaction identifier with the participant's recovery attempt.
Determine whether the participant expected an immediate presumed-abort Rollback callback and whether it is retrying or retaining an in-doubt recovery record because no callback arrived.
Check every coordinator-capable server for the supporting update and a consistent effective attribute value. Intermittent callback behavior can indicate a mixed patch or configuration state.
In a controlled environment, send a fresh replay-completion request for an unknown transaction. With the attribute enabled, verify that the ignored-request message is written, no callback reaches ReplyTo, and the request completes promptly. With the attribute disabled, verify the expected legacy rollback callback behavior.
Separately test a recovery request for a known transaction. Its completion-retry behavior should be the same with the attribute enabled or disabled.

Do not use a caller-controlled or production endpoint as the ReplyTo destination in a diagnostic test. Use an isolated endpoint where callback attempts and timing can be observed safely.

WSATRegistrationSecretEnabled

The FeatureCompatibilityMBean.WSATRegistrationSecretEnabled feature gate controls whether a registration request on the legacy, non-issued-token path must prove that the caller received the coordination context exported for that transaction.

Note:

If you do not see this feature gate, confirm that you have applied the latest available Patch Set Update (PSU) or Critical Security Patch Update (CSPU). Security fixes and their feature gates are delivered on an as-needed basis through PSUs and CSPUs to ensure that your system is protected against vulnerabilities. To determine when this feature gate was delivered, see Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

Web Services Atomic Transaction (WS-AT) allows multiple services to participate in one distributed transaction. A WebLogic Server acting as the transaction coordinator exports a WS-Coordination context to a participant. The participant then calls the registration service identified in that context and supplies the endpoint that the coordinator should use for later prepare, commit, or rollback messages.

The normal registration sequence is:

Coordinator exports a coordination context.
Participant receives the RegistrationService endpoint reference.
Participant sends a Register request.
Coordinator registers the participant endpoint.
Coordinator later sends transaction-completion messages.

Property	Value
Type	Boolean
Default	`true`
Dynamic	Yes
Scope	Domain-wide. Evaluated by a WS-AT coordinator when it exports a coordination context and when it processes a participant registration request.

When FeatureCompatibilityMBean.WSATRegistrationSecretEnabled is set to true, WebLogic Server places a per-transaction registration secret in the RegistrationService endpoint reference. A participant using that endpoint reference sends the secret back as a WS-Addressing reference-parameter header named wls-wsat:registrationSecret. On the non-issued-token path, the coordinator verifies the secret before it registers the participant endpoint.

The attribute applies to the WS-AT 1.0 and WS-AT 1.1 registration endpoints and protects both durable-participant enlistment and volatile-participant registration.

For the non-issued-token path, the coordinator rejects the registration before participant enlistment or synchronization registration if:

The transaction cannot be found.
The transaction does not have an expected registration secret.
The request does not contain the wls-wsat:registrationSecret header.
The supplied secret does not match the secret stored on the transaction.

A matching registration secret allows registration processing to continue. Other transaction, protocol, and endpoint-processing checks still apply.

The registration secret is bearer-style proof that the caller received the exported coordination context. Treat the coordination context and its reference parameters as sensitive transaction data. Do not record registration-secret values in ordinary application logs or diagnostic material.

This attribute does not:

Enable the optional WS-AT deployment if WS-AT is otherwise disabled.
Replace WS-AT issued-token validation. If WS-AT issued-token enforcement is enabled, a request without the required security-context credential is rejected even if it contains a matching registration secret.
Authenticate an application user.
Restrict the scheme, host name, IP address, or port in a participant endpoint reference.
Require HTTPS or encrypt a coordination context.
Affect transactions that do not use WS-AT participant registration.

This attribute supplements the existing WS-AT security-context credential path. It does not replace or relax it.

If a security-context credential is present, WebLogic Server validates that its AppliesTo value identifies the transaction. A valid credential satisfies the registration authorization check without requiring the registration secret as an additional credential.
If the credential's AppliesTo value does not identify the transaction, the request is rejected regardless of the registration-secret setting.

Consequently, a missing-issued-token failure and a registration-secret mismatch are separate conditions and should be diagnosed independently.

Furthermore, enabling this attribute prevents a caller that has only a live transaction identifier from registering a participant endpoint on the protected legacy path. It does not authorize or validate the contents of the participant endpoint reference after the caller has demonstrated possession of the coordination context.

A party that obtains the complete coordination context, including its registration secret, can present the same proof. This attribute therefore does not replace:

Appropriate transport or message protection for coordination contexts.
Network controls around WS-AT endpoints.
Issued-token security where that mode is required.
Independent validation or policy for participant endpoint destinations.

Treat the attribute as a WS-AT registration proof mechanism, not as a general participant-endpoint allowlist or a complete WS-AT authentication system.

When WSATRegistrationSecretEnabled is set to false, WebLogic Server preserves the legacy WS-AT interoperability behavior.

For WebLogic Server generated coordination contexts, the RegistrationService endpoint reference does not contain a wls-wsat:registrationSecret reference parameter.

When the coordinator receives a registration request without a security-context credential, and WS-AT issued-token enforcement is not enabled, it does not reject the request merely because a registration secret is absent. The existing transaction lookup, protocol checks, issued-token behavior, and participant registration processing continue to apply.

Dynamic Behavior and Outstanding Coordination Contexts

The WSATRegistrationSecretEnabled attribute is read when WebLogic Server exports a coordination context and again when the coordinator processes the later registration request. Changing the setting alone does not modify previously issued contexts or initialize transaction secrets.

An existing transaction can acquire a secret when WebLogic Server exports another coordination context for it after enablement. Contexts exported while the attribute was disabled still lack the secret, even if a later export initializes one on the transaction.

For a registration request without a security-context credential, when WS-AT issued-token enforcement is disabled, the important combinations are:

Value when the context is exported	Value when registration is processed	Result
`false`	`false`	Legacy registration behavior; no registration secret is required.
`false`	`true`	Registration using the previously issued endpoint reference is rejected because that context does not contain the required secret, even if a later export has initialized a secret on the transaction.
`true`	`true`	Registration requires the matching secret returned from the issued endpoint reference.
`true`	`false`	Legacy registration behavior; the returned secret is not enforced.

Although no server restart is required, enabling the attribute while distributed transactions are in progress can therefore reject registrations that use coordination contexts issued before enablement. Plan a production enablement around the lifetime of outstanding WS-AT transactions, or drain them before changing the setting.

In a cluster or mixed-version environment, ensure that every server that may act as the WS-AT coordinator has the update and observes the intended domain configuration before relying on this protection.

Potential Impacts

Applications are most likely to notice this setting when they use:

WS-AT transactions between WebLogic Server and a non-WebLogic transaction participant.
A custom WS-Coordination or WS-AT client stack.
An intermediary, gateway, SOAP handler, or message transformation that reconstructs endpoint references.
Code that manually creates a WS-AT Register message instead of invoking the RegistrationService endpoint reference supplied in the coordination context.
Long-running transactions whose coordination contexts can remain outstanding while the attribute is changed.
Mixed-version deployments in which different participants handle WS-Addressing reference parameters differently.

A participant does not need to interpret or modify the registration-secret value. It must preserve the supplied RegistrationService endpoint reference and return its reference parameters when invoking that endpoint. A client or intermediary that drops the registration-secret reference parameter will fail registration on the non-issued-token path when the attribute is enabled. A valid security-context credential whose AppliesTo value identifies the transaction satisfies the authorization check without requiring the registration secret.

Ordinary local JTA transactions and applications that do not use WS-AT are not affected.

After the attribute is enabled, an affected application or integration may experience:

A SOAP fault from a WS-AT 1.0 or 1.1 registration endpoint.
An HTTP 500 response carrying the registration SOAP fault.
Failure to enlist a remote durable participant.
Failure to register a volatile participant.
A distributed transaction that is marked for rollback or cannot complete as expected.
A Web-service or transaction exception reported before the participant receives prepare, commit, or rollback callbacks.
Success with newly created transactions but failure for transactions whose contexts were issued before enablement.
Success between some participant implementations and failure with another implementation that drops WS-Addressing reference parameters.

Because registration is rejected before the participant endpoint is recorded, the participant should not receive a transaction-completion callback for the rejected registration.

Mitigate the Effects of the Enabled Setting

Inventory applications and integrations that use WS-AT 1.0 or 1.1, including non-WebLogic participants and custom transaction bridges.
Verify that each participant invokes the exact RegistrationService endpoint reference supplied in the coordination context.
Verify that SOAP handlers, gateways, and intermediaries preserve WS-Addressing reference parameters, including unknown vendor-specific parameters.
Protect coordination contexts in transit with transport or message protections appropriate for the deployment. Possession of the registration secret is sufficient proof on the legacy path.
Apply the supporting update consistently to every server that may coordinate WS-AT transactions.
Drain or allow outstanding WS-AT transactions to complete before enablement so that later registrations do not use contexts issued without a secret.
In a representative test environment, enable the attribute and exercise both WS-AT 1.0 and 1.1 transactions.
Confirm that normal durable and volatile participant registration succeeds and that prepare, commit, rollback, timeout, recovery, and clustered-routing behavior remains correct for the deployment.
On the non-issued-token path, confirm that registration requests with a missing or changed secret are rejected before the participant endpoint is registered.
Monitor registration faults and DebugWSAT output during rollout, taking care not to log the secret itself.

Troubleshooting Issues

When the attribute is enabled and the request follows the non-issued-token path, a missing, unknown, or mismatched registration secret causes a WebServiceException containing text similar to:

unknown context identifier:<transaction-identifier>

The registration endpoint normally returns this failure as a SOAP fault, commonly with HTTP status 500.

When DebugWSAT is enabled, the coordinator can also report:

the registration message does not match an exported coordination context

If issued-token enforcement is enabled and the request lacks the required token, the failure instead contains:

no required issuedToken in the incoming soap message!

unknown context identifier is not sufficient by itself to prove that this attribute caused a failure. The same general error can also result from an invalid transaction identifier or a security-context credential whose AppliesTo value does not match the transaction.

To determine whether the attribute caused the issue, perform the following steps:

Confirm the live value of WSATRegistrationSecretEnabled on the domain's FeatureCompatibilityMBean.
Identify the server acting as the WS-AT coordinator and confirm that the failure occurs while processing a WS-AT Register request, rather than during the original application call or a later prepare, commit, or rollback callback.
Determine whether WS-AT issued-token enforcement is enabled. If the exception reports a missing issued token, diagnose that configuration before investigating the registration-secret path.
Determine when the coordination context was created. A context exported before the attribute was enabled does not contain the registration secret required after enablement.
Without recording its value, confirm whether the RegistrationService endpoint reference in the exported context contains a wls-wsat:registrationSecret reference parameter.
Without exposing its value, confirm whether the participant's Register request returns that reference parameter as an inbound SOAP header. If it is absent, inspect the participant stack, SOAP handlers, gateways, and other intermediaries for endpoint-reference reconstruction or header filtering.
Enable DebugWSAT temporarily and look for the message indicating that the registration did not match an exported coordination context.
Check all coordinator-capable servers for a consistent patch level and active domain configuration. Intermittent behavior can indicate that only some servers are applying the gate or that different participant implementations are being selected.
In a controlled environment, create a new transaction and export a new coordination context after setting the attribute to true. Verify that an unmodified participant can register successfully. Do not reuse an older context for this comparison.
As a final controlled comparison, set only this attribute to false, create another new transaction, and repeat the same registration. If the operation succeeds only while the attribute is disabled, this gate is the likely compatibility boundary.

Do not print or compare registration-secret values in shared logs, support bundles, or command output. Presence, propagation, and the server's match or mismatch result are sufficient for normal diagnosis.

CrossDomainT3SConnectionTrustValidationEnabled

The FeatureCompatibilityMBean.CrossDomainT3SConnectionTrustValidationEnabled controls whether new outbound cross-domain T3S or Administration Server requests must use a connection initiated by the sending server. Establishing that connection applies the sending server's outbound SSL trust configuration to the destination server's certificate.

The distinction matters because an established T3S connection can carry messages in both directions. A server that accepts a connection from another domain can otherwise reuse that connection to initiate calls back to the other domain, without establishing an outbound SSL connection of its own.

Note:

If you do not see this feature gate, confirm that you have applied the latest available Patch Set Update (PSU) or Critical Security Patch Update (CSPU). Security fixes and their feature gates are delivered on an as-needed basis through PSUs and CSPUs to ensure that your system is protected against vulnerabilities. To determine when this feature gate was delivered, see Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

Connections to trusted servers recognized as belonging to the same domain retain their existing reuse behavior. Peers with unknown domain identity, or whose same-domain identity is not trusted, are also subject to the locally initiated connection requirement. A matching domain-name string alone does not establish trusted same-domain identity.

Here, trust in a server's WebLogic identity and trust in its SSL certificate serve different purposes. Recognition of a trusted same-domain server determines whether the connection-reuse restriction applies. Outbound SSL trust configuration determines whether a new secure connection can be established.

CrossDomainT3SConnectionTrustValidationEnabled affects server-to-server communication using secure T3, including:

Cross-domain JNDI lookups over T3S
WebLogic RMI and EJB invocations over T3S
Server requests using the secure Administration Server protocol
Application or product activity that initiates a new invocation in the reverse direction over an existing cross-domain connection

The attribute does not change plain T3, HTTPS, or IIOP connection selection. It does not change application authentication, authorization, or the contents of an invocation. Connections to standalone clients are outside this server-peer selection rule.

A response to an existing request and a new invocation in the reverse direction are different operations. Replies may use the established request connection. A new server-to-server invocation is subject to the outbound connection requirement even when it occurs while processing an incoming request.

Property	Value
Type	Boolean
Default	`true`
Dynamic	No. Changes require a server restart.
Scope	Domain-level configuration. Each server uses the value captured at its startup.
Primary area	Connection selection for outbound cross-domain T3S and Administration Server requests.

When CrossDomainT3SConnectionTrustValidationEnabled is set to true, WebLogic Server does not select an accepted cross-domain connection for a new outbound server request. It selects a suitable locally initiated connection or attempts to establish one.

When a new connection is established, the destination's certificate must satisfy the initiating server's SSL trust configuration. Other connection requirements, including the configured hostname-verification policy and network reachability, continue to apply.

An existing suitable locally initiated connection can be reused. The attribute does not require a new SSL handshake for every invocation or certificate revalidation for every message.

Replies to incoming cross-domain requests can use their original request connection, including after an outbound connection has been established. Receiving a request does not, by itself, require the receiving server to establish a reverse connection merely to send its response.

For example, consider two domains, D1 and D2, with certificates issued by different certificate authorities:

D1 trusts the certificate presented by D2.
D2 does not trust the certificate presented by D1.

The resulting behavior is:

Operation	Behavior with the attribute enabled
D1 establishes a T3S connection to D2 and sends a request	The connection can succeed because D1 trusts D2, provided the other connection and application checks pass.
D2 sends the response to that request	D2 can reply over the existing D1-to-D2 connection.
D2 initiates a new invocation to D1	D2 must use a locally initiated connection. Establishing that connection fails certificate trust validation if D2 does not trust D1.
D2 initiates a new invocation after its SSL trust configuration has been corrected and applied	The connection can succeed if certificate validation, network connectivity, and the other applicable checks pass.

For applications that initiate calls in both directions, configure the servers in each domain to trust the destination certificates they encounter in the other domain.

Trust in both directions does not, by itself, mean that two-way SSL client-certificate authentication is required. The relevant check here is validation of the destination server's certificate whenever a server initiates an outbound SSL connection.

When CrossDomainT3SConnectionTrustValidationEnabled is set to false at server startup, WebLogic Server preserves legacy connection selection. A server can reuse an accepted cross-domain connection for a new reverse invocation when the existing connection-selection rules permit it.

This can allow reverse calls to succeed without a separate outbound SSL handshake in that direction. It does not guarantee that all such calls will succeed: if no reusable connection is available, establishing a new connection still requires the normal SSL and connectivity checks.

Disabling the attribute does not disable SSL encryption, application authentication, authorization, or certificate validation on newly established SSL connections.

Use the disabled setting when legacy connection-reuse compatibility is required. Where possible, correct the outbound trust and connectivity configuration so that the application can operate with the attribute enabled.

Potential Impacts

Applications are most likely to notice the enabled behavior when they:

Communicate between domains with different certificate authorities or trust stores.
Configure trust in only one direction but initiate JNDI, RMI, or EJB calls in both directions.
Depend on the first connection established by one domain to carry new invocations initiated by the other domain.
Permit network connections in only one direction, or advertise server addresses that cannot be reached from the other domain.
Communicate with peers whose same-domain identity cannot be established as trusted.

A request and its reply can succeed while a subsequent reverse invocation fails. This is consistent with the setting: the reply can use the established request connection, while the reverse invocation requires an eligible outbound connection.

Troubleshooting Issues

A failed outbound SSL connection can produce an underlying exception such as:

javax.net.ssl.SSLHandshakeException

Certificate-chain problems can include diagnostic text such as:

PKIX path building failed

The exception reported to the application depends on the operation. A JNDI lookup may report a naming or communication exception; an RMI or EJB invocation may report a remote-call or connection exception. Inspect the complete exception chain and the initiating server's SSL diagnostics.

These messages are not unique to this attribute. The same certificate problem can prevent any fresh outbound SSL connection. The attribute can expose a previously hidden trust problem by preventing reuse of a connection accepted from the other domain.

If the new outbound connection cannot reach the destination, the visible failure may instead be a connection refusal, timeout, or address-resolution error. Correct certificate trust alone does not resolve those network or addressing problems.

To determine whether the attribute caused the issue, perform the following steps:

Identify the server initiating the failing invocation and the destination server. Establish whether the operation is a reply to an existing request or a new invocation in the reverse direction.
Check the attribute in the initiating server's domain configuration and determine the value captured at its most recent startup. Do not assume that activating a configuration edit changed a running server's policy.
Confirm the protocol and connection direction. This setting concerns secure T3S and Administration Server requests. Check whether earlier successful traffic depended on a connection originally established by the other domain.
Inspect the initiating server's exception chain and SSL diagnostics. Check the certificate presented by the destination, its validity and chain, the applicable trust configuration, and hostname verification.
Check the destination address and port as seen from the initiating server. Verify that routing, firewall rules, and advertised addresses permit an outbound connection in that direction.
In a controlled test environment, compare the same operation with the attribute enabled and disabled, restarting the affected server after each configuration change. Re-establish the initial forward connection and recreate application connection references before testing the reverse invocation.
If the reverse invocation succeeds only with legacy reuse, investigate the trust or connectivity requirement exposed by the locally initiated connection. After correcting that configuration, repeat the test with the attribute enabled.

When changing certificates or trust configuration during a comparison, also ensure that connections established under the previous configuration are no longer being reused. Follow the restart or connection-recreation requirements for those SSL configuration changes separately.

Relationship to T3RouteOnlyToTrustedServersEnabled

CrossDomainT3SConnectionTrustValidationEnabled governs selection of accepted versus locally initiated secure connections for outbound server requests.

T3RouteOnlyToTrustedServersEnabled governs whether an intermediate WebLogic Server may establish an indirect T3 route to a destination it recognizes. A supported routed invocation can be subject to both policies. Changing one attribute does not configure SSL trust or satisfy the routing requirements controlled by the other.

IIOPTypedReadResolveProxyValidationEnabled

The FeatureCompatibilityMBean.IIOPTypedReadResolveProxyValidationEnabled attribute controls when WebLogic Server verifies that the class carried in an IIOP message is compatible with the expected Java type.

Note:

If you do not see this feature gate, confirm that you have applied the latest available Patch Set Update (PSU) or Critical Security Patch Update (CSPU). Security fixes and their feature gates are delivered on an as-needed basis through PSUs and CSPUs to ensure that your system is protected against vulnerabilities. To determine when this feature gate was delivered, see Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

When WebLogic Server reads a value from an IIOP message, it often knows the Java type that the application or protocol expects. For example, a remote method's signature might declare that a parameter is a Report object or that its return value implements a particular interface.

Java serialization also supports a pattern in which the object placed on the wire is a temporary wrapper. After the wrapper is read, its readResolve() method replaces it with the object the application actually receives. A corresponding writeReplace() method is commonly used on the sending side.

For example, consider a remote method that declares an interface named ReportService, but the IIOP message contains a wrapper named ReportServiceProxyDescription. The wrapper does not implement ReportService; its readResolve() method creates a dynamic proxy that does.

Property	Value
Type	Boolean
Default	`true`
Dynamic	Yes. After the configuration change is activated, subsequent typed IIOP values are read using the new setting, including values received over an existing connection.
Primary area	Typed IIOP valuetype unmarshalling

When IIOPTypedReadResolveProxyValidationEnabled is set to true, WebLogic Server normally verifies that the class identified in the IIOP message is assignable to the expected Java type before reading its serialized state. A narrowly defined exception permits validated WebLogic EJB remote-business proxies, as described below.

Except for the validated WebLogic EJB proxy path, if the wire class does not implement or extend the expected type, WebLogic Server rejects it before:

Allocating an instance of the class
Reading the object's serialized state
Invoking its readResolve() method
Passing the value to application code

IIOPTypedReadResolveProxyValidationEnabled=true does not prohibit all uses of readResolve(). If the wire class itself is compatible with the expected type, WebLogic Server can still read the object and invoke readResolve(). The object returned by readResolve() must also be compatible with the expected type.

With strict validation enabled, WebLogic Server can reconstruct its EJB remote-business proxy from weblogic.iiop.ProxyDesc or a generated Java proxy class. This path requires the WebLogic remote-business invocation handler, a locally resolved business interface compatible with the expected interface, and the weblogic.ejb.spi.BusinessObject marker interface. WebLogic Server validates the handler metadata, remote-object reference, interface identities, and completed proxy. This exception does not admit arbitrary application invocation handlers or general serialization-proxy wrappers.

When IIOPTypedReadResolveProxyValidationEnabled is set to false, WebLogic Server preserves several legacy compatibility cases in which the class on the wire is not compatible with the expected type but is intended to produce a compatible object through readResolve(). In the ReportService example, WebLogic Server may read the wrapper, run readResolve(), and then verify that the resulting proxy implements ReportService.

These cases include:

A Java dynamic proxy represented on the wire by weblogic.iiop.ProxyDesc
JMX MBeanInfo represented by weblogic.corba.utils.MarshalledObject
A custom serialization wrapper whose class defines readResolve()

WebLogic Server reads the wrapper, invokes readResolve(), and then verifies the type of the resulting object.

The disabled behavior does not accept an incompatible final value. Regardless of this attribute, the object produced after deserialization and readResolve() must be assignable to the expected Java type.

Potential Impacts

This attribute affects typed CORBA valuetypes read by WebLogic Server's IIOP implementation.

It can apply when WebLogic Server:

Reads parameters from an incoming IIOP request
Reads the return value from an outbound IIOP invocation
Reads an exception or other protocol value with a known expected type
Reads a typed value from recognized IIOP protocol metadata
Reads a dynamic proxy or serialization wrapper sent as an IIOP valuetype

It does not directly affect:

T3 serialization
HTTP requests
JMS message bodies
Java serialization performed outside the IIOP implementation
Ordinary non-proxy values whose wire class already implements or extends the expected type
Values read without a specific expected Java type
Ordinary broad values carried through an IIOP Any, such as many values declared as Object, Serializable, or Externalizable, when the Any type does not identify a proxy

An Any whose type identifies ProxyDesc or a Java proxy is handled separately from the typed EJB proxy path. With strict validation enabled, its root wire class must be ProxyDesc or compatible with that proxy type. Regardless of this setting, a non-null result must resolve to a dynamic proxy. Other IIOP type and class checks continue to apply.

An application or integration is more likely to be affected if it sends any of the following through IIOP:

Java dynamic proxies as interface-typed parameters or return values that do not satisfy the validated WebLogic EJB proxy requirements
Custom serialization-proxy classes using writeReplace() and readResolve()
Wrapper objects that intentionally resolve to a different application type
Classes or enums whose writeReplace() method substitutes an unrelated holder class
JMX MBeanInfo between WebLogic Server instances using the Java-serialization form of JMX-over-IIOP
Vendor-generated proxy or holder classes that are not assignable to the declared Java type

Applications using ordinary serializable classes are generally unaffected when the concrete class on the wire implements or extends the type declared in the remote method signature.

Where the Setting Is Applied

The attribute is evaluated in the WebLogic Server process that is reading the value.

For an incoming request:

IIOP client → WebLogic Server
              setting is applied here

The receiving server's value controls how request parameters are validated.

For a WebLogic Server making an outbound IIOP call:

WebLogic Server → remote IIOP service (request)
WebLogic Server ← remote IIOP service (reply)
setting is applied when this server reads the reply

The calling WebLogic Server's value controls how it validates the returned value.

A standalone client is not controlled by the server's FeatureCompatibilityMBean when it reads a reply. However, the receiving WebLogic Server still applies its setting when that client sends request parameters.

In a cross-domain server-to-server call, the two domains can therefore apply different behavior depending on which server is reading a request or reply.

Mitigate the Effects of the Enabled Setting

Inventory applications and server-to-server integrations that use IIOP.
Identify remote method parameters and return values declared as interfaces or concrete application types.
Look for custom writeReplace() or readResolve() methods in classes sent as values of those declared types.
Identify uses of java.lang.reflect.Proxy passed as IIOP valuetypes.
Review server-to-server JMX-over-IIOP communication.
Test both the request and reply directions for each affected integration.
Prefer a wire class that implements or extends the type declared by the remote method.
For a custom serialization-proxy pattern, consider declaring the wrapper explicitly in the remote contract and converting it in application code rather than relying on an unrelated wire class to resolve automatically.
For dynamic remote interfaces, use the supported RMI-IIOP remote-object representation or the validated WebLogic EJB remote-business proxy path. General Java dynamic proxies with application-supplied handlers do not satisfy the strict typed EJB proxy requirements.
If JMX-over-IIOP is affected, review whether the sending server should use the non-Java-serialization representation for JMX metadata instead of the MarshalledObject wrapper.

The most reliable long-term correction is to make the type carried in the IIOP message compatible with the type declared in the remote contract.

Troubleshooting Issues

You may encounter the following behavior after enabling IIOPTypedReadResolveProxyValidationEnabled.

Failure While Reading a Request

If WebLogic Server rejects an incoming parameter, the request fails before the target application method is invoked.

The caller may receive a CORBA MARSHAL exception, an RMI unmarshalling exception, or a remote invocation exception. Application logging at the beginning of the target method will not appear because the invocation was never dispatched.

Failure While Reading a Reply

If a WebLogic Server rejects a return value, the remote method may already have completed successfully. Only the caller's attempt to decode the reply has failed.

This distinction is important for operations that change data or have other side effects. Do not automatically retry a failed operation merely because the caller reported an unmarshalling error. First determine whether the remote method completed; otherwise, a retry could perform the operation a second time.

Expected Error Information

When strict validation rejects the wire class before readResolve(), WebLogic Server reports a CORBA MARSHAL exception with an underlying InvalidClassException. The cause contains:

<wire-class>; Resolved valuetype is not assignable to <expected-class>

For example:

com.example.ReportServiceProxyDescription; Resolved valuetype is not assignable to com.example.ReportService

The class before the semicolon is the class actually carried in the IIOP message. The class at the end is the type WebLogic Server expected.

A rejected proxy can instead report a validation-specific cause, such as Typed proxy handler is not the WebLogic remote-business handler or Typed proxy descriptor does not match the validated EJB handler. A proxy-hinted Any can report Any proxy value must resolve to a dynamic proxy. These messages identify different validation stages and should not be diagnosed solely as a failure of the ordinary wire-class assignability check.

There is a similar but distinct error that can occur after readResolve():

<resolved-class>; Resolved valuetype value is not assignable to <expected-class>

The word value is significant:

Resolved valuetype is not assignable indicates that the wire class failed the early check controlled by this attribute.
Resolved valuetype value is not assignable indicates that deserialization completed but the final object had the wrong type. That final check applies even when this attribute is false.

To determine whether the attribute caused the issue, perform the following steps:

Confirm that the failing communication uses IIOP or IIOPS.
Identify which WebLogic Server process was reading the failing value.
Check that server's runtime value of IIOPTypedReadResolveProxyValidationEnabled.
Review the complete CORBA or RMI exception chain.
Look for Resolved valuetype is not assignable to or a proxy-validation cause described above.
Record both the wire class and the expected class from the exception.
Examine the remote method signature or protocol definition to determine why that expected type was used.
Check whether the wire class defines readResolve() or was produced by another object's writeReplace() method.
Check specifically for weblogic.iiop.ProxyDesc or weblogic.corba.utils.MarshalledObject.
Determine whether the failure occurred while reading a request or while reading a reply.
If more detail is required, temporarily enable DebugIIOPDetail and DebugIIOPTransport on the server reading the value.

In a controlled environment, change the attribute dynamically and repeat the same operation. If the value is accepted with the attribute set to false but fails with Resolved valuetype is not assignable to when set to true, this attribute is the cause.

For a reply failure, verify whether the remote operation completed before repeating the test.

IIOPUnauthenticatedServiceContextValueTypeFilteringEnabled

The FeatureCompatibilityMBean.IIOPUnauthenticatedServiceContextValueTypeFilteringEnabled attribute controls whether WebLogic Server applies its unauthenticated deserialization allowlist while reading valuetypes from incoming IIOP request and reply service contexts.

Note:

If you do not see this feature gate, confirm that you have applied the latest available Patch Set Update (PSU) or Critical Security Patch Update (CSPU). Security fixes and their feature gates are delivered on an as-needed basis through PSUs and CSPUs to ensure that your system is protected against vulnerabilities. To determine when this feature gate was delivered, see Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

IIOP requests and replies can carry protocol metadata called a service context, in addition to application arguments, return values, or exceptions. Service contexts are used for information such as transaction propagation, caller information, protocol capabilities, and vendor-specific ORB data.

Some recognized service contexts contain CORBA valuetypes. In this context, a valuetype represents a serializable Java object in an IIOP message.

For this attribute, "unauthenticated" identifies the allowlist applied while WebLogic Server decodes service-context data; it does not describe the eventual authentication status of the peer.

For an incoming request, service contexts are decoded early, before WebLogic Server has finished establishing the caller’s identity and before it dispatches the request to the application. Therefore, this filtering can apply even when:

The caller supplied valid credentials
The application method requires an authenticated user
The request arrived over an encrypted connection
The caller would eventually be recognized as another WebLogic Server

The term 'unauthenticated' does not mean that the application is configured to permit anonymous access. The same allowlist also applies when a WebLogic Server acting as a client reads service contexts in an IIOP reply.

Property	Value
Type	Boolean
Default	`true`
Dynamic	Yes. After the configuration change is activated, the new value is used when subsequent IIOP request or reply service contexts are decoded.
Primary area	Incoming IIOP request and reply service contexts

When IIOPUnauthenticatedServiceContextValueTypeFilteringEnabled is set to true, WebLogic Server checks each Java class encountered while decoding a valuetype within an incoming request or reply service context.

The check occurs before WebLogic Server constructs and reads the object. Nested valuetypes are checked as they are encountered, so permitting only the top-level class might not be sufficient when that class contains objects of other types.

Standard WebLogic Server protocol classes and commonly required core Java classes are included in the default unauthenticated filter. A custom class supplied by an application, ORB, transaction manager, or integration might not be included.

If a class is not permitted, WebLogic Server stops decoding the message. It does not discard only that service context and continue. A rejected request fails before the target application method is called. A rejected reply fails at the calling server, after the remote method may already have completed.

When IIOPUnauthenticatedServiceContextValueTypeFilteringEnabled is set to false, WebLogic Server preserves the earlier IIOP service-context unmarshalling behavior and does not apply the unauthenticated allowlist specifically to this portion of the request or reply.

Disabling the attribute does not disable all serialization filtering in WebLogic Server. Other class-loading rules, object-input filters, type checks, and protocol validation continue to apply.

Potential Impacts

This attribute affects:

Incoming IIOP requests and replies received by WebLogic Server
Recognized request and reply service contexts that contain Java valuetypes
The classes nested inside those service-context valuetypes
All supported GIOP request and reply versions processed by WebLogic Server

It can affect specialized integrations that propagate WebLogic or vendor-specific transaction, identity, or other protocol metadata through IIOP.

It does not directly affect:

Ordinary application method arguments
Application return values
T3 requests
HTTP requests
JMS message bodies
Java serialization elsewhere in the server
Service contexts that WebLogic Server retains only as opaque bytes

A third-party ORB adding an unknown service context as an uninterpreted byte sequence is not automatically affected. Filtering occurs when WebLogic Server recognizes the context and invokes its valuetype decoder.

Applications Most Likely to Be Affected

Ordinary IIOP applications that pass custom serializable objects only as method arguments generally are not affected by this attribute. Those objects are outside the service-context portion of the request.

An application or integration is more likely to be affected if it uses:

A non-WebLogic ORB that supplies a custom class within a service context recognized by WebLogic Server
A custom transaction integration that places a proprietary object in propagated transaction metadata
A custom subclass or replacement for a WebLogic protocol metadata class
An IIOP interceptor or integration layer that reuses a recognized service-context identifier and encodes a Java valuetype in it
A layered Oracle or third-party product that extends WebLogic IIOP service-context behavior with additional Java classes

Standard WebLogic Server clients normally send protocol classes already accepted by the default filter.

Troubleshooting Issues

When a required class in a request service context is rejected, the request fails before the application method is invoked. If the rejection occurs in a reply service context, the calling WebLogic Server cannot decode the reply, but the remote method may already have run.

The caller may receive:

A CORBA MARSHAL exception
An RMI unmarshalling or remote invocation exception containing a CORBA exception
A COMM_FAILURE, end-of-file, or connection-reset error if the request cannot be completed cleanly
A transaction-propagation or remote-call failure reported by a higher-level framework

For a request rejection, application logging placed at the beginning of the target method will not run because the request fails before dispatch. For a reply rejection, check whether the remote operation completed before retrying it, especially if it changes data or has other side effects.

Failures can depend on the peer. Requests or replies from one ORB or integration product may fail while others succeed because they send different service-context metadata.

Expected Error Information

The server-side exception is a CORBA MARSHAL exception whose underlying cause is an InvalidClassException. The cause includes the rejected class name and the following text:

Rejected by unauthenticated IIOP valuetype filter

For example, the cause can resemble:

com.example.orb.CustomContext;
Rejected by unauthenticated IIOP valuetype filter

This exact phrase is the clearest indication that IIOPUnauthenticatedServiceContextValueTypeFilteringEnabled caused service-context decoding to fail.

Review the complete exception chain in the WebLogic Server process that is reading the message: the receiving server for a request, or the calling server for a reply. A remote client might receive only a higher-level CORBA or RMI exception.

To determine whether the attribute caused the issue, perform the following steps:

Confirm that the failing client is using IIOP or IIOPS.
Identify whether the failure occurred while reading a request or a reply. Confirm the current runtime value of IIOPUnauthenticatedServiceContextValueTypeFilteringEnabled on the WebLogic Server reading that message.
Review the complete server-side exception and look for Rejected by unauthenticated IIOP valuetype filter.
Record the class name reported immediately before that text.
Determine which ORB, transaction manager, interceptor, or integration component supplies that class.
Check whether the target application method was entered. If it was, this filter did not reject that request before dispatch, but it can still reject the reply service contexts.
Compare successful and failing peers to determine whether only one ORB or integration sends the additional request or reply service context.
If more protocol detail is needed, temporarily enable DebugIIOPDetail and DebugIIOPTransport on the server reading the message.

In a controlled environment, change the attribute dynamically and repeat a safe IIOP operation. If decoding succeeds with the attribute set to false but fails with Rejected by unauthenticated IIOP valuetype filter when set to true, the enabled filter caused the rejection. Before repeating an operation after a reply failure, determine whether the remote operation already completed.

A generic CORBA MARSHAL exception is not sufficient by itself to identify this attribute. IIOP can report MARSHAL for many unrelated data-format and type errors.

Addressing a Legitimate Class Rejection

If a legitimate integration depends on a custom service-context valuetype:

Identify the rejected top-level class and all custom classes reachable from it.
Determine whether the client or integration can use standard WebLogic Server service-context classes instead.
Check whether the client is using a recognized service-context identifier for data that could be carried as an opaque vendor context instead.
Review any explicitly configured weblogic.oif.serialUnauthenticatedFilter setting.
If the custom class must be permitted, add only the required class or narrowly scoped class pattern to the unauthenticated filter.
Restart servers if the filter is supplied as a server startup property.
Retest the operation with the feature attribute enabled.

Avoid adding a broad package pattern merely to make the exception disappear. The exception identifies the first rejected class; after permitting it, another nested class may be reported and require separate evaluation.

JAXWSRejectUnknownSEIOperationsEnabled

The FeatureCompatibilityMBean.JAXWSRejectUnknownSEIOperationsEnabled attribute controls how WebLogic Server handles an incoming SOAP request whose operation cannot be resolved to a method in the JAX-WS service endpoint interface (SEI).

Note:

If you do not see this feature gate, confirm that you have applied the latest available Patch Set Update (PSU) or Critical Security Patch Update (CSPU). Security fixes and their feature gates are delivered on an as-needed basis through PSUs and CSPUs to ensure that your system is protected against vulnerabilities. To determine when this feature gate was delivered, see Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

A JAX-WS SEI describes the Java methods exposed by a Web service. For an incoming SOAP request, WebLogic Server attempts to resolve the request to an SEI method and its method-level authorization resource.

The relevant request path is:

SOAP request reaches a JAX-WS SEI endpoint.
1. AuthorizationTube checks for an applicable WS-ReliableMessaging (WS-RM) or MakeConnection protocol control request.
2. Otherwise, it resolves the request to an SEI method and resource:
  - Resource found: perform normal method-level authorization.
  - No resource and attribute is true: return an Invalid operation fault.
  - No resource and attribute is false: invoke downstream tubes without method-level authorization for that operation.

The protected case is an operation that cannot be resolved to an SEI method, such as a SOAP body operation QName that is not in the endpoint's SEI. The check also applies if method lookup does not yield an authorization resource. When enabled, it rejects the request before downstream tubes, including the WorkContext-processing path, are invoked.

This attribute does not:

Change authorization for a recognized SEI method with a mapped resource.
Apply this SEI-specific check to a JAX-WS Provider endpoint, which uses a separate provider resource.
Turn an otherwise invalid operation into a valid SEI method.
Replace WS-Security, transport authentication, method authorization, or other Web-service checks.
Control WorkContext input on other transports or on requests that take another processing path.

When WS-ReliableMessaging or MakeConnection is enabled, its protocol-control requests have their own classification and processing path. This gate is not a general rejection switch for those protocol messages; their protocol tubes remain responsible for validating and consuming them.

Property	Value
Type	Boolean
Default	`true`
Dynamic	Yes
Scope	Domain-wide. Evaluated by the server-side JAX-WS authorization tube for endpoints backed by an SEI.

When JAXWSRejectUnknownSEIOperationsEnabled is set to true, a request with no mapped SEI authorization resource receives an Invalid operation SOAP fault before the authorization tube invokes downstream tubes. A request with a valid, mapped operation continues through the existing method-level authorization check.

The fault string begins with Invalid operation and, when a SOAP body operation is available, includes its local name and possibly its namespace. The fault uses:

SOAP 1.1: a Client fault code.
SOAP 1.2: a Sender fault code with an InvalidOperation subcode.

The HTTP binding commonly exposes the SOAP fault with HTTP status 500, but diagnose the SOAP fault rather than relying on the HTTP status alone. This is an invalid-operation fault, not the separate Access denied to operation fault used when authorization denies a recognized method.

Enabling JAXWSRejectUnknownSEIOperationsEnabled prevents an unresolved SEI operation from using the legacy authorization-tube fall-through to reach downstream processing, including the WorkContext path, without a method-level authorization resource. It closes that specific path while retaining the normal processing of recognized operations.

It does not prove that a recognized method is safe, authenticate a caller, validate WorkContext data on every path, or replace protocol-specific controls. The authorization tube still performs some processing before this check, and WS-RM/MakeConnection control messages take their separate protocol path. Disabling the gate restores the legacy fall-through and should be treated as a security-reducing compatibility choice, not as a routine interoperability setting.

When JAXWSRejectUnknownSEIOperationsEnabled is set to false, it restores the legacy path for an unmatched SEI operation. The authorization tube skips its invalid-operation rejection and, because it has no method resource, also skips the method-level authorization decision for that operation. It then invokes the next tube.

This does not guarantee that the request succeeds. A later tube, SOAP dispatcher, or application layer may still reject it. It does mean that the request can reach downstream processing that the default check would have stopped, including WorkContext processing. The legacy path can therefore restore the pre-authentication exposure addressed by the original security fix. Use false only as a temporary, explicitly accepted compatibility exception while correcting the client or integration.

Disabling this attribute does not relax authorization for recognized SEI methods; those still have a mapped resource and undergo the normal authorization check.

Dynamic Behavior and Mixed-Version Domains

The authorization tube reads the effective domain attribute when it processes a request that reaches the unknown-operation check. A committed change therefore affects subsequent requests without restarting the server. It cannot change a request that has already passed that point in the tube.

Every server that may receive the affected SOAP traffic should have both the management-configuration update that defines the attribute and the WebServices runtime update that consumes it. During a staged or mixed-version rollout:

A server with only the new MBean/API but the older WebServices runtime can expose and store false while its authorization tube continues to reject unknown operations unconditionally.
A server with the new WebServices runtime but unavailable or older MBean/API symbols falls back to rejection rather than enabling the legacy path.
Servers with different effective values or patch levels can return different results for the same request.

Verify the effective value and installed runtime on every receiving server before relying on an opt-out. Keep the secure default while coordinating a rollout.

Potential Impacts

An integration is most likely to notice the default rejection if it sends a SOAP request to an SEI-backed endpoint but does not use an operation recognized by that endpoint. Examples include:

A stale generated client using an operation removed or renamed in the deployed service.
A hand-built SOAP message with the wrong body operation QName or namespace.
A gateway, intermediary, or handler that rewrites the SOAP body or operation-identifying information.
A client and endpoint deployed from different WSDL or SEI versions.
A diagnostic or probing client that intentionally sends an unknown operation.

Applications that send recognized operations should retain their usual authorization behavior. JAX-WS Provider endpoints do not use this SEI-specific unknown-operation decision.

Mitigate the Effects of the Enabled Setting

Identify SOAP clients, gateways, and handlers that call SEI-backed JAX-WS endpoints, including clients generated from older WSDL versions.
Compare the deployed service's WSDL and SEI with each client's operation name, namespace, and action. Regenerate or correct clients that issue unmatched requests.
Exercise representative requests for both valid and invalid operations. Verify that valid operations still receive their normal authorization decisions and invalid operations receive the expected SOAP-version-specific fault.
Apply both parts of the update consistently to every server that can host the endpoint, then verify the effective domain value and behavior on each server.
Keep the attribute at its default true. If an exception is unavoidable, document the affected client, endpoint, exposure, and plan to restore true; restrict untrusted access to the endpoint while the legacy path is in use.

Troubleshooting Issues

After the attribute is enabled, an affected client can receive an Invalid operation SOAP fault before its intended application method or downstream tube runs. A client may surface that fault as a SOAP exception or a Web-service invocation error. A SOAP 1.1 caller should see a Client fault; a SOAP 1.2 caller should see a Sender fault with an InvalidOperation subcode.

If the same malformed request is sent with the attribute disabled, the immediate invalid-operation fault may disappear, but a different downstream fault or failure can still occur. Do not treat the absence of that fault as proof that the request was authenticated, authorized, or safely processed.

To determine whether the attribute caused the issue, perform the following steps:

Check the effective JAXWSRejectUnknownSEIOperationsEnabled value on the domain's FeatureCompatibilityMBean. Confirm which server processed the request and that it has the WebServices runtime update.
Confirm that the target is an SEI-backed JAX-WS endpoint, rather than a Provider endpoint or a WS-RM/MakeConnection protocol-control request.
Compare the request's operation-identifying SOAP content with the deployed endpoint's current WSDL and SEI. Pay particular attention to the body operation QName and namespace; also check the SOAP action or WS-Addressing action used by the client where applicable.
Inspect the full SOAP fault. Invalid operation with the codes described above points to the unknown-operation branch; Access denied to operation indicates a separate authorization decision for a mapped method.
Check for a stale client stub, changed WSDL, intermediary transformation, or endpoint-version mismatch. Correcting the request is preferable to disabling the gate.
In a controlled test environment, send a new request after changing the attribute. If the early Invalid operation fault disappears only when the attribute is false, the enabled check caused the earlier rejection. Inspect any later response and server-side processing separately.
If the value is false but the same early rejection remains, check for an incomplete or mixed-version installation. The MBean can exist before the WebServices runtime consumer is installed, and a runtime unable to read the configuration falls back to rejection.

Do not use a production request carrying untrusted WorkContext data as a diagnostic probe. Test with a benign payload in an isolated environment.

SAML2StrictArtifactResolutionEnabled

The FeatureCompatibilityMBean.SAML2StrictArtifactResolutionEnabled feature gate controls whether WebLogic Server must authenticate a SAML 2.0 artifact-resolution requester before accessing the artifact cache. When enabled, it also requires WebLogic Server to verify that the requester is the artifact’s intended recipient before consuming it.

Note:

If you do not see this feature gate, confirm that you have applied the latest available Patch Set Update (PSU) or Critical Security Patch Update (CSPU). Security fixes and their feature gates are delivered on an as-needed basis through PSUs and CSPUs to ensure that your system is protected against vulnerabilities. To determine when this feature gate was delivered, see Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

The SAML 2.0 HTTP Artifact binding sends a short artifact through the browser instead of sending the SAML protocol message itself. The receiving partner then sends a back-channel SOAP ArtifactResolve request to the artifact resolution service that created the artifact. The service retrieves the one-time message associated with the artifact and returns it in an ArtifactResponse.

The normal sequence is:

WebLogic Server stores a SAML message for a configured partner.
The browser carries the artifact to that partner.
The partner sends a SOAP ArtifactResolve request.
WebLogic Server authenticates the requester.
WebLogic Server consumes the one-time artifact for its intended recipient.
WebLogic Server returns the SAML message in an ArtifactResponse.

When the attribute is enabled, WebLogic Server uses the request issuer to find enabled partner registrations, verifies all configured authentication requirements, and requires partner-bound proof through either a verified request signature or a partner-matched TLS client certificate. It then consumes the artifact only if its stored recipient and SAML message type match an authenticated partner in the correct identity provider or service provider role.

The attribute applies to both WebLogic Server artifact resolution routes:

A local identity provider artifact resolution service returning a stored authentication response to its requesting service provider partner.
A local service provider artifact resolution service returning a stored authentication request to its requesting identity provider partner.

This attribute does not:

Enable SAML 2.0 services or the HTTP Artifact binding.
Configure request signing, TLS client authentication, or Basic authentication for a partner.
Authenticate the browser user associated with the SAML exchange.
Change how artifacts are created, delivered through the browser, expired, or replicated.
Apply the domain MBean setting to a non-WebLogic, off-platform CSS installation.
Change SAML bindings or endpoints other than artifact resolution.

Property	Value
Type	Boolean
Default	`true`
Dynamic	Yes
Scope	Domain-wide. Evaluated for each SAML 2.0 `ArtifactResolve` request processed by a WebLogic Server service provider or identity provider artifact resolution service.

When SAML2StrictArtifactResolutionEnabled is set to true, WebLogic Server processes an ArtifactResolve request in this order:

It requires a nonempty Issuer, a nonempty artifact, and a parsed request document. If the issuer has a Format, the format must be the SAML entity format.
It uses the issuer value and the artifact resolution route to find candidate partner registrations. The candidates must be in the correct partner role, enabled, and have an entity ID exactly matching the issuer.
It applies the local artifact-request authentication settings to each candidate.
It verifies any supplied signature against that partner's configured SAML signing certificate. A required but absent signature fails authentication.
It requires the request to establish partner identity through a verified signature or, for an unsigned request, through configured TLS client authentication using the certificate registered for that partner.
Only after partner authentication succeeds does it ask the artifact store to consume the artifact conditionally.
The store removes and returns the artifact only when the stored recipient name belongs to one of the authenticated registrations and the stored message type is correct for the route.

The recipient and message-type check is part of the same atomic cache operation that consumes the artifact. A partner cannot consume an artifact intended for a different registration. Registrations in the service provider and identity provider namespaces also cannot consume each other's artifacts merely because they use the same partner name.

If authentication fails, the issuer does not identify an eligible partner, or the artifact belongs to another recipient, the SAML message is not returned. The artifact is not consumed by that rejected request and remains available for a correctly authenticated retry until it is successfully consumed or expires.

Requests containing unknown artifacts and requests that cannot authenticate as the intended recipient produce the same empty result. This avoids revealing whether a supplied artifact currently exists for another partner.

When the attribute is enabled ("strict mode"), WebLogic Server uses the existing local SAML 2.0 artifact-request settings, but it does not treat every configured credential as proof of partner identity.

Local or request condition	Enabled behavior
Artifact request signing is required	The request must contain a valid signature that verifies with the candidate partner's configured signing certificate.
Artifact request signing is not required, but a signature is supplied	WebLogic Server still verifies the supplied signature. An invalid supplied signature is rejected.
The request is unsigned	TLS client authentication must be configured, and the presented client certificate must match the transport-layer client certificate registered for the candidate partner.
TLS client authentication is configured	A matching partner certificate is required even when the request is signed.
Basic authentication is configured	The Basic credentials must be present and valid in addition to the partner-bound proof.
Basic authentication is the only configured credential	An unsigned request is rejected. The shared local Basic credentials do not identify a particular partner.

Strict mode therefore always requires at least one partner-bound mechanism: a verified SAML request signature or partner-matched TLS client authentication. When multiple authentication controls are configured or supplied, all applicable checks must pass.

SAML2StrictArtifactResolutionEnabled can protect the artifact cache by requiring partner authentication before access and by binding one-time consumption to an authenticated intended recipient and the correct partner role. It can also prevent a rejected authentication attempt from consuming an artifact that a legitimate partner can still redeem.

However, the setting does not prevent an authenticated intended recipient from consuming an artifact, including accidentally or maliciously. It also does not:

Protect an artifact before it reaches the artifact resolution service.
Encrypt artifacts or SAML messages.
Replace HTTPS, network access controls, or appropriate protection for private signing keys and client certificates.
Validate the identity or authorization of the end user represented by the SAML message.
Correct an inaccurate or compromised partner registration.
Apply strict behavior to other SAML bindings, SAML endpoints, or non-SAML protocols.
Make shared Basic credentials a partner-specific authentication mechanism.

When SAML2StrictArtifactResolutionEnabled is set to false, WebLogic Server preserves the legacy artifact-resolution order and authentication behavior. The legacy path retrieves and removes the one-time artifact from the cache before it identifies and authenticates the partner. It then uses the partner name stored with the artifact to obtain the partner registration, checks that the registration is enabled, applies configured Basic and TLS client authentication, and verifies a signature only when signing is locally required or the request contains a signature.

Consequently, in legacy mode:

A request that later fails partner lookup, authentication, or signature validation can already have consumed the artifact.
An unauthenticated or incorrectly authenticated caller that knows an artifact value can make that one-time artifact unavailable to its intended recipient.
An unsigned request can resolve an artifact when request signing and TLS client authentication are not required and any other configured checks pass.
Valid shared Basic credentials can satisfy the configured Basic check, but do not bind the request to the artifact's intended partner.
The request issuer is not used to select and authenticate the intended recipient before cache access.

Set SAML2StrictArtifactResolutionEnabled to false only when a legacy partner cannot send a signed ArtifactResolve request and cannot use partner-matched TLS client authentication. Disabling the attribute weakens both requester authentication and protection of one-time artifacts from premature consumption.

Mitigate the Effects of the Enabled Setting

WebLogic Server reads the live FeatureCompatibilityMBean.SAML2StrictArtifactResolutionEnabled value for each artifact resolution request. A committed change affects subsequent requests without a server restart. A request that has already selected the strict or legacy path continues on that path.

The setting does not alter an artifact when the artifact is created, so an artifact issued before a setting change can still be resolved after the change if it has not expired or been consumed. However, the request must satisfy the mode that is active when resolution occurs.

Important transition effects include:

Earlier request or state	Later state	Result
Strict mode rejects an unauthenticated request	A correctly authenticated retry arrives while strict mode remains enabled	The retry can consume the still-live artifact.
Strict mode rejects an unauthenticated request	The attribute is disabled before a retry	The same artifact can enter the legacy path if it is still live.
Legacy mode retrieves an artifact and later rejects the request	The attribute is enabled before a retry	The setting change cannot restore the artifact already consumed by the legacy request.
An artifact was created before strict mode was enabled	A valid signed or partner-TLS-authenticated request arrives after enablement	The artifact can be resolved because enforcement occurs at resolution time.

In a cluster or mixed-version environment, apply the supporting update consistently and verify the effective setting on every server that can process artifact resolution. Otherwise, the same integration can receive strict behavior on one server and legacy behavior on another. Artifact cache replication or routing does not replace consistent partner authentication configuration across those servers.

Potential Impacts

Applications and integrations are most likely to notice this setting when they use:

SAML 2.0 HTTP Artifact binding with WebLogic Server acting as either the identity provider or the service provider.
A partner that sends unsigned ArtifactResolve requests without TLS client authentication.
A partner that relies only on shared Basic authentication for artifact resolution.
A custom SAML stack that omits the issuer, sends a blank issuer, or uses a non-entity issuer format.
A partner whose entity ID, signing certificate, or TLS client certificate does not match its WebLogic Server partner registration.
Duplicate partner registrations that use the same issuer but have different names or certificates.
A proxy or TLS terminator that does not provide the expected client certificate to WebLogic Server.
A cluster in which partner registries, certificates, patch levels, or effective feature-compatibility values are inconsistent.

Applications that use only HTTP POST or HTTP Redirect bindings and never invoke the artifact resolution service are not affected by this setting.

With the attribute enabled, a legacy integration can experience:

An artifact resolution response that contains no embedded SAML protocol message.
A downstream single sign-on failure because the expected authentication request or response was not returned.
A service provider or identity provider error indicating that artifact requester authentication failed.
Repeated failure when a partner continues sending unsigned requests without partner-matched TLS client authentication.
Failure after certificate rotation when the sender and the WebLogic Server partner registration do not contain matching signing or TLS client certificates.
Success on one cluster member and failure on another when configuration or update levels differ.
An eventual HTTP error, such as a 403 response, at the surrounding SSO operation even though the artifact resolution service represented the rejected lookup with an empty ArtifactResponse.

A strict mode authentication failure does not consume an otherwise valid artifact. A later retry can therefore succeed after the requester corrects its signature, certificate, issuer, or other required credentials.

Before You Enable SAML2StrictArtifactResolutionEnabled

Before deploying the update or removing a temporary legacy override:

Inventory every SAML 2.0 partner that uses HTTP Artifact binding in either direction.
Configure each artifact requester to sign ArtifactResolve requests, or configure TLS client authentication with a certificate registered to the specific partner.
Prefer request signing when TLS is terminated before WebLogic Server and the original partner certificate cannot be delivered reliably to the server.
Verify that every WebLogic Server partner registration is enabled and contains the exact entity ID and current signing or transport-layer client certificate used by the requester.
If Basic authentication is also configured, verify that the requester continues to send the expected credentials in addition to its partner-bound proof.
Test both directions used by the deployment: an identity provider requesting an authentication request from the service provider artifact resolution service, and a service provider requesting an authentication response from the identity provider artifact resolution service.
Test missing signatures, invalid signatures, wrong TLS client certificates, wrong recipients, duplicate issuers, unknown artifacts, replayed artifacts, and correctly authenticated retries.
Confirm that rejected requests return no embedded SAML message and do not consume a valid artifact intended for a later authenticated retry.
Apply the supporting update and partner configuration consistently across all cluster members before relying on the protection.
Monitor SSO failures, empty artifact responses, BEA-096565, and feature-compatibility change notifications during rollout.

Troubleshooting Issues

For a request that fails strict artifact authentication, the underlying diagnostic text is:

Artifact requester authentication failed.

This text corresponds to message BEA-096565. The artifact resolution service returns an ArtifactResponse correlated to the request, with a top-level SAML status of Success but without the stored SAML message. The status message can contain the authentication-failure text. The same empty response shape is used when the artifact is unknown or is not owned by an authenticated candidate, so the response does not confirm whether the artifact exists.

Debug output can also indicate that an ArtifactResolve signature did not authenticate a candidate partner. A generic authentication failure does not by itself identify which prerequisite failed; inspect the issuer, partner state, signature, TLS client certificate, Basic credentials, and local authentication settings together.

Do not infer that strict mode is disabled merely because the top-level artifact response status is Success. For this path, the presence or absence of the embedded SAML message is the significant result.

To determine whether the attribute caused the issue, perform the following steps:

Confirm the live value of SAML2StrictArtifactResolutionEnabled on the domain's FeatureCompatibilityMBean.
Confirm that the failing integration uses SAML 2.0 HTTP Artifact binding and identify the server and route processing the SOAP ArtifactResolve request. Determine whether the local WebLogic Server artifact resolution service is returning an authentication request as a service provider or returning an authentication response as an identity provider.
Inspect the local SAML 2.0 settings for artifact request signing, TLS client authentication, and Basic authentication. Do not assume that disabling the explicit signing requirement permits an unsigned request in strict mode; unsigned requests require partner-matched TLS client authentication.
Verify that the request contains a nonblank issuer. If an issuer format is present, verify that it is the SAML entity format. Confirm that the issuer value exactly matches the entity ID of an enabled partner in the role appropriate for the endpoint.
For a signed request, verify that the signature is valid and that the partner registration contains the corresponding signing certificate. Strict mode verifies a supplied signature even when signing is not configured as required.
For an unsigned request, verify that TLS client authentication is enabled and that WebLogic Server receives a client certificate exactly matching the transport-layer client certificate configured for that partner. Check any proxy or TLS-termination layer that can remove or replace the certificate information.
If Basic authentication is configured, verify it separately. Correct Basic credentials are an additional requirement and are not a substitute for the request signature or partner-matched TLS client certificate.
Examine the ArtifactResponse. An empty response carrying Artifact requester authentication failed. is consistent with this protection, but the same response can represent an unknown artifact or a recipient mismatch.
In a controlled environment, retry the same still-live artifact with the issuer and partner-bound authentication corrected. Success on the authenticated retry, after an earlier empty response, is strong evidence that strict mode rejected the first request without consuming the artifact.
Check all artifact-resolution-capable servers for the supporting update, consistent partner configuration, and the same effective feature-compatibility value.
As a final controlled compatibility comparison, set only this attribute to false, issue a new artifact, and repeat the operation. Use a new artifact because a failed legacy-path request can consume the artifact before it reports the authentication failure. Restore the secure default after the comparison.

SerializedWorkContextMaximumSize

A WorkContext is metadata that WebLogic Server can propagate with work, such as a request or message. The FeatureCompatibilityMBean.SerializedWorkContextMaximumSize attribute limits the size of one SerializableWorkContext: a WorkContext containing an arbitrary Java Serializable object.

Note:

If you do not see this feature gate, confirm that you have applied the latest available Patch Set Update (PSU) or Critical Security Patch Update (CSPU). Security fixes and their feature gates are delivered on an as-needed basis through PSUs and CSPUs to ensure that your system is protected against vulnerabilities. To determine when this feature gate was delivered, see Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

SerializedWorkContextMaximumSize does not set a limit on:

The complete RMI invocation
A JMS message body
A SOAP message
An HTTP request
The combined size of all WorkContexts

The limit is applied separately to each serialized WorkContext read from untrusted input by a server. WorkContexts containing only a string, ASCII string, or long integer are not affected.

Property	Value
Type	Integer, measured in bytes
Default	`65535`
Limit	Any value from `-1` through `2147483647`.
Dynamic	Yes. No server restart is required.
Scope	Domain-wide. Enforced by a server receiving the WorkContext.

When SerializedWorkContextMaximumSize is set to a positive integer (such as 65535, its default), its value specifies the largest serialized WorkContext payload the server will accept.

For example, when SerializedWorkContextMaximumSize = 65535, the server accepts an individual serialized WorkContext containing up to 65,535 bytes. A larger payload is rejected before the server allocates memory for and reads that payload.

The size is the Java-serialized representation sent over the wire. It includes serialization overhead and may therefore be larger than the application’s estimate of the original object’s data.

Start with 65,535 bytes and increase the value only when a legitimate WorkContext requires more space.

Additionally, setting SerializedWorkContextMaximumSize to 0 or a positive value causes WebLogic Server to apply its stricter early-request object filter when the object stored inside the SerializableWorkContext is deserialized. The filter checks every class in the serialized object graph, not merely the top-level object.

Currently, WebLogic Server includes the normal product classes needed for standard WebLogic operations. However, an application-defined class, proxy interface, custom Principal, or another unusual nested object may not be accepted.

Consequently, an application can be affected even when its serialized WorkContext is smaller than the configured maximum.

This filtering is distinct from WorkContextClassValidationEnabled:

SerializedWorkContextMaximumSize checks the size and contents of the object stored inside a SerializableWorkContext.
WorkContextClassValidationEnabled controls which classes may serve as WorkContext implementations themselves.

When SerializedWorkContextMaximumSize is set to -1, the attribute does not impose a maximum size on a serialized WorkContext. The server preserves the previous size-handling behavior. It also does not activate the additional class filtering associated with this attribute.

The size limit and this attribute's additional payload filter are not reapplied when WebLogic Server restores WorkArea data that the server previously accepted and saved as trusted local data. Received deferred payloads must pass ingress validation before WebLogic Server promotes them to trusted storage.

Note:

Although 0 is accepted by the MBean, it is not equivalent to either a positive maximum or the documented disabled value (-1). Instead:

It does not impose a practical byte limit.
It does activate the stricter class filter.

Avoid using 0 unless the filtering-only behavior is specifically intended and understood.

Potential Impacts

Applications are most likely to notice this setting if they:

Call PrimitiveContextFactory.create(Serializable) or createMutable(Serializable).
Place application-defined Java objects in a WorkContextMap.
Use a framework or Oracle layered product that propagates opaque Java objects through WorkArea.
Depend on a custom class, proxy, or security-subject implementation being reconstructed from a WorkContext.
Propagate unusually large diagnostic, tracing, transaction, or application metadata.

Applications that do not use serialized WorkContexts should not be affected. Ordinary application parameters, JMS message bodies, and HTTP request bodies are outside the scope of this setting.

Troubleshooting Issues

There are two distinct types of failure.

The Serialized WorkContext Is Too Large

The server rejects it while reading the WorkContext. The underlying exception contains:

Invalid serialized WorkContext length: <length>

The outer symptom depends on the transport. For example, an application might receive:

An RMI or IIOP invocation failure
A SOAP fault
A JMS delivery or dispatch failure
An internal product operation failure

There is no single protocol-independent outer exception because the shared WorkArea code is used by several communication paths.

A Class Inside the WorkContext Is Not Accepted

Code that calls SerializableWorkContext.getSerializable() receives an InvalidClassException, normally with information indicating that an object-input filter rejected a class.

Code that calls the more general get() method behaves differently. That method catches the deserialization exception and returns the raw serialized data as a byte[]. Downstream code may consequently experience:

A value that is unexpectedly a byte array
Missing or unusable context information
A ClassCastException
An error resembling:
```
[B cannot be cast to <expected class>
```

In Java diagnostics, [B means byte[].

To determine whether the attribute caused the issue, perform the following steps:

First, identify the value active on the server receiving the request or message. In a cluster, enforcement occurs on the receiving server, so check each relevant server during configuration changes or mixed-version operation.

Then look for these indicators:

Invalid serialized WorkContext length
InvalidClassException
An object-input-filter rejection
Unauthorized deserialization attempt
A cast failure involving [B
Failures that occur only when a particular WorkContext is present
Failures that begin after setting the attribute to 0 or a positive value

To distinguish the two effects:

Compare the length reported in Invalid serialized WorkContext length with the configured maximum. If it is larger, the size limit caused the rejection.
If the payload is within the limit but deserialization still fails, inspect the exception for the first rejected class.
In a controlled test environment, use a much larger positive limit and repeat the exact operation. If the failure remains, the class filter—not the byte limit—is the likely cause.
As a final controlled comparison, set the attribute to -1 and repeat the operation. Because the attribute is dynamic, subsequent operations use the new value without a restart.

DebugWorkContext and object-input-filter diagnostics can provide additional class information when the ordinary exception chain is insufficient.

Interaction with the Older System Property

The older setting is:

weblogic.workarea.serializableWorkContext.maxLength

In a WebLogic Server process, the FeatureCompatibilityMBean value—including its default—takes precedence over this older property. The server does not fall back to the property merely because the MBean attribute is unset.

Thin or standalone WebLogic clients do not have access to the server's configuration MBean. Their local WorkArea implementation continues to use the system property, with -1 as the fallback when the property is absent. This can produce different client-side and server-side behavior.

StrictClusterCompatibilityEnabled

In WebLogic Server 26.1.0.0.0 and later, strict cluster compatibility handling is always enabled. The deprecated FeatureCompatibilityMBean.StrictClusterCompatibilityEnabled attribute cannot be configured. Its use as a rollout and compatibility gate applies only to lower-version PSU patch streams that support a configurable gate.

Note:

This feature gate is deprecated in this release and cannot be disabled. The following information is provided for reference only.

StrictClusterCompatibilityEnabled represents the always-enabled strict cluster compatibility handling for HTTP session and stateful EJB replication, including strict session serialization formats and validation of replicated metadata, dynamic proxies, and persistence references.

For example, in HTTP session replication, the gated changes include the strict replicated-session wire format, validation of replicated session metadata, and validation of serialized dynamic proxies stored in replicated session attributes. Other compatibility sensitive cluster service security hardening changes use the same attribute.

Applications do not normally read this attribute directly. A compatibility concern can arise while applying a Patch Set Update (PSU) that adds gated cluster hardening, while patched and unpatched servers coexist, or when an application depends on behavior made stricter by one of the gated changes.

Note:

StrictClusterCompatibilityEnabled is distinct from StrictReplicationAuthorizationEnabled. StrictReplicationAuthorizationEnabled represents the separately enforced authorization of cluster replication requests. Both protections are always enabled in WebLogic Server 26.1.0.0.0 and later. StrictClusterCompatibilityEnabled is the common gate for other compatibility-sensitive cluster service security hardening.

Property	Value
Type	Boolean
Default	`true`
Dynamic	N/A. In this release, you cannot change the `StrictClusterCompatibilityEnabled` value.

With StrictClusterCompatibilityEnabled enabled, WebLogic Server enables all cluster service security hardening registered with this compatibility gate. Consult the PSU release notes at Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

For example, for replicated HTTP session hardening, WebLogic Server:

Carries replicated application attributes in separate serialized chunks instead of accepting them as inline objects in the outer replication stream.
Preserves the unauthenticated object-input filtering associated with a replicated attribute when that attribute is stored or forwarded in serialized form.
Requires dynamic proxies in affected replicated session attributes to use interfaces visible from the active application class loader, subject to the compatibility exceptions described below.
Uses a tagged, chunked representation for internal full-session attributes.
Validates important full-session metadata using the expected exact object graph and type.

These current checks apply when a server receives or materializes replicated session state. They do not change the Servlet API or the application-visible value of a valid session attribute.

Potential Impacts

This attribute applies broadly to compatibility-sensitive security hardening in the WebLogic Server cluster service and in product features that exchange state or control information through that service.

For example, the Web container uses this gate for security hardening of in-memory HTTP session replication paths such as:

Incremental changes to replicated HTTP sessions
Full HTTP session state transferred to another server
Serialized application objects stored as HTTP session attributes
Internal session state and metadata carried in the replicated-session stream
Dynamic proxies reconstructed while replicated session attributes are deserialized

Future compatibility-sensitive cluster service security hardening will be associated with this attribute. Administrators should therefore review the release notes for each applicable PSU rather than assuming that the attribute affects only the current HTTP session cases.

The attribute does not by itself control ordinary cluster configuration or capacity settings such as:

How often WebLogic Server replicates a session
The number of secondary session copies
HTTP load balancing or session-cookie behavior
Database or file-based session persistence
Authorization of cluster replication requests, which remains controlled separately by StrictReplicationAuthorizationEnabled
Non-cluster communication and unrelated application security settings

The possible impact depends on the cluster hardening associated with the attribute in the installed update. Review that update's release notes for additional affected cluster operations and feature-specific symptoms.

For the current replicated HTTP session hardening, most applications are not affected. Ordinary serializable session attributes and dynamic proxies whose interfaces belong to the deployed application continue to be replicated normally.

An application is more likely to be affected if it stores a serialized dynamic proxy in an HTTP session and that proxy contains an interface that:

Is supplied by the server or system class loader rather than the application
Is supplied by a shared library whose loader is not recognized as belonging to the application
Cannot be resolved using the receiving server's application class loader

A proxy that implements the built-in WebLogic BusinessObject interface but no application interface may also be affected.

A mixed-version cluster can also be affected if a patched server uses a gated strict behavior when communicating with a server that has not yet been patched to support it. For the current HTTP session hardening, this can occur if strict session state is exchanged with a server that does not understand the new representation.

Troubleshooting Issues

Possible cluster-level symptoms include rejected inter-server operations, incomplete backup state, or failures that appear only after another server assumes responsibility for work. For the current HTTP session hardening, symptoms can include:

Replicated session updates or full-session transfers being rejected
A secondary session copy not being created or updated
A user losing an HTTP session after failover or being asked to log in again
Shopping-cart, wizard, or other conversational state disappearing after failover
ClassNotFoundException or InvalidClassException while a session attribute is deserialized
An error such as Could not resolve all application proxy interfaces
An error indicating that inline replicated session objects are not supported
An error indicating that strict replicated session metadata requires exact graph input

The primary request can continue to succeed even if its secondary session update failed. Consequently, the application impact may not become visible until failover occurs.

In WebLogic Server 26.1.0.0.0 and later, a reported value of false or a successful setter call is not expected. Verify that the client is connected to the intended server and is not displaying stale or offline metadata.

Compatibility Exceptions for the Current Dynamic-Proxy Validation

If a legitimate session attribute proxy requires a system-provided interface, the preferred compatibility setting is:

weblogic.common.internal.ProxyClassResolver.allowedSystemProxyInterfaces

Set this JVM startup property to the fully qualified names of the exact system interfaces that must be accepted. Multiple names can be separated by commas, semicolons, or whitespace. Configure it only on the servers that require the exception and restart those servers.

For example:

-Dweblogic.common.internal.ProxyClassResolver.allowedSystemProxyInterfaces=com.example.RequiredInterface

The broader compatibility property is:

weblogic.common.internal.ProxyClassResolver.allowNonApplicationProxyInterfaces

Setting this property to true restores broad legacy proxy-interface resolution for affected deserialization paths. It weakens the strict validation and should be used only as a temporary last resort on selected servers while the application packaging or proxy implementation is corrected.

Neither startup property changes the value returned by StrictClusterCompatibilityEnabled. They affect the current dynamic-proxy validation only; they do not disable or modify other cluster service hardening controlled by the aggregate gate. They provide narrowly scoped—or, for the broad property, legacy—proxy-resolution compatibility while strict cluster compatibility remains enabled.

StrictReplicationAuthorizationEnabled

In WebLogic Server 26.1.0.0.0 and later, strict replication authorization is always enforced. The deprecated FeatureCompatibilityMBean.StrictReplicationAuthorizationEnabled attribute cannot be configured. Its rollout-control behavior applies only to lower-version PSU patch streams that support a configurable gate.

Note:

This feature gate is deprecated in this release and cannot be disabled. The following information is provided for reference only.

Applications do not directly depend on the earlier replication protocol. In lower-version PSU patch streams with a configurable gate, the temporary compatibility requirement is between cluster members while the initial domain update is being completed.

This is not a replication performance setting. It does not control how often state is replicated, how much state is copied, or how many secondary copies WebLogic Server maintains.

The StrictReplicationAuthorizationEnabled attribute affects the clustering service that maintains backup copies of in-memory application state on other servers, including:

Replicated HTTP sessions
Replicated stateful session EJBs
Other services that use WebLogic Server replication
Remote or multi-site configurations that use the replication service

It does not directly change application deployment, load balancing, session cookies, database access, or persistent-store behavior.

Property	Value
Type	Boolean
Default	`true`
Dynamic	N/A. In this release, you cannot change the `StrictReplicationAuthorizationEnabled` value.

In WebLogic Server 26.1.0.0.0 and later, there is no enablement step and calling the setter throws UnsupportedOperationException. In lower-version PSU patch streams where the gate is configurable, enable it only after patching and restarting every server in the domain, including configured servers that are currently shut down.

Potential Impacts

Strict replication authorization does not change the contents or programming model of HTTP sessions, stateful session EJBs, or other replicated application data. In lower-version PSU patch streams with a configurable gate, patch and restart all participating servers before enabling it.

In those lower-version patch streams, enabling the gate before all participating servers are patched can prevent cluster members from creating or updating backup copies of application state. WebLogic Server 26.1.0.0.0 does not provide a switch to restore the legacy replication authorization behavior.

Normal application requests can continue succeeding on a primary server, so the problem might not be immediately visible. It may appear only when that server is stopped, fails, or is removed from service. Users could then experience symptoms such as:

An HTTP session being lost after failover
A user being unexpectedly logged out
Shopping-cart, wizard, or other conversational state disappearing
A stateful session EJB becoming unavailable after failover
Replicated state being missing or older than expected on the replacement server

Stateless applications and applications that do not use WebLogic Server in-memory replication generally are not affected.

WLDFScriptActionPathRestrictionEnabled

The FeatureCompatibilityMBean.WLDFScriptActionPathRestrictionEnabled attribute controls where a script executable specified by a WLDF script action may be located. It does not enable or disable WLDF script actions themselves.

Note:

If you do not see this feature gate, confirm that you have applied the latest available Patch Set Update (PSU) or Critical Security Patch Update (CSPU). Security fixes and their feature gates are delivered on an as-needed basis through PSUs and CSPUs to ensure that your system is protected against vulnerabilities. To determine when this feature gate was delivered, see Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

A WebLogic Diagnostics Framework (WLDF) watch can be configured to run a script when a monitored condition occurs. For example, a watch might run a diagnostic collection script when a server enters a warning state.

WLDFScriptActionPathRestrictionEnabled applies specifically to the PathToScript configured for WLDF watch script actions. These actions can be defined in WLDF system resources and targeted to an Administration Server or Managed Server.

It does not control:

Node Manager scripts
Server start or stop scripts
Application deployment scripts
Programs started directly by application code
The parameters, environment variables, or working directory configured for a WLDF script action
Other WebLogic Server features that perform their own script-path validation

Property	Value
Type	Boolean
Default	`true`
Dynamic	Yes
Restricted directory when enabled	`DOMAIN_HOME/bin/scripts`

When WLDFScriptActionPathRestrictionEnabled is set to true, WebLogic Server requires the script’s resolved path to be within DOMAIN_HOME/bin/scripts. A relative path is resolved from that directory. For example, if the domain home is /domains/production, the relative path maintenance/collect-data.sh resolves to /domains/production/bin/scripts/maintenance/collect-data.sh.

An absolute path also passes the location check if it resolves under DOMAIN_HOME/bin/scripts.

Before checking the location, WebLogic Server converts the path to its canonical form. In practical terms, this means that it:

Removes . and .. path components
Resolves symbolic links where the operating system permits
Checks the resulting location rather than relying only on the text of the configured path

A path containing .. is not rejected merely because it contains that component. It is rejected if the final resolved location is outside the permitted directory.

Examples of the resulting behavior are:

Configured path	Result when enabled
`collect-data.sh`	Allowed if it resolves beneath `DOMAIN_HOME/bin/scripts`
`maintenance/collect-data.sh`	Allowed
An absolute path beneath `DOMAIN_HOME/bin/scripts`	Allowed
`/opt/company/scripts/collect-data.sh`	Rejected
A relative path that uses `..` to leave `DOMAIN_HOME/bin/scripts`	Rejected
A symbolic link beneath `DOMAIN_HOME/bin/scripts` that points outside that directory	Rejected
A path in a similarly named directory such as `DOMAIN_HOME/bin/scripts-old`	Rejected

The executable must be located beneath the applicable domain scripts directory on every server where the WLDF action can run. In a domain spread across multiple machines, placing the script on the Administration Server does not automatically make it available on Managed Server machines.

Scripts and Programs Launched by the Configured Script

The restriction applies only to the executable configured in PathToScript. It is not a sandbox for everything that executable subsequently runs.

After WebLogic Server validates and starts a script beneath DOMAIN_HOME/bin/scripts, it does not apply this path restriction to programs or other scripts launched by that script. The configured script may call executables or scripts outside the domain scripts directory, subject to the operating-system permissions of the account running WebLogic Server.

The restriction also does not inspect the script action’s command-line parameters. Only the configured PathToScript is checked.

For example, a script stored at:

DOMAIN_HOME/bin/scripts/run-company-diagnostics.sh

can call:

/opt/company/diagnostics/collect-data.sh

The entry-point script configured in the WLDF action must be beneath the domain scripts directory. The program or script that it invokes does not have to be located there.

When WLDFScriptActionPathRestrictionEnabled is set to false, WebLogic Server preserves the earlier path-handling behavior:

An absolute script path may identify a file outside DOMAIN_HOME/bin/scripts.
A relative path is appended to DOMAIN_HOME/bin/scripts.
The resulting path is not subjected to the enabled attribute’s canonical containment check.

Consequently, an existing script action may depend on the disabled behavior if it uses:

An absolute path to a shared or system directory
A relative path that leaves DOMAIN_HOME/bin/scripts
A symbolic link beneath the scripts directory that points elsewhere

Potential Impacts

This setting normally affects monitoring and operational automation rather than application code directly.

When enabled, a WLDF watch can continue detecting its configured condition, but its script action will not run if the configured script resolves outside the permitted directory. Depending on what the script was intended to do, administrators might observe:

A diagnostic bundle not being collected
An alerting or incident-management script not running
An automated cleanup or recovery action not occurring
An external monitoring system not receiving an expected notification
No expected output files or other results from the script

The application being monitored may continue operating normally. In some environments, however, the missing automation can make an application problem appear worse or last longer—for example, if the script normally gathers diagnostic information or performs a recovery step.

Enabling the attribute does not change the script’s command-line parameters, environment variables, or configured working directory. After moving an entry-point script, verify any relative paths used inside the script or supplied through those other settings.

When Path Validation Occurs

The path is checked when the WLDF watch fires and WebLogic Server attempts to execute the script action. It is not necessarily checked when the WLDF resource is created or when a configuration change is activated.

As a result, a WLDF configuration can be accepted successfully even though its script path will later be rejected. A rarely triggered watch might not reveal the problem until well after the attribute was enabled.

Mitigate the Effects of the Enabled Setting

Inventory WLDF script actions in the domain.
Identify actions whose PathToScript is absolute or contains ...
Check whether any configured script path uses a symbolic link whose target is outside the domain scripts directory.
Place each configured entry-point script beneath DOMAIN_HOME/bin/scripts on every server where its action can run.
Update each script action to use the new entry-point location. A simple relative path is usually easiest to maintain.
If the entry-point script calls scripts or programs outside the domain scripts directory, verify those locations and the operating-system permissions needed to run them.
Verify file ownership, execution permission, interpreter availability, parameters, environment variables, and working-directory assumptions.
Trigger or otherwise exercise the affected watches to confirm that their script actions run successfully.

Troubleshooting Issues

When WebLogic Server rejects a script because it resolves outside the permitted directory, the reported error contains text similar to:

Invalid script path <configured-path>, script must be located underneath the domain directory <DOMAIN_HOME/bin/scripts>

This message is the clearest indication that WLDFScriptActionPathRestrictionEnabled caused the script action not to run.

To determine whether the attribute caused the issue, perform the following steps:

Confirm the current runtime value of WLDFScriptActionPathRestrictionEnabled.
Identify the server on which the WLDF script action attempted to run.
Obtain that server’s effective DOMAIN_HOME.
Examine the script action’s PathToScript.
Resolve the path completely, accounting for ., .., and symbolic links.
Confirm that the final location is beneath that server’s DOMAIN_HOME/bin/scripts directory.
Confirm that the configured entry-point file exists on every server targeted by the WLDF resource.

Other messages help distinguish path-restriction failures from ordinary script-execution problems:

BEA-320209, reporting that the executable path is not valid, can indicate that the accepted path does not exist.
BEA-320211, reporting that the script action is starting, indicates that the location restriction was passed and an execution attempt was made.
BEA-320206, reported after an execution attempt, generally points to a separate launch problem such as file permissions, an invalid interpreter, an invalid working directory, or another operating-system error.

In a controlled environment, change the attribute dynamically and trigger the same watch condition again. If the action runs when the attribute is false but produces the Invalid script path error when it is true, the path restriction is the cause.

IIOPStrictRemoteBusinessInterfaceValidationEnabled

The FeatureCompatibilityMBean.IIOPStrictRemoteBusinessInterfaceValidationEnabled feature gate controls whether WebLogic Server accepts a plain EJB business interface when generating an IIOP client stub. A plain business interface is an interface that does not extend java.rmi.Remote.

Note:

If you do not see this feature gate, confirm that you have applied the latest available Patch Set Update (PSU) or Critical Security Patch Update (CSPU). Security fixes and their feature gates are delivered on an as-needed basis through PSUs and CSPUs to ensure that your system is protected against vulnerabilities. To determine when this feature gate was delivered, see Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

The normal IIOP client path is:

IIOP client receives or looks up an IOR
    -> WebLogic Server resolves the business interface from local metadata
    -> Strict validation checks whether the interface is a remote interface
       -> Accepted: generated _IIOP_WLStub implements the business interface
       -> Rejected: generated stub does not retain that plain interface
    -> Client narrows or casts the stub to the business interface

With the default setting, an interface that is not recognized as remote is not retained on the generated stub. Consequently, PortableRemoteObject.narrow() and an application cast to that plain business interface can fail even though the interface was used by a legacy EJB 3 IIOP client.

This setting does not:

Make an arbitrary interface eligible for an IIOP stub.
Load an interface from an IOR codebase.
Relax the normal remote-interface checks for ordinary or deserialized client runtime descriptors.
Change server-side EJB authorization, application method dispatch, or transport authentication.

Property	Value
Type	Boolean
Default	`true`
Dynamic	Yes. A server restart is not required.
Scope	Domain-level configuration. It affects a WebLogic Server instance when it acts as an IIOP client and creates a stub from an IOR.

When IIOPStrictRemoteBusinessInterfaceValidationEnabled is set to true, WebLogic preserves strict remote-interface validation. A business interface that does not extend java.rmi.Remote is not retained as a generated-stub interface. The resulting stub can therefore expose only the standard IIOP stub interfaces rather than the application's plain business interface.

When IIOPStrictRemoteBusinessInterfaceValidationEnabled is set to false, WebLogic Server permits a legacy IIOP client stub to retain a plain EJB 3 business interface that is not recognized as remote, provided:

The interface has already been resolved locally from RemoteInfo.
The interface is visible to the client runtime's class loader.
The IOR has no codebase.
The interface is a usable Java interface but is not already a java.rmi.Remote interface.

The exception is limited to that exact locally resolved interface. It is local-only state: it is not serialized with the client runtime descriptor and is not shared through descriptor interning. The existing descriptor filter continues to reject unrelated non-remote interfaces.

When these conditions are met, the generated _IIOP_WLStub implements the plain business interface, allowing the legacy PortableRemoteObject.narrow() call or application cast to succeed.

Setting the attribute to false does not guarantee that a lookup, narrow, or invocation succeeds. The interface must still be locally available and the IOR must meet the no-codebase requirement. Other IIOP, naming, class-loading, and application errors can still prevent the operation.

The disabled setting does not permit remote codebase loading, arbitrary interface injection, or relaxation of the normal ClientRuntimeDescriptor filtering rules. Treat false as a limited legacy-interoperability setting rather than a general-purpose IIOP type-resolution option.

Dynamic Behavior and Rollout Considerations

The IIOPStrictRemoteBusinessInterfaceValidationEnabled attribute is dynamic. A committed domain configuration change affects stubs created after the client runtime observes the new value; it does not retroactively alter a stub that was already created. Recreate the lookup or narrow result when testing a change.

Every WebLogic Server that acts as the affected IIOP client needs the runtime update as well as the management configuration that defines the attribute. In a staged or mixed-version rollout:

A server with the MBean/API update but an older IIOP runtime can store false but still retain the old strict behavior.
A server with the IIOP runtime update but without an available configuration value retains strict validation rather than enabling the compatibility exception.
Different client servers can create different stub shapes if they have different patch levels or effective values.

Verify both the effective domain value and the installed IIOP runtime on the server that performs the lookup or narrow operation.

Potential Impacts

This setting is relevant to an IIOP client that uses a plain EJB 3 remote business interface. Typical cases include:

A legacy EJB 3 client that narrows a looked-up IIOP object to a plain business interface.
An application that casts an IIOP lookup result directly to that interface.
A client and service assembled from legacy artifacts where the business interface follows the EJB 3 programming model but does not extend java.rmi.Remote.

Clients whose business interfaces already extend java.rmi.Remote continue through the normal path and do not need this compatibility setting.

Mitigate the Effects of the Enabled Setting

Identify IIOP clients that use EJB 3 business interfaces not extending java.rmi.Remote.
Prefer updating the client contract or integration so it uses a normal remote interface where practical.
Test lookups, PortableRemoteObject.narrow(), and application casts using the deployed interface and the same client class-loader arrangement used in production.
Keep the attribute at its default true unless a documented legacy compatibility requirement needs the narrow exception.
If an exception is necessary, record the affected client and interface, verify that the IOR has no codebase, and plan to restore the secure default after the client is updated.

Troubleshooting Issues

With the attribute enabled, a legacy client can observe one or more of these symptoms after receiving an IIOP stub:

PortableRemoteObject.narrow() does not return an object compatible with the expected business interface.
A cast of the generated _IIOP_WLStub to the business interface fails.
Reflection or framework code that requires the stub to implement the business interface cannot find that interface.

With the attribute disabled and the stated safety conditions met, the generated stub implements the expected plain business interface. If the symptom remains, check that the interface is visible locally, that the IOR carries no codebase, and that the lookup result was recreated after the configuration change.

To determine whether the attribute caused the issue, perform the following steps:

Confirm the effective IIOPStrictRemoteBusinessInterfaceValidationEnabled value on the domain FeatureCompatibilityMBean used by the server acting as the IIOP client.
Recreate the lookup or narrow result after a dynamic configuration change; an existing stub is not modified.
Confirm that the expected business interface is a Java interface, is locally visible to the client runtime, and does not extend java.rmi.Remote.
Confirm that the IOR does not provide a codebase. This opt-out intentionally does not permit codebase-based interface loading.
Inspect the actual returned stub. With the compatibility path active, it must implement the expected business interface before an application cast or PortableRemoteObject.narrow() can succeed.
If the setting is false but the stub still lacks the interface, verify that the IIOP runtime update is installed on the client server and that the domain configuration is available to that runtime.

SpringJtaDeserializationJndiLookupDisabled

The FeatureCompatibilityMBean.SpringJtaDeserializationJndiLookupDisabled feature gate controls whether WebLogic Server's repackaged Spring JTA transaction manager restores transaction handles during Java deserialization. Normal initialization of a configured Spring transaction manager remains available regardless of the feature gate setting.

Note:

If you do not see this feature gate, confirm that you have applied the latest available Patch Set Update (PSU) or Critical Security Patch Update (CSPU). Security fixes and their feature gates are delivered on an as-needed basis through PSUs and CSPUs to ensure that your system is protected against vulnerabilities. To determine when this feature gate was delivered, see Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

A JTA transaction manager uses handles to services such as UserTransaction, TransactionManager, and TransactionSynchronizationRegistry. Spring can obtain these services from configured JNDI names, default JNDI locations, or server-specific discovery.

In the affected Spring implementation, these three handles are transient: Java serialization does not retain them. The serialized object can retain the configuration used to locate them, including JNDI names. Earlier behavior reconstructed the handles as part of the transaction manager's readObject() method. This attribute controls that restoration step.

The SpringJtaDeserializationJndiLookupDisabled attribute applies to the repackaged Spring JTA transaction manager classes bundled with WebLogic Server. It does not automatically apply to an application’s own Spring libraries merely because the application runs on WebLogic Server. When assessing compatibility, verify which transaction manager class the application loads and which library supplies it.

When enabled, SpringJtaDeserializationJndiLookupDisabled separates Java deserialization from service resolution driven by serialized transaction-manager configuration. It removes this particular deserialization-time path to JNDI lookup and other handle restoration. It is not a general-purpose Java deserialization filter, a ban on all JNDI access, or a switch that disables JTA transactions.

Setting the attribute to false restores the possibility of service resolution while the object is being deserialized. Because the setting is domain-wide rather than application-specific, use it only after identifying the affected application and reviewing the source and trust of the serialized data. Prefer an application change that no longer depends on automatic handle restoration in readObject().

The Spring bridge returns the protective value (true) when it cannot load or invoke the compatibility helper. The helper also starts with the protective default (true) before configuration becomes available. Consequently, a configured compatibility override should not be assumed to work in a standalone process or class-loading environment that cannot reach WebLogic's configuration bridge.

The feature gate is checked in readObject(), not in the normal Spring initialization callback, afterPropertiesSet(). A newly configured bean can still initialize its transaction handles through the usual lifecycle. A deliberately reinitialized, deserialized object can also obtain handles through that callback when its configuration is trusted and appropriate for the current server.

The attribute does not directly change:

Transaction timeout, isolation, commit, or rollback settings
Normal JNDI access elsewhere in an application
Other JNDI security or allowlist settings
The serialized representation of the nontransient configuration
Application-supplied Spring implementations that do not contain this WebLogic gate

Changing the value does not revisit transaction managers that have already been deserialized. It neither restores handles in those objects nor removes handles from objects that are already initialized. A dynamic change affects subsequent executions of the affected deserialization path.

Property	Value
Type	Boolean
Default	`true`
Dynamic	Yes. A server restart is not required.
Scope	Domain-wide. Enforced in each server's affected repackaged Spring classes.

When SpringJtaDeserializationJndiLookupDisabled is set to true, the affected readObject() method:

Reads the serialized object's nontransient state.
Creates a new JndiTemplate.
Skips initUserTransactionAndTransactionManager() and initTransactionSynchronizationRegistry().

The transient transaction handles therefore remain unset immediately after deserialization. The implementation does not reject the object solely because this protection is enabled, and it does not clear the serialized JNDI-name properties. It simply does not use those properties to restore handles in this callback.

This is broader than blocking remote JNDI URLs: the initialization routines are skipped even when a serialized name refers to a local service or the subclass could obtain a handle from WebLogic's transaction helper. There is no per-name allowlist exception in this gate.

When SpringJtaDeserializationJndiLookupDisabled is set to false, the affected readObject() method calls both initialization routines after restoring the nontransient state and recreating the JNDI template.

These routines can resolve configured JNDI names, discover default services, or retrieve WebLogic-specific handles, depending on the serialized configuration and concrete transaction manager class. If a lookup fails, deserialization may fail with the associated Spring transaction-system or naming error.

The false value permits the earlier behavior, but it does not guarantee that a lookup succeeds. JNDI outbound connection restrictions, factory restrictions, authentication, authorization, and service availability still apply independently. Disabling this feature gate for compatibility purposes is not a bypass for those checks.

Potential Impacts

The compatibility risk is concentrated in code that serializes an affected transaction manager, directly or as part of a larger object graph, and expects it to be immediately usable after restoration.

Examples to investigate include custom serialization, cached object graphs, or session passivation and replication that actually include one of the affected classes. These are investigation scenarios, not a statement that ordinary WebLogic session replication always serializes a Spring transaction manager.

An application that creates and initializes its transaction manager normally, without serializing that manager, should not need this override for that initialization path. A serialized proxy that resolves back to a managed bean without deserializing the transaction manager itself is also different from the path controlled here.

Mitigate the Effects of the Enabled Setting

Keep true for applications that do not depend on deserializing these transaction managers.
Avoid serializing infrastructure transaction-manager instances when the application can recover a reference to a locally managed, initialized bean instead.
If reconstruction is necessary, perform it through an intentional lifecycle with trusted configuration for the current server. Do not blindly reapply untrusted serialized JNDI names in another deserialization callback; that would recreate the behavior the protection avoids.
Test legitimate restoration scenarios and the first transaction after restoration, not just whether ObjectInputStream.readObject() returns successfully.
If a temporary false override is required, record the affected application, review the domain-wide exposure, and define a migration and retest plan. Restore true and create or restore fresh instances when that dependency is removed.

Troubleshooting Issues

With the protection enabled, deserialization itself can succeed, but later transaction use can fail because the restored object has no UserTransaction handle. The affected implementation can report:

No JTA UserTransaction available - programmatic PlatformTransactionManager.getTransaction usage not supported

Explicit initialization can instead report:

No JTA UserTransaction available - specify either 'userTransaction' or 'userTransactionName' or 'transactionManager' or 'transactionManagerName'

These messages are not proof that the attribute caused the failure. An incompletely configured transaction manager can produce them for other reasons. Correlate the exception with the object's deserialization history and the effective attribute value.

With SpringJtaDeserializationJndiLookupDisabled set to false, a failure may instead appear during deserialization when a configured or discovered JNDI service cannot be resolved. Do not assume that every Spring transaction failure or NamingException is controlled by this attribute.

To determine whether the attribute caused the issue, perform the following steps:

Identify the actual transaction manager class and its supplying library. Confirm that it is the affected WebLogic repackaged implementation.
Establish whether the failing instance was deserialized. Look for the serialization or restoration boundary before its first failing transaction operation.
Read the domain attribute with WLST. Record whether the protection is enabled.
In a controlled reproduction, inspect getUserTransaction(), getTransactionManager(), and getTransactionSynchronizationRegistry() immediately after deserialization and before any explicit reinitialization. With the protection enabled, these transient fields are not restored by the affected callback.
Compare normal bean initialization with deserialization. If a new, configured bean works but a restored instance fails, investigate the application's dependence on automatic restoration.
If necessary, compare the same legitimate payload with true and false in a nonproduction test domain. A successful fresh deserialization and subsequent transaction with false is evidence of a compatibility dependency, not justification for a permanent domain-wide exception.

When DebugJNDI is enabled, the configuration helper can log a FeatureCompatibilityMBean refresh message containing SpringJtaDeserializationJndiLookupDisabled. Use that as supporting evidence of a server-side configuration refresh, not as proof that a particular application object has usable handles. There is no dedicated rejection exception in the guarded readObject() branch: it skips initialization.

T3LegacyCrossDomainCredentialJVMIDReplayProtectionEnabled

The FeatureCompatibilityMBean.T3LegacyCrossDomainCredentialJVMIDReplayProtectionEnabled feature gate controls whether WebLogic Server prevents a remote server identity from becoming trusted solely because it carries a JVM identifier (JVMID) signed using legacy cross-domain credentials.

Note:

If you do not see this feature gate, confirm that you have applied the latest available Patch Set Update (PSU) or Critical Security Patch Update (CSPU). Security fixes and their feature gates are delivered on an as-needed basis through PSUs and CSPUs to ensure that your system is protected against vulnerabilities. To determine when this feature gate was delivered, see Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

A JVMID represents a WebLogic process identity. Before exchanging remote invocations, peers use T3 identify messages to exchange identity information.

Legacy global-domain-trust communication can use a JVMID signature verified with the domain credential. Verification of this legacy signature alone does not prove that the process presenting the identity is its original owner: a previously observed signed identity can be replayed.

When protection is enabled, a verified legacy signature alone is insufficient to establish trusted-server identity during this exchange. Trusted-server identity affects how WebLogic classifies subsequent traffic as server traffic and applies unauthenticated-request checks.

The control applies to both T3 identify requests and responses.

The T3LegacyCrossDomainCredentialJVMIDReplayProtectionEnabled attribute affects server-to-server T3 communication that depends on legacy global-domain trust, including product or application callbacks between trusted domains.

For example, Coherence global-domain-trust cache operations can depend on callbacks from a remote trusted domain. With replay protection enabled, those callbacks can be classified as anonymous RMI and rejected when RemoteAnonymousRMIT3 is disabled.

The attribute controls how trust is established during T3 identity exchange. It does not configure domain credentials, establish global-domain trust, grant application permissions, or change application invocation data.

It also does not configure SSL certificate trust, hostname verification, or selection of an outbound T3S connection. JVMID trusted-server state and SSL certificate trust serve different purposes.

Property	Value
Type	Boolean
Default	`true`
Dynamic	Yes. A server restart is not required.
Scope	Domain-level configuration. Enforced by each server during T3 identity exchange.
Primary area	Trusted-server identity promotion for legacy global-domain-trust communication

This is a server-side setting. Configure the participating servers' domains. Changing a standalone client's configuration is not a substitute for changing the server configuration.

When T3LegacyCrossDomainCredentialJVMIDReplayProtectionEnabled is set to true, WebLogic Server does not establish trusted-server state solely because a JVMID received in a T3 identify request or response has a verified legacy cross-domain credential signature.

A previously encountered identity that is still untrusted remains subject to this restriction.

This setting does not reject every identify message or disable all cross-domain communication. It suppresses the specific legacy-signature trust promotion. Subsequent traffic remains subject to the trust, authentication, authorization, and unauthenticated-request policies applicable to that traffic.

The enabled setting does not revoke trust already held by an existing remote server identity or revalidate all established connections. This matters when testing a configuration change with connections that were established while the attribute was disabled.

When T3LegacyCrossDomainCredentialJVMIDReplayProtectionEnabled is set to false, WebLogic Server permits a verified legacy cross-domain credential signature received during T3 identity exchange to establish trusted-server state.

This compatibility behavior includes a newly encountered remote server and applies to both identify requests and responses.

The disabled setting does not accept arbitrary unsigned identities as trusted through this path. The received identity must represent a server and carry a verified legacy signature, and the applicable identity-matching checks still apply.

However, disabling the attribute permits the legacy-signature-only promotion that the replay-protection setting is designed to prevent. Legacy compatibility therefore retains the replay exposure associated with relying on that signature alone.

Keep the default value of true unless a required integration depends on legacy global-domain-trust behavior. Consider disabling the attribute when a controlled comparison confirms that this restriction causes otherwise supported cross-domain calls or callbacks to fail. Review the replay exposure before retaining the disabled setting. Other authentication and authorization requirements continue to apply.

Potential Impacts

Applications and product integrations are most likely to notice the enabled behavior if they:

Communicate between domains using legacy global-domain trust.
Depend on trusted-server classification derived from a legacy credential-signed JVMID.
Initiate server-to-server callbacks from a remote trusted domain.
Disable anonymous RMI over T3 and rely on those callbacks being recognized as server traffic.
Use Coherence cache operations that depend on global-domain-trust callbacks.

Ordinary application traffic that does not rely on this legacy identity-promotion path is less likely to be affected. A successful initial operation does not establish that later callbacks will work; test traffic initiated in both directions.

Troubleshooting Issues

With the attribute enabled, a peer whose identity previously became trusted solely through the legacy signature may remain untrusted. The enabled attribute does not revoke trust already held by an existing remote server identity or revalidate all established connections. When a remote identity is established again, for example after a server restart, traffic that previously relied on legacy signature-based trust may be subject to additional authentication and deserialization checks. Test the setting with newly established identities and connections.

If anonymous RMI over T3 is disabled, affected server-to-server requests can be rejected as anonymous RMI. For affected Coherence callbacks, symptoms can include:

Server log message BEA-000582 for callbacks from the remote trusted domain.
An EOFException in the calling operation.

The exception reported to an application depends on the operation. Other integrations can report remote-call failures, connection failures, or nested exceptions according to where the rejected request occurs.

Neither BEA-000582 nor EOFException uniquely identifies this setting. Anonymous-RMI policy, other identity problems, and unrelated connection failures can produce similar symptoms.

To determine whether the attribute caused the issue, perform the following steps:

Identify the server receiving the failing request or callback and the domain from which it originates. Establish whether the communication uses legacy global-domain trust.
Check the active T3LegacyCrossDomainCredentialJVMIDReplayProtectionEnabled value in the receiving server's domain configuration. For operations that initiate traffic in both directions, check the relevant servers in both domains.
Determine whether failures began after enabling the attribute or updating to a release with default true. Check whether the attribute has an explicit value rather than assuming that a previously unset attribute still defaults to false. Also check RemoteAnonymousRMIT3 and the server logs for anonymous-RMI rejections. For Coherence callbacks, look for BEA-000582 on the server together with EOFException in the failing operation.
Examine the complete exception chain and establish whether the initial invocation succeeds but a later server-to-server callback fails. Verify that the target business operation or callback actually runs rather than inferring success from connection establishment alone.
In a controlled environment, compare the same operation with the attribute enabled and disabled. Save and activate each change. A server restart is not required to change this attribute's value.
Recreate the relevant remote identities and connections for each comparison, or restart the affected test servers when necessary to obtain a clean identity state. Closing a single connection may leave its remote server identity available for reuse. Existing trusted identities are not reset merely by enabling the attribute and can conceal the difference between the two settings.
Repeat the complete interaction, including callbacks in both directions. If it succeeds with false and fails with true only when the peer depends on legacy-signature trust promotion, the attribute is a likely cause of the behavior change.
If the failure persists with the attribute disabled and fresh test identities, investigate other causes, including global-domain-trust configuration, authentication, authorization, anonymous-RMI policy, SSL configuration, and connectivity.

There is no single exception message specific to this attribute. Diagnosis depends on the subsequent operation and the policy that rejects it.

Relationship to Other FeatureCompatibilityMBean Attributes

CrossDomainT3SConnectionTrustValidationEnabled governs whether outbound cross-domain secure server requests must use a locally initiated connection so that outbound SSL trust configuration is applied.
T3RouteOnlyToTrustedServersEnabled governs indirect T3 routing to trusted destination servers.
T3LegacyCrossDomainCredentialJVMIDReplayProtectionEnabled governs legacy-signature-only trusted-server promotion during identify processing. Changing it does not configure the other two policies or satisfy their SSL and routing requirements.

5 Managing Gated Security Features

Determining the Security Behavior

Handling Security Hardening Changes

JNDIAdditionalFactoriesAllowListsEnabled

Configuring JNDIAdditionalInitialContextFactoriesAllowed and JNDIAdditionalReferenceFactoriesAllowed

JNDIBindingAuthorizationPolicyEnabled

JNDIOutboundConnectionsAllowListEnabled

Configuring JNDIOutboundConnectionsAllowed

T3RouteOnlyToTrustedServersEnabled

WorkContextClassValidationEnabled

WLProxyClientCertificateChainValidationEnabled

WorkContextInputMaximumASCIIFieldSize

WSATIgnoreUnknownReplayCompletionEnabled

WSATRegistrationSecretEnabled

CrossDomainT3SConnectionTrustValidationEnabled

IIOPTypedReadResolveProxyValidationEnabled

IIOPUnauthenticatedServiceContextValueTypeFilteringEnabled

JAXWSRejectUnknownSEIOperationsEnabled

SAML2StrictArtifactResolutionEnabled

SerializedWorkContextMaximumSize

StrictClusterCompatibilityEnabled

StrictReplicationAuthorizationEnabled

WLDFScriptActionPathRestrictionEnabled

IIOPStrictRemoteBusinessInterfaceValidationEnabled

SpringJtaDeserializationJndiLookupDisabled

T3LegacyCrossDomainCredentialJVMIDReplayProtectionEnabled