7 Securing Oracle Coherence in Oracle WebLogic Server

Authentication and authorization can be used to secure Coherence in an Oracle WebLogic Server domain. The instructions are specific to the Oracle WebLogic Server Administration Console and do not include details for the Oracle WebLogic Scripting Tool (WLST).

This chapter includes the following sections:

Overview of Securing Oracle Coherence in Oracle WebLogic Server

Several security features are used to secure cluster members, caches and services, and extend clients when deploying Coherence within an Oracle WebLogic Server domain. The default security configuration allows any server to join a cluster and any extend client to access a cluster's resources.

The following security features should be configured to protect against unauthorized use of a cluster:

  • Oracle Coherence access controllers – provides authorization between cluster members

  • Oracle WebLogic Server authorization – provides authorization to Oracle Coherence caches and services

  • Oracle Coherence identity tokens – provides authentication for extend clients

Much of the security for Oracle Coherence in a Oracle WebLogic Server domain reuses existing security capabilities. Knowledge of these existing security components is assumed. References are provided in this documentation to existing content where applicable.

Securing Oracle Coherence Cluster Membership

The Oracle Coherence security framework (access controller) can be enabled within a Oracle WebLogic Server domain to secure access to cluster resources and operations. The access controller provides authorization and uses encryption/decryption between cluster members to validate trust. See Overview of Using an Access Controller.

In Oracle WebLogic Server, access controllers use a managed Coherence server's keystore to establish a caller's identity between Oracle Coherence cluster members. The Demo Identity keystore is used by default and contains a default SSL identity (DemoIdentity). The default keystore and identity require no setup and are ideal during development and testing. Specific keystores and identities should be created for production environments. See Configuring Keystores in Administering Security for Oracle WebLogic Server.

This section includes the following topics:

Enabling the Oracle Coherence Security Framework

To enable the security framework in an Oracle WebLogic server domain:

  1. From the Summary of Coherence Clusters page, click a Coherence Cluster to configure its settings.
  2. From the cluster's settings page, click the Security tab.
  3. From the General tab, click the Security Framework Enabled option to enable the security framework.
  4. Click Save.

Specifying an Identity for Use by the Security Framework

The Oracle Coherence security framework requires a principal (identity) when performing authentication. The SSL Demo Identity keystore is used by default and contains a default SSL identity (DemoIdentity). The SSL Demo keystore and identity are typically used during development. For production environments, you should create an SSL keystore and identity. For example, use the Java keytool utility to create a keystore that contains an admin identity:

keytool -genkey -v -keystore ./keystore.jks -storepass password -alias admin
-keypass password -dname CN=Administrator,O=MyCompany,L=MyCity,ST=MyState

Note:

If you create an SSL keystore and identity, you must configure Oracle WebLogic Server to use that SSL keystore and identity. In addition, the same SSL identity must be located in the keystore of every managed Coherence server in the cluster. Use the Keystores and SSL tabs on the Settings page for a managed Coherence server to configure a keystore and identity.

To override the default SSL identity and specify an identity for use by the security framework:

  1. From the Summary of Coherence Clusters page, click a Coherence Cluster to configure its settings.
  2. From the cluster's settings page, click the Security tab.
  3. From the General tab, click the Security Framework Enabled option to enable the security framework if it has not already been enabled.
  4. In the Private Key Alias field, enter the alias for the identity.
  5. In the Private Key Pass Phrase field, enter the password for the identity.
  6. In the Confirm Private Key Pass Phrase field, re-enter the password.
  7. Click Save.

Authorizing Oracle Coherence Caches and Services

Oracle WebLogic Server authorization can be used to secure Oracle Coherence resources that run within a domain. In particular, different roles and policies can be created to control access to caches and services. Authorization is enabled by default and the default authorization policy gives all users access to all Oracle Coherence resources. See Overview of Securing WebLogic Resources in Securing Resources Using Roles and Policies for Oracle WebLogic Server.

Authorization roles and policies are explicitly configured for caches and services. You must know the cache names and service names that are to be secured. In some cases, inspecting the cache configuration file may provide the cache names and service names. However, because of wildcard support for cache names in Oracle Coherence, you may need to consult an application developer or architect that knows the cache names being used by an application. For example, a cache mapping in the cache configuration file could use a wildcard (such as * or dist-*) and does not indicate the name of the cache that is actually used in the application.

Note:

Deleting a service or cache resource does not delete roles and policies that are defined for the resource. Roles and policies must be explicitly deleted before deleting a service or cache resource.

This section includes the following topics:

Specifying Cache Authorization

Oracle WebLogic Server authorization can be used to restrict access to specific Oracle Coherence caches. To specify cache authorization:

  1. From the Summary of Coherence Clusters page, click a Coherence Cluster to configure its settings.
  2. From the cluster's settings page, click the Security tab and Caches subtab.
  3. Click New to define a cache on which roles and polices will be defined. The Create a Coherence Cache page displays.
  4. Enter the name of a cache in the Name field. The name of the cache must exactly match the name of the cache used in an application.
  5. Click Finish. The cache is listed on the Coherence Caches page.
  6. Click the cache to access its settings page where you can define scoped roles and policies using the Roles and Policies tab, respectively. For example, you can create a policy that allows specific users to access the cache. The users can be selected based on their membership in a global role, or a Coherence-specific scoped role can be created and used to define which users can access the cache. See Overview of Securing WebLogic Resources in Securing Resources Using Roles and Policies for Oracle WebLogic Server.

Specifying Service Authorization

Oracle WebLogic Server authorization can be used to restrict access to Oracle Coherence services. Specifying authorization on a cache service (for example a distributed cache service) affects access to all the caches that are created by that service.

To specify service authorization:

  1. From the Summary of Coherence Clusters page, click a Coherence Cluster to configure its settings.
  2. From the cluster's settings page, click the Security tab and Services subtab.
  3. Click New to define a service to which roles and polices will be defined. The Create a Coherence Service page displays.
  4. Enter the name of a service in the Name field. The name of the service must exactly match the name of the service used in an application.

    Note:

    The exact name must include the scope name as a prefix to the service name. The scope name can be explicitly defined in the cache configuration file or, more commonly, taken from the deployment module name. For example, if you deploy a GAR named contacts.gar that defines a service named ContactsService, then the exact service name is contacts:ContactsService.

  5. Click Finish. The service is listed on the Coherence Services page.
  6. Click the service to access its settings page where you can define scoped roles and policies using the Roles and Policies tab, respectively. For example, you can create a policy that allows specific users to access the service. The users can be selected based on their membership in a global role, or a Coherence-specific scoped role can be created and used to define which users can access the service. See Overview of Securing WebLogic Resources in Securing Resources Using Roles and Policies for Oracle WebLogic Server.

Securing Extend Client Access with Identity Tokens

Identity tokens are used to protect against unauthorized access to an Oracle Coherence cluster through an Oracle Coherence proxy server. Identity tokens are used by local (within WebLogic Server) extend clients and remote (outside of WebLogic Server) Java, C++, and .NET extend clients.

Only clients that pass a valid identity token are permitted to access cluster services. If a null identity token is passed (a client connecting without being within the scope of a Subject), then the client is treated as an Oracle WebLogic Server anonymous user. The extend client is able to access caches and services that the anonymous user can access.

Note:

Upon establishing and identity, an authorization policy should be used to restrict that identity to specific caches and services. See Authorizing Oracle Coherence Caches and Services.

Identity token security requires an identity transformer implementation that creates an identity token and an identity asserter implementation that validates the identity token. A default identity transformer implementation (DefaultIdentityTransformer) and identity asserter implementation (DefaultIdentityAsserter) are provided. The default implementations use a Subject or Principal as the identity token. However, custom implementations can be created as required to support any security token type (for example, to support Kerberos tokens). See Using Identity Tokens to Restrict Client Connections.

This section includes the following topics:

Enabling Identity Transformers for Use in Oracle WebLogic Server

An identity transformer associates an identity token with an identity. For local (within Oracle WebLogic Server) extend clients, the default identity transformer cannot be replaced. The default identity transformer passes a token of type weblogic.security.acl.internal.AuthenticatedSubject representing the current Oracle WebLogic Server user.

For remote (outside of Oracle WebLogic Server) extend clients, the identity transformer implementation class must be included as part of the application's classpath and the fully qualified name of the implementation class must be defined in the client operational override file. See Enabling a Custom Identity Transformer. The following example enables the default identity transformer:

...
<security-config>
   <identity-transformer>
      <class-name>
         com.tangosol.net.security.DefaultIdentityTransformer</class-name>
   </identity-transformer>
</security-config>
...

Remote extend clients must execute cache operations within the Subject.doAS method. For example,

Principal principal = new WLSUserImpl("user");
Subject subject = new Subject();
subject.getPrincipals().add(principal);

Subject.doAs(subject, new PrivilegedExceptionAction()
   {
      NamedCache cache = CacheFactory.getCache("mycache");
      ...

Enabling Identity Asserters for Use in Oracle WebLogic Server

Identity asserters must be enabled for an Oracle Coherence cluster and are used to assert (validate) a client's identity token. For local (within Oracle WebLogic Server) extend clients, the an identity asserter is already enabled for asserting a token of type weblogic.security.acl.internal.AuthenticatedSubject.

For remote (outside of Oracle WebLogic Server) extend clients, a custom identity asserter implementation class must be packaged in a GAR. However, an identity asserter is not required if the remote extend client passes null as the token. If the proxy service receives a non-null token and there is no identity asserter implementation class configured, a SecurityException is thrown and the connection attempt is rejected.

To enable an identity asserter for a cluster:

  1. From the Summary of Coherence Clusters page, click a Coherence Cluster to configure its settings.
  2. From the cluster's settings page, click the Security tab.
  3. From the General tab, use the Identity Assertion fields to enter the fully qualified name of the asserter class and, if required, any class constructor arguments. For example, to use the default identity asserter, enter:
    com.tangosol.net.security.DefaultIdentityAsserter
    
  4. Click Save.
  5. Restart the cluster servers or redeploy the GAR for the changes to take effect.