This chapter includes the following sections:
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.
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:
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:
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:
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:
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:
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"); ...
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: