7 Securing Oracle Coherence in Oracle WebLogic Server
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. - 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. - 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. - 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.
Overview of Securing Oracle Coherence in Oracle WebLogic Server
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.
Parent topic: Securing Oracle Coherence in Oracle WebLogic Server
Securing Oracle Coherence Cluster Membership
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
- Specifying an Identity for Use by the Security Framework
Parent topic: Securing Oracle Coherence in Oracle WebLogic Server
Enabling the Oracle Coherence Security Framework
To enable the security framework in an Oracle WebLogic server domain:
- From the Summary of Coherence Clusters page, click a Coherence Cluster to configure its settings.
- From the cluster's settings page, click the Security tab.
- From the General tab, click the Security Framework Enabled option to enable the security framework.
- Click Save.
Parent topic: Securing Oracle Coherence Cluster Membership
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:
- From the Summary of Coherence Clusters page, click a Coherence Cluster to configure its settings.
- From the cluster's settings page, click the Security tab.
- From the General tab, click the Security Framework Enabled option to enable the security framework if it has not already been enabled.
- In the Private Key Alias field, enter the alias for the identity.
- In the Private Key Pass Phrase field, enter the password for the identity.
- In the Confirm Private Key Pass Phrase field, re-enter the password.
- Click Save.
Parent topic: Securing Oracle Coherence Cluster Membership
Authorizing Oracle Coherence Caches and Services
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 mappings 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:
Parent topic: Securing Oracle Coherence in Oracle WebLogic Server
Specifying Cache Authorization
Oracle WebLogic Server authorization can be used to restrict access to specific Oracle Coherence caches. To specify cache authorization:
- From the Summary of Coherence Clusters page, click a Coherence Cluster to configure its settings.
- From the cluster's settings page, click the Security tab and Caches subtab.
- Click New to define a cache on which roles and polices will be defined. The Create a Coherence Cache page displays.
- 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.
- Click Finish. The cache is listed on the Coherence Caches page.
- 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.
Parent topic: Authorizing Oracle Coherence Caches and Services
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:
Parent topic: Authorizing Oracle Coherence Caches and Services
Securing Extend Client Access with Identity Tokens
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
- Enabling Identity Asserters for Use in Oracle WebLogic Server
Parent topic: Securing Oracle Coherence in Oracle WebLogic Server
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"); ...
Parent topic: Securing Extend Client Access with Identity Tokens
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:
Parent topic: Securing Extend Client Access with Identity Tokens