Managing Gated Security Features

5 Managing Gated Security Features

WebLogic Server releases Patch Set Updates (PSUs) and Critical Security Patch Updates (CSPUs) to ensure that your system is protected against vulnerabilities. Occasionally, these updates include changes to existing behavior that are backward incompatible, leading to unexpected effects in processes that relied on the previous behavior.

To reduce potential side effects, features with significant behavioral changes are disabled by default and controlled by feature gates. When you are ready to enable the new behavior, set the feature's gate to true. This grants WebLogic Server administrators the flexibility to test and enable each feature individually and on a schedule that works best for their system.

Feature gates are controlled by attributes on the FeatureCompatibilityMBean. See Determining the Security Behavior for steps on opening a feature gate and enabling the new behavior.

Note:

Oracle strongly recommends enabling these features as soon as feasible. They provide significant security benefits, and delaying their implementation increases your system's vulnerability.

New security fixes and their feature gates are delivered in PSUs and CSPUs on an as-needed basis. For the latest information, refer to Security Advice and Post-Install Information for Oracle WebLogic Server PSUs (Doc ID 2764668.1) on My Oracle Support.

This chapter includes the following sections:

Determining the Security Behavior

Use WLST to set a feature gate and change the security behavior.

Feature gate behavior is determined by Boolean attributes on the FeatureCompatibilityMBean. Setting the attribute to true enables the more secure behavior in WebLogic Server, while setting it to false preserves the legacy and less secure behavior.

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.

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()

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 can't 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.

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	`false`
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 objects returned by Foreign JNDI or Foreign JMS configurations

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 Foreign JNDI Provider using a non-built-in initial context factory
A Foreign JMS configuration using a vendor-specific 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 initialize a Foreign JNDI Provider
Failure to initialize 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

Before You Enable JNDIAdditionalFactoriesAllowListsEnabled

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 Foreign JNDI Provider and Foreign JMS configurations.
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 Foreign JNDI Provider 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 factory, such as an LDAP or third-party naming-provider factory, must be added explicitly when the feature is enabled.

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 controls enhanced authorization enforcement for JNDI namespace modification operations, including T3/IIOP binding operations, sharable namespace writes, default JNDI ACL behavior, and IIOP CosNaming mutations.

Note:

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, the JNDIBindingAuthorizationPolicyEnabled attribute adds a WebLogic security role requirement to operations that change server-side JNDI bindings such as bind, rebind, unbind, rename, and subcontext operations. It does not apply to operations that merely read the namespace such as lookup and list.

By default, the additional Admin, Deployer, or Operator role requirement is not applied. Whether the modification succeeds is determined by the existing JNDI resource policy, remote-anonymous-user restrictions, naming rules, and the behavior of the protocol through which the operation arrived.

This distinction is important when diagnosing an application that worked with the attribute disabled. The application might have depended on a custom JNDI policy that permitted an ordinary service account to modify a particular name. Enabling the attribute adds the security role requirement before or in addition to that policy.

When the attribute is true, a caller normally must be one of the following to modify the server-side JNDI namespace:

The WebLogic Server kernel identity
A user with the WebLogic Admin, Deployer, or Operator security role

The security role check is an additional requirement. It does not replace an existing authorization policy for the individual JNDI name.

A successful modification generally must pass both checks:

Caller has an allowed security role
                    and
Caller is permitted to modify the specific JNDI resource

Consequently, placing a user in the Admin, Deployer, or Operator role does not necessarily guarantee that every bind or unbind operation will succeed. An applicable JNDI resource policy can still deny the operation.

Similarly, when this attribute is false, WebLogic Server does not simply allow every caller to modify JNDI. Existing per-name JNDI authorization policies and restrictions on remote anonymous callers remain in effect.

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

Because the attribute is dynamic, a server restart is not required. After the configuration change is activated, the new policy is applied to subsequent JNDI modification attempts.

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 add a security role requirement to:

lookup
list
Normal use of an object that has already been obtained from JNDI
Application deployment descriptors that ask WebLogic Server to create standard application resources
Internal WebLogic Server registrations performed using the server's kernel identity

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.

Local Application Exception

The enabled policy preserves a narrow compatibility case for a deployed application performing a JNDI modification from its application invocation context.

The additional security role requirement is bypassed only when all of the following are true:

The effective caller is anonymous.
The call is running in the invocation context of a real deployed application.
The effective JNDI environment does not contain a non-null Context.PROVIDER_URL. An explicitly configured empty or whitespace value is still present and does not qualify for this exception.
The operation does not enable the WebLogic create-under-sharable environment option (weblogic.jndi.createUnderSharable=true).

This is an authorization-policy classification, not a network-reachability test. Any non-null Context.PROVIDER_URL value disqualifies the operation from this exception, even when that URL targets the same server, localhost, or a local address.

The exception bypasses only this additional Admin, Deployer, or Operator role check. Existing per-name JNDI authorization and remote-anonymous-user restrictions still apply.

The exception does not apply when application code performs the operation under the identity of an authenticated end user, service account, or configured run-as user. Such an identity must satisfy the normal security role requirement unless it is the kernel identity.

Sharable Namespace Changes

WebLogic Server has an internal sharable namespace used by server services and certain cross-partition or replicated facilities.

The WebLogic create-under-sharable environment option (weblogic.jndi.createUnderSharable=true) directs supported internal naming operations to create beneath the sharable namespace. When this attribute is enabled, that path is restricted to a server-internal caller using the kernel identity.

A remote user does not gain permission to change the sharable namespace merely by having the Admin, Deployer, or Operator role.

Ordinary applications should not normally need to set weblogic.jndi.createUnderSharable.

IIOP CosNaming Behavior

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

WebLogic Server checks the identity of the original IIOP caller 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 security role requirement.

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
Uses an ordinary application service account rather than a WebLogic administrative identity
Uses CORBA CosNaming to register objects in WebLogic Server
Uses a provider URL to modify JNDI, even when the URL points to the same server
Performs a local bind while running under an authenticated end-user or run-as identity
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.

Before You Enable JNDIBindingAuthorizationPolicyEnabled

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 effective JNDI environment contains a non-null provider URL.
Review existing policies for the JNDI names being modified.
Replace remote application-managed registrations with deployment-time or server-managed configuration where practical.
Where remote namespace modification is required, use an appropriately authorized administrative identity and grant only the permissions required by the applicable JNDI resource policy.
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

An early remote-dispatch authorization failure can contain:

User <user-name> does not have permission to invoke <operation>

For example:

User application-user does not have permission to invoke bind

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.

These messages strongly indicate that the JNDI binding authorization policy or an existing JNDI resource policy denied the operation.

The following separate message indicates the existing remote-anonymous-user restriction rather than the security role check added by this attribute:

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 that user has the WebLogic Admin, Deployer, or Operator security role.
Determine whether the effective JNDI environment contains a non-null Context.PROVIDER_URL. Remember that an empty or whitespace-only value is still non-null.
For a local application call, determine whether the effective caller is anonymous and whether the operation runs in the deployed application's invocation context.
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 the security role permission message when it is true, this attribute added the requirement that caused the failure.

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:

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 JNDIOutboundConnectionsAllowed does not necessarily mean that every scheme is accepted. A legacy system property may still restrict the operation.

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

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	`false`	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
WebLogic Foreign JNDI Provider connections
Foreign JMS resources that use a remote JNDI provider
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 to connect to a Foreign JNDI Provider
Failure to initialize a Foreign JMS resource
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.

Before You Enable JNDIOutboundConnectionsAllowListEnabled

Inventory Foreign JNDI Providers, Foreign JMS resources, delegate environments, and server-side code that uses remote JNDI.
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 JNDIOutboundConnectionsAllowed 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 Foreign JNDI Provider 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.

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:

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

By default, if an accepted server-to-server message must be forwarded and no route already exists, the intermediate server may create a route using the destination address and port carried with that message. This enables 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	`false`
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.

Before You Enable T3RouteOnlyToTrustedServersEnabled

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 will construct 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:

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

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.

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	`false`
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.