Secure a NoSQL Resource

Configure runtime authorization independently of placement, binding, and database authentication. The Securing a Production Environment for Oracle WebLogic Server book also strongly encourages a policy review for each global resource.

Identify the Access Policy

weblogic.security.service.NoSQLResource uses type <nosql> with keys resource and action. The resource key is the global management-resource name, such as personNoSqlResource. The runtime action is access.

The semantic hierarchy is resource-and-action, resource, global action, then the top NoSQL resource.

<nosql>, resource=personNoSqlResource, action=access
  -> <nosql>, resource=personNoSqlResource
     -> <nosql>, action=access
        -> <nosql>

These identities describe policy inheritance, not command serialization. Obtain the exact serialized identity from the supported policy-management interface. The repository alias nosql/person and JNDI name nosql/personNoSqlResource are not the policy resource identity.

The shipped global access policy grants the everyone group, represented by Grp(everyone). Review the effective policy and configure resource-specific restrictions for intended callers.

Configure and Verify Access

Use the security realm’s supported policy-management interface. Determine the management-resource name and intended callers before changing the policy.

  1. Select the NoSQL resource’s access policy.
  2. Configure the intended users, groups, or roles.
  3. Read back the effective policy and its inheritance.
  4. Verify an allowed caller through the owning application.
  5. Verify that an excluded caller is denied.
  6. Revoke an allowed caller’s access.
  7. Verify denial on its next guarded handle or retained-capability operation.

The provider credential authenticates the database connection. It does not authorize every WebLogic Server caller. Management permission to configure a resource is also separate from runtime access permission.

Evaluate the Current Subject and Ownership

WebLogic Server checks the current authenticated subject before lazy provider or credential initialization and during guarded manager operations. Checks also apply to retained capabilities and applicable metadata access.

Denial, a missing eligible subject, or an unavailable authorization service fails closed with SecurityException. An initially denied operation does not initialize the provider or credentials.

The deployer or the subject that originally obtained a handle does not permanently authorize subsequent calls. Retained streams, iterators, cursors, prepared operations, and applicable metadata access remain subject to the current checks.

Passing a handle or derived capability to another deployment does not transfer ownership. WebLogic Server enforces the exact calling application’s ownership.

Revoke Access to Existing Capabilities

Effective policy revocation denies the next guarded operation through existing handles and retained capabilities without application redeployment.

An operation already admitted can drain. Revocation does not promise to interrupt that operation. Keep policy revocation distinct from terminal resource invalidation.