This chapter includes the following sections:
There are several security features that can be used when deploying Oracle 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.
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. For details on the access controller, 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. For details on configuring keystores, identity and trust in Oracle WebLogic Server, see Administering Security for Oracle WebLogic Server.
To enable the security framework in an Oracle WebLogic server domain:
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:
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. For details on creating roles and policies in Oracle WebLogic Server, see 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.
Oracle WebLogic Server authorization can be used to restrict access to specific Oracle Coherence caches. To specify cache 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:
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:
Once an identity is established, an authorization policy should be used to restrict that identity to specific caches and services. For details on configuring authorization, 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). For details on creating transformer and asserter implementations, see "Using Identity Tokens to Restrict Client Connections".
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. For details on enabling an identity transformer, 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");
...
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: