This chapter describes how to configure security in Oracle Event Processing, including configuring a security provider, SSL and FIPS, as well as configuring HTTPS-only connections and the security auditor.
This chapter includes the following sections:
Section 10.1, "Overview of Security in Oracle Event Processing"
Section 10.2, "Configuring Java SE Security for Oracle Event Processing Server"
Section 10.6, "Configuring FIPS for Oracle Event Processing Server"
Section 10.7, "Configuring HTTPS-Only Connections for Oracle Event Processing Server"
Section 10.8, "Configuring Security for Oracle Event Processing Server Services"
Section 10.9, "Configuring Cross-Domain Security for Oracle Event Processing Visualizer"
Section 10.10, "Configuring the Oracle Event Processing Security Auditor"
Oracle Event Processing provides a variety of mechanisms to protect server resources such as data and event streams, configuration, username and password data, security policy information, remote credentials, and network traffic.
To configure security for Oracle Event Processing server, consider the following general tasks:
Configure Java SE security.
Configure a security provider for authorization and authentication.
See:
Configure password strength.
Configure SSL and FIPS.
See:
Configure HTTPS-only connections.
See Section 10.7, "Configuring HTTPS-Only Connections for Oracle Event Processing Server".
Configure security for individual Oracle Event Processing server services.
See Section 10.8, "Configuring Security for Oracle Event Processing Server Services"
For more information, see:
Section 10.1.8, "Specifying User Credentials When Using the Command-Line Utilities"
Section 10.1.9, "Security in Oracle Event Processing Examples and Domains"
You can define Java SE security policies for:
All the bundles that make up Oracle Event Processing
Server startup
Web applications deployed to the Oracle Event Processing server Jetty HTTP server
Oracle Event Processing Visualizer
For more information, see:
Oracle Event Processing supports various security providers for authentication, authorization, role mapping, and credential mapping.
Oracle Event Processing supports the following security providers:
File-based—Default out-of-the-box security provider. This type of provider uses an operating system file to access security data such as user, password, and group information. Provides both authentication (process whereby identity of users is proved or verified) and authorization (process whereby a user's access to an Oracle Event Processing resource is permitted or denied based on the user's security role and the security policy assigned to the requested Oracle Event Processing resource). Authentication typically involves username/password combinations.
LDAP—Provider that uses a Lightweight Data Access Protocol (LDAP) server to access user, password, and group information. Provides only authentication.
DBMS—Provider that uses a database management system (DBMS) to access user, password, and group information. Provides both authentication and authorization.
If you choose to use the default file-based security provider, then you do not need to do any further configuration of your domain; the Configuration Wizard performs all necessary configuration. However, if you want to use the LDAP or DBMS providers, you must perform further configuration. See Section 10.3, "Configuring a Security Provider"
Once you have configured the security provider, you can start using Oracle Event Processing Visualizer to add new users, assign them to groups, and map groups to roles. See Section 10.1.3, "Users, Groups, and Roles".
Oracle Event Processing uses role-based authorization control to secure the Oracle Event Processing Visualizer and the wlevs.Admin command-line utility. There are a variety of default out-of-the-box security groups. You can add users to different groups to give them the different roles.
Administrators who use Oracle Event Processing Visualizer, wlevs.Admin, or any custom administration application that uses JMX to connect to an Oracle Event Processing instance use role-based authorization to gain access.
You can also use role-based authorization to control access to the HTTP publish-subscribe server.
There are two types of role:
Application roles: application roles grant users the permission to access various Oracle CQL applications deployed to the Oracle Event Processing server. You can create application roles and associate them with the task roles that Oracle Event Processing provides.
By default, administrator users can access any application and non-administration users cannot access any applications. Before a none-administration user can access an application, an administration user must grant the user the associated application role.
Task roles: task roles grant users the permission to perform various tasks with the applications their application role authorizes them to access. Oracle Event Processing provides the default task roles that Table 10-1 describes.
Users that successfully authenticate themselves when using Oracle Event Processing Visualizer or wlevs.Admin are assigned roles based on their group membership, and then subsequent access to administrative functions is restricted according to the roles held by the user. Anonymous users (non-authenticated users) will not have any access to the Oracle Event Processing Visualizer or wlevs.Admin.
When an administrator uses the Configuration Wizard to create a new domain, they enter an administrator user that will be part of the wlevsAdministrators group. By default, this information is stored in a file-based provider filestore. The password is hashed using the SHA-256 algorithm. The default administrator user is named wlevs with password wlevs.
Table 10-1 describes the default Oracle Event Processing tasks roles available right after the creation of a new domain, as well as the name of the groups that are assigned to these roles.
Table 10-1 Default Oracle Event Processing Task Roles and Groups
| Task Role | Group | Privileges |
|---|---|---|
|
|
wlevsAdministrators |
Has all privileges of all the preceding roles, as well as permission to:
|
|
|
wlevsApplicationAdmins |
Has all Operator privileges as well as permission to update the configuration of any deployed application. |
|
|
wlevsBusinessUsers |
Has all Operator privileges as well as permission to update the Oracle CQL and EPL rules associated with the processor of a deployed application. |
|
|
wlevsDeployers |
Has all Operator privileges as well as permission to deploy, undeploy, update, suspend, and resume any deployed application. |
|
|
wlevsMonitors |
Has all Operator privileges as well as permission to enable/disable diagnostic functions, such as creating a diagnostic profile and recording events (then playing them back.) |
|
|
wlevsOperators |
Has read-only access to all server resources, services, and deployed applications. |
Once the domain has been created, the administrator can use Oracle Event Processing Visualizer to create a group and associate it with one or more roles: each role grants access to an application. When you assign a user to a group, the roles you associate with the group give the user the privileges to access those applications.
For instructions on using Oracle Event Processing Visualizer to modify users, groups, and roles, see:
"Managing Users" in the Oracle Fusion Middleware Visualizer User's Guide for Oracle Event Processing
"Managing Groups" in the Oracle Fusion Middleware Visualizer User's Guide for Oracle Event Processing
"Managing Roles" in the Oracle Fusion Middleware Visualizer User's Guide for Oracle Event Processing
For more information, see:
Section 10.8.4, "Configuring HTTP Publish-Subscribe Server Channel Security"
Section 10.1.8, "Specifying User Credentials When Using the Command-Line Utilities"
Chapter 3, "Administering Oracle Event Processing Standalone-Server Domains"
Chapter 5, "Administering Multi-Server Domains With Oracle Coherence"
Chapter 7, "Administering Multi-Server Domains With Oracle Event Processing Native Clustering"
Oracle Event Processing provides one-way Secure Sockets Layer (SSL) to secure network traffic between Oracle Event Processing Visualizer and Oracle Event Processing server instances, between the Oracle Event Processing server instances of a multi-server domain, and between the wlevs.Admin command-line utility and Oracle Event Processing server instances.
You can configure Oracle Event Processing to use a Federal Information Processing Standards (FIPS)-certified pseudo-random number generator for SSL.
For more information, see:
Section 5.3, "Securing the Messages Sent Between Servers in a Multi-Server Domain"
Oracle Coherence: Section 7.3, "Securing the Messages Sent Between Servers in a Multi-Server Domain"
Oracle Event Processing Native Clustering: Section A.4, "Running wlevs.Admin Utility in SSL Mode"
The National Institute of Standards and Technology (NIST) creates standards for Federal computer systems. NIST issues these standards as Federal Information Processing Standards (FIPS) for use government-wide.
Oracle Event Processing supports FIPS using the com.rsa.jsafe.provider.JsafeJCE security provider. Using this provider, you can configure Oracle Event Processing to use a FIPS-certified pseudo-random number generator for SSL.
For more information, see:
After you configure SSL, you can configure the Oracle Event Processing server to accept only client requests on the HTTPS port. See Section 10.7, "Configuring HTTPS-Only Connections for Oracle Event Processing Server".
Optionally, you can disable security. See Section 10.11, "Disabling Security".
Oracle Event Processing provides a variety of command-line utilities to simplify security administration. In addition to command-line utilities, you can use Oracle Event Processing Visualizer to perform many security tasks.
For more information, see:
Oracle Event Processing provides the following command-line utilities for performing a variety of tasks:
wlevs.Admin: a command-line interface to administer Oracle Event Processing and, in particular, dynamically configure the rules for Oracle CQL and EPL processors and monitor the event latency and throughput of an application.
See Appendix A, "wlevs.Admin Command-Line Reference" for details
Deployer: a Java-based deployment utility that provides administrators and developers command-line based operations for deploying Oracle Event Processing applications.
See Appendix B, "Deployer Command-Line Reference" for details.
cssconfig: a command-line utility to generate a security configuration file (security.xml) that uses a password policy.
See Appendix C, "The cssconfig Command-Line Utility" for details.
encryptMSAConfig: an encryption command-line utility to encrypt cleartext passwords, specified by the password element, in XML files.
See Appendix C, "The encryptMSAConfig Command-Line Utility" for details.
For each utility, you can specify user credentials (username and password) using the following three methods:
On the command line using options such as -user and -password.
Interactively so that the command line utility always prompts for the credentials.
Specifying a filestore that stores the user credentials; the filestore itself is also password protected.
In a production environment you should never use the first option (specifying user credentials on the command line) but rather use only the second and third option.
When using interactive mode (command-line utility prompts for credentials), be sure you have the appropriate terminalio native libraries for your local computer in your CLASSPATH so that the user credentials are not echoed on the screen when you type them. Oracle Event Processing includes a set of standard native libraries for this purpose, but it may not include the specific one you need.
When you use the Configuration Wizard to create a new domain, you specify the administrator user and password, as well as the password to the domain identity keystore. This user is automatically added to the wlevsAdministrators group. All security configuration is stored using a file-based provider, by default.
All Oracle Event Processing examples are configured to have an administrator with username wlevs and password wlevs. When you create a new domain you specify the administrator name and password.
By default, security is disabled in the HelloWorld example. This means that any user can start the server, deploy applications, and run all commands of the administration tool (wlevs.Admin) without providing a password.
Security is enabled in the FX and AlgoTrading examples. In both examples, the user wlevs, with password wlevs, is configured to be the Oracle Event Processing administrator with full administrator privileges. The scripts to start the server for these examples use the appropriate arguments to pass this username and password to the java command. If you use the Deployer or wlevs.Admin utility, you must also pass this username/password pair using the appropriate arguments.
For more information, see Section 10.1.8, "Specifying User Credentials When Using the Command-Line Utilities".
The Java SE platform defines a standards-based and interoperable security architecture that is dynamic and extensible. Security features — cryptography, authentication and authorization, public key infrastructure, and more — are built in.
Oracle Event Processing supports Java SE security by using the following security policies:
policy.xml—Defines the security policies of all the bundles that make up Oracle Event Processing. The first bundle set defines the policies for server-related bundles; the second bundle set defines the policies for application bundles.
security.policy—Defines the security policies for server startup and Web applications deployed to the Jetty HTTP server. This file also defines policies for the Oracle Event Processing Visualizer Web application.
Samples of the preceding files are shipped with the product and can be found in ORACLE_CEP_HOME/ocep_11.1/utils/security, where ORACLE_CEP_HOME refers to the directory in which you installed Oracle Event Processing, such as /oracle_home.
You can enable all Java SE security features with Oracle Event Processing.
For more information, see Section 10.1.1, "Java SE Security".
To configure Java SE security on the Oracle Event Processing server:
Stop the Oracle Event Processing server, if it is currently running.
See Section 1.5.4, "Starting and Stopping Oracle Event Processing Servers".
Copy policy.xml and security.policy:
From: ORACLE_CEP_HOME/ocep_11.1/utils/security
To: DOMAIN_DIR/servername/config
Where ORACLE_CEP_HOME refers to the directory in which you installed Oracle Event Processing (such as /oracle_home), DOMAIN_DIR refers to the main Oracle Event Processing installation directory, servername refers to the name of your server (such as /oracle_cep/user_projects/domains/mydomain/myserver/config).
Edit the two security policy files to suit your needs.
Update the server startup script for your platform located in the DOMAIN_DIR/servername directory, startwlevs.cmd (Windows) or startwlevs.sh (UNIX), by adding the following three properties to the java command that actually starts the server:
-Djava.security.manager -Djava.security.policy=./config/security.policy -Dcom.bea.core.security.policy=./config/policy.xml
For example (in practice, the full command should be on one line):
"%JAVA_HOME%\bin\java" %DGC% %DEBUG% -Djava.security.manager -Djava.security.policy=./config/security.policy -Dcom.bea.core.security.policy=./config/policy.xml -Dwlevs.home="%USER_INSTALL_DIR%" -Dbea.hoe="%BEA_HOME%" -jar "%USER_INSTALL_DIR%\bin\wlevs.jar" %1 %2 %3 %4 %5 %6
Update the DOMAIN_DIR/servername/config/config.xml file of your Oracle Event Processing server and edit the Jetty configuration by adding a <scratch-directory> child element of the <jetty> element to specify the directory to which Jetty Web applications are deployed. For example:
<jetty>
<name>JettyServer</name>
<network-io-name>NetIO</network-io-name>
<work-manager-name>JettyWorkManager</work-manager-name>
<secure-network-io-name>sslNetIo</secure-network-io-name>
<scratch-directory>./JettyWork</scratch-directory>
</jetty>
Restart the Oracle Event Processing server for the changes to take effect.
See Section 1.5.4, "Starting and Stopping Oracle Event Processing Servers".
A security provider performs authentication, authorization, or both.
Oracle Event Processing server supports file-based, LDAP, and DBMS security providers.
The file-based security provider is the default security provider that the Configuration Wizard configures. If you want to use the file-based security provider, no further configuration is required.
The LDAP security provider supports authentication only.
The DBMS security provider supports both authentication and authorization.
This section describes:
For more information, see Section 10.1.2, "Security Providers".
The following procedure describes how to configure the LDAP security provider for authentication and the DBMS provider for authorization.
Caution:
When using LDAP for authentication, you can not add or delete users and groups using Oracle Event Processing Visualizer, you can only change the password of a user.
To configure authentication using the LDAP provider and Authorization using the DBMS provider:
Open a command window and set your environment as described in "Setting Your Development Environment" in the Oracle Fusion Middleware Developer's Guide for Oracle Event Processing for Eclipse.
Add the ORACLE_CEP_HOME\ocep_11.1\bin directory to your PATH environment variable, where ORACLE_CEP_HOME is the main Oracle Event Processing installation directory, such as d:\oracle_cep:
prompt> set PATH=d:\oracle_cep\ocep_11.1\bin;%PATH% (Windows) prompt> PATH=/oracle_cep/ocep_11.1/bin:$PATH (UNIX)
Change to the DOMAIN_DIR/servername/config directory, where DOMAIN_DIR refers to the main directory of your domain, such as d:\oracle_cep\user_projects\domains\mydomain, and servername refers to the name of your server:
prompt> cd d:\oracle_cep\user_projects\domains\mydomain\defaultserver\config
Using your favorite text editor, create a file called myLDAPandDBMS.properties and copy into it the entire contents of Example 10-1.
Example 10-1 LDAP/DBMS Properties File
# For attributes of type boolean or Boolean, value can be "true" or "false"
# and it's case insensitive.
# For attributes of type String[], values are comma separated; blanks before
# and after the comma are ignored. For example, if the property is defined as:
# saml1.IntersiteTransferURIs=uri1, uri2, uri3
# the IntersiteTransferURIs attribute value is String[]{"uri1", "uri2", "uri3"}
# For attributes of type Properties, the value should be inputted as
# a set of key=value pairs separated by commas; blanks before and after the
# commas are also ignored. For example (in practice, the property should be all on one line):
# store.StoreProperties=DriverName=oracle.jdbc.driver.OracleDriver,
ConnectionURL=jdbc:oracle:thin:@united.bea.com:1521:xe, Username=user, Password=user
domain.mbean=com.bea.common.management.configuration.LegacyDomainInfoMBean
domain.DomainName=legacy-domain-name
domain.ServerName=legacy-server-name
domain.RootDirectory=legacy-rootdir
#domain.ProductionModeEnabled=
#domain.WebAppFilesCaseInsensitive=
domain.DomainCredential=changeit
jaxp.mbean=com.bea.common.management.configuration.JAXPFactoryServiceMBean
#jaxp.DocBuilderFactory=
#jaxp.SaxParserFactory=
#jaxp.SaxTransformFactory=
#jaxp.TransformFactory=
#ldapssl.mbean=com.bea.common.management.configuration.LDAPSSLSocketFactoryLookupServiceMBean
#ldapssl.Protocol=
#ldapssl.TrustManagerClassName=
namedsql.mbean=com.bea.common.management.configuration.NamedSQLConnectionLookupServiceMBean
store.mbean=com.bea.common.management.configuration.StoreServiceMBean
# Split here for readability; in practice, a property should be all on one line.
store.StoreProperties=DriverName=oracle.jdbc.driver.OracleDriver,
ConnectionURL=jdbc:oracle:thin:@localhost:1521:orcl, Username=wlevs, Password=wlevs
#store.ConnectionProperties=
#store.NotificationProperties=
realm.mbean=weblogic.management.security.RealmMBean
realm.Name=my-realm
#realm.ValidateDDSecurityData=
#realm.CombinedRoleMappingEnabled=
#realm.EnableWebLogicPrincipalValidatorCache=
#realm.MaxWebLogicPrincipalsInCache=
#realm.DelegateMBeanAuthorization=
#realm.AuthMethods=
adt.1.mbean=weblogic.security.providers.audit.DefaultAuditorMBean
adt.1.Severity=INFORMATION
#adt.1.InformationAuditSeverityEnabled=
#adt.1.WarningAuditSeverityEnabled=
#adt.1.ErrorAuditSeverityEnabled=
#adt.1.SuccessAuditSeverityEnabled=
#adt.1.FailureAuditSeverityEnabled=
#adt.1.OutputMedium=
#adt.1.RotationMinutes=
#adt.1.BeginMarker=
#adt.1.EndMarker=
#adt.1.FieldPrefix=
#adt.1.FieldSuffix=
adt.1.Name=my-auditor
#adt.1.ActiveContextHandlerEntries=
atn.1.mbean=weblogic.security.providers.authentication.LDAPAuthenticatorMBean
#atn.1.UserObjectClass=
#atn.1.UserNameAttribute=
#atn.1.UserDynamicGroupDNAttribute=
atn.1.UserBaseDN=o=ECS,dc=bea,dc=com
atn.1.UserSearchScope=subtree
#atn.1.UserFromNameFilter=
#atn.1.AllUsersFilter=
atn.1.GroupBaseDN=ECS,dc=bea,dc=com
#atn.1.GroupSearchScope=
#atn.1.GroupFromNameFilter=
#atn.1.AllGroupsFilter=
#atn.1.StaticGroupObjectClass=
#atn.1.StaticGroupNameAttribute=
atn.1.StaticMemberDNAttribute=member
#atn.1.StaticGroupDNsfromMemberDNFilter=
#atn.1.DynamicGroupObjectClass=
#atn.1.DynamicGroupNameAttribute=
#atn.1.DynamicMemberURLAttribute=
atn.1.GroupMembershipSearching=unlimited
atn.1.MaxGroupMembershipSearchLevel=0
atn.1.UseRetrievedUserNameAsPrincipal=false
#atn.1.IgnoreDuplicateMembership=
#atn.1.KeepAliveEnabled=
atn.1.Credential=wlevs
#atn.1.Name=
#atn.1.PropagateCauseForLoginException=
atn.1.ControlFlag=REQUIRED
#atn.1.ConnectTimeout=
atn.1.Host=localhost
atn.1.Port=389
#atn.1.SSLEnabled=
atn.1.Principal=cn=Administrator,dc=bea,dc=com
#atn.1.CacheEnabled=
#atn.1.CacheSize=
#atn.1.CacheTTL=
atn.1.FollowReferrals=false
#atn.1.BindAnonymouslyOnReferrals=
#atn.1.ResultsTimeLimit=
#atn.1.ParallelConnectDelay=
#atn.1.ConnectionRetryLimit=
atn.1.EnableGroupMembershipLookupHierarchyCaching=true
#atn.1.MaxGroupHierarchiesInCache=
#atn.1.GroupHierarchyCacheTTL=
#atn.5.mbean=weblogic.security.providers.authentication.OpenLDAPAuthenticatorMBean
#atn.5.UserNameAttribute=
#atn.5.UserBaseDN=
#atn.5.UserFromNameFilter=
#atn.5.GroupBaseDN=
#atn.5.GroupFromNameFilter=
#atn.5.StaticGroupObjectClass=
#atn.5.StaticMemberDNAttribute=
#atn.5.StaticGroupDNsfromMemberDNFilter=
#atn.5.UserObjectClass=
#atn.5.UserDynamicGroupDNAttribute=
#atn.5.UserSearchScope=
#atn.5.AllUsersFilter=
#atn.5.GroupSearchScope=
#atn.5.AllGroupsFilter=
#atn.5.StaticGroupNameAttribute=
#atn.5.DynamicGroupObjectClass=
#atn.5.DynamicGroupNameAttribute=
#atn.5.DynamicMemberURLAttribute=
#atn.5.GroupMembershipSearching=
#atn.5.MaxGroupMembershipSearchLevel=
#atn.5.UseRetrievedUserNameAsPrincipal=
#atn.5.IgnoreDuplicateMembership=
#atn.5.KeepAliveEnabled=
#atn.5.Credential=
#atn.5.PropagateCauseForLoginException=
#atn.5.ControlFlag=
#atn.5.Name=
#atn.5.ConnectTimeout=
#atn.5.Host=
#atn.5.Port=
#atn.5.SSLEnabled=
#atn.5.Principal=
#atn.5.CacheEnabled=
#atn.5.CacheSize=
#atn.5.CacheTTL=
#atn.5.FollowReferrals=
#atn.5.BindAnonymouslyOnReferrals=
#atn.5.ResultsTimeLimit=
#atn.5.ParallelConnectDelay=
#atn.5.ConnectionRetryLimit=
#atn.5.EnableGroupMembershipLookupHierarchyCaching=
#atn.5.MaxGroupHierarchiesInCache=
#atn.5.GroupHierarchyCacheTTL=
cm.1.mbean=weblogic.security.providers.credentials.DefaultCredentialMapperMBean
cm.1.Name=my-credential-mapper
cm.1.CredentialMappingDeploymentEnabled=true
#cm.3.mbean=weblogic.security.providers.credentials.FileBasedCredentialMapperMBean
#cm.3.FileStorePath=
#cm.3.FileStorePassword=
#cm.3.EncryptAlgorithm=
#cm.3.Name=
#cm.3.CredentialMappingDeploymentEnabled=
rm.1.mbean=weblogic.security.providers.xacml.authorization.XACMLRoleMapperMBean
rm.1.Name=my-role-mapper
rm.1.RoleDeploymentEnabled=true
atz.1.mbean=weblogic.security.providers.xacml.authorization.XACMLAuthorizerMBean
atz.1.Name=my-authorizer
atz.1.PolicyDeploymentEnabled=true
adj.1.mbean=weblogic.security.providers.authorization.DefaultAdjudicatorMBean
adj.1.RequireUnanimousPermit=false
adj.1.Name=my-adjudicator
Customize the property file by updating the store.StoreProperties property to reflect your database driver information, connection URL, and username and password of the user that connects to the database. This is how the default property is set:
# Split for readability; in practice, the property should be on one line. store.StoreProperties=DriverName=oracle.jdbc.driver.OracleDriver, ConnectionURL=jdbc:oracle:thin:@mymachine:1521:orcl, Username=wlevs, Password=wlevs
Also update the property that specifies your LDAP server configuration.
Leave all the other properties to their default values.
Make a backup copy of the existing security.xml file, in case you need to revert:
prompt> copy security.xml security.xml_save
Create a new security configuration file (security.xml) by executing the following cssconfig command:
prompt> cssconfig -p myLDAPandDBMS.properties -c security.xml -i security-key.dat
In the preceding command, myLDAPandDBMS.properties is the property file you created in step 4, security.xml is the name of the new security configuration file, and security-key.dat is an existing file, generated by the Configuration Wizard, that contains the identity key.
See Section C.1, "The cssconfig Command-Line Utility" for additional information.
Change to the ORACLE_CEP_HOME/ocep_11.1/utils/security/sql directory:
prompt> cd d:\oracle_cep\ocep_11.1\utils\security\sql
This directory contains SQL scripts for creating the required security-related database tables and populating them with initial data. Because you are using the DBMS provider only for authorization, the relevant scripts for this procedure are:
atz_create.sql—Creates all tables required for authorization.
atz_drop.sql—Drops all authorization-related tables.
Run the following SQL script against the database you specified as the database store in step 4:
atz_create.sql
Configure your LDAP server by adding the default groups described in Section 10.1.3, "Users, Groups, and Roles" as well as the administrator user you specified when you created the domain. By default, this user is called wlevs.
Refer to your LDAP server documentation for details.
Optionally, configure password strength in your new security.xml file.
The following procedure describes how to configure the DBMS security provider for both authentication and authorization.
To configure both authentication and authorization using the DBMS provider:
Open a command window and set your environment as described in "Setting Your Development Environment" in the Oracle Fusion Middleware Developer's Guide for Oracle Event Processing for Eclipse.
Add the ORACLE_CEP_HOME\ocep_11.1\bin directory to your PATH environment variable, where ORACLE_CEP_HOME is the main Oracle Event Processing installation directory, such as d:\oracle_cep:
prompt> set PATH=d:\oracle_cep\ocep_11.1\bin;%PATH% (Windows) prompt> PATH=/oracle_cep/ocep_11.1/bin:$PATH (UNIX)
Change to the DOMAIN_DIR/servername/config directory, where DOMAIN_DIR refers to the main directory of your domain, such as d:\oracle_cep\user_projects\domains\mydomain, and servername refers to the name of your server:
prompt> cd d:\oracle_cep\user_projects\domains\mydomain\defaultserver\config
Make a backup copy of the existing security.xml file, in case you need to revert:
prompt> copy security.xml security.xml_save
Using your favorite text editor, create a file called myDBMS.properties and copy into it the entire contents of Example 10-2.
Example 10-2 DBMS Property File
# For attributes of type boolean or Boolean, value can be "true" or "false"
# and it's case insensitive.
# For attributes of type String[], values are comma separated; blanks before
# and after the comma are ignored. For example, if the property is defined as:
# saml1.IntersiteTransferURIs=uri1, uri2, uri3
# the IntersiteTransferURIs attribute value is String[]{"uri1", "uri2", "uri3"}
# For attributes of type Properties, the value should be inputted as
# a set of key=value pairs separated by commas; blanks before and after the
# commas are also ignored. For example (split for readability; in practice, the property should be all on one line):
# store.StoreProperties=DriverName=oracle.jdbc.driver.OracleDriver,
ConnectionURL=jdbc:oracle:thin:@united.bea.com:1521:xe, Username=user, Password=user
domain.mbean=com.bea.common.management.configuration.LegacyDomainInfoMBean
domain.DomainName=legacy-domain-name
domain.ServerName=legacy-server-name
domain.RootDirectory=legacy-rootdir
#domain.ProductionModeEnabled=
#domain.WebAppFilesCaseInsensitive=
domain.DomainCredential=changeit
jaxp.mbean=com.bea.common.management.configuration.JAXPFactoryServiceMBean
#jaxp.DocBuilderFactory=
#jaxp.SaxParserFactory=
#jaxp.SaxTransformFactory=
#jaxp.TransformFactory=
#ldapssl.mbean=com.bea.common.management.configuration.LDAPSSLSocketFactoryLookupServiceMBean
#ldapssl.Protocol=
#ldapssl.TrustManagerClassName=
namedsql.mbean=com.bea.common.management.configuration.NamedSQLConnectionLookupServiceMBean
store.mbean=com.bea.common.management.configuration.StoreServiceMBean
# Split for readability; the property should be fully on one line.
store.StoreProperties=DriverName=oracle.jdbc.driver.OracleDriver,
ConnectionURL=jdbc:oracle:thin:@mymachine:1521:orcl, Username=wlevs, Password=wlevs
#store.ConnectionProperties=
#store.NotificationProperties=
realm.mbean=weblogic.management.security.RealmMBean
realm.Name=my-realm
#realm.ValidateDDSecurityData=
#realm.CombinedRoleMappingEnabled=
#realm.EnableWebLogicPrincipalValidatorCache=
#realm.MaxWebLogicPrincipalsInCache=
#realm.DelegateMBeanAuthorization=
#realm.AuthMethods=
sqlconn.1.mbean=com.bea.common.management.configuration.NamedSQLConnectionMBean
sqlconn.1.Name=POOL1
sqlconn.1.JDBCDriverClassName=oracle.jdbc.driver.OracleDriver
sqlconn.1.ConnectionPoolCapacity=5
sqlconn.1.ConnectionPoolTimeout=10000
sqlconn.1.AutomaticFailoverEnabled=false
sqlconn.1.PrimaryRetryInterval=0
sqlconn.1.JDBCConnectionURL=jdbc\:oracle\:thin\:@fwang02\:1521\:orcl
sqlconn.1.JDBCConnectionProperties=
sqlconn.1.DatabaseUserLogin=wlevs
sqlconn.1.DatabaseUserPassword=wlevs
sqlconn.1.BackupJDBCConnectionURL=
sqlconn.1.BackupJDBCConnectionProperties=
sqlconn.1.BackupDatabaseUserLogin=
sqlconn.1.BackupDatabaseUserPassword=
adt.1.mbean=weblogic.security.providers.audit.DefaultAuditorMBean
adt.1.Severity=INFORMATION
#adt.1.InformationAuditSeverityEnabled=
#adt.1.WarningAuditSeverityEnabled=
#adt.1.ErrorAuditSeverityEnabled=
#adt.1.SuccessAuditSeverityEnabled=
#adt.1.FailureAuditSeverityEnabled=
#adt.1.OutputMedium=
#adt.1.RotationMinutes=
#adt.1.BeginMarker=
#adt.1.EndMarker=
#adt.1.FieldPrefix=
#adt.1.FieldSuffix=
adt.1.Name=my-auditor
#adt.1.ActiveContextHandlerEntries=
atn.1.mbean=weblogic.security.providers.authentication.SQLAuthenticatorMBean
atn.1.PasswordAlgorithm=SHA-1
atn.1.PasswordStyle=SALTEDHASHED
atn.1.PasswordStyleRetained=true
atn.1.SQLCreateUser=INSERT INTO USERS VALUES ( ? , ? , ? )
atn.1.SQLRemoveUser=DELETE FROM USERS WHERE U_NAME \= ?
atn.1.SQLRemoveGroupMemberships=DELETE FROM GROUPMEMBERS WHERE G_MEMBER \= ? ORG_NAME \= ?
atn.1.SQLSetUserDescription=UPDATE USERS SET U_DESCRIPTION \= ? WHERE U_NAME \= ?
atn.1.SQLSetUserPassword=UPDATE USERS SET U_PASSWORD \= ? WHERE U_NAME \= ?
atn.1.SQLCreateGroup=INSERT INTO GROUPS VALUES ( ? , ? )
atn.1.SQLSetGroupDescription=UPDATE GROUPS SET G_DESCRIPTION \= ? WHERE G_NAME \= ?
atn.1.SQLAddMemberToGroup=INSERT INTO GROUPMEMBERS VALUES( ?, ?)
atn.1.SQLRemoveMemberFromGroup=DELETE FROM GROUPMEMBERS WHERE G_NAME \= ? AND G_MEMBER \= ?
atn.1.SQLRemoveGroup=DELETE FROM GROUPS WHERE G_NAME \= ?
atn.1.SQLRemoveGroupMember=DELETE FROM GROUPMEMBERS WHERE G_NAME \= ?
atn.1.SQLListGroupMembers=SELECT G_MEMBER FROM GROUPMEMBERS WHERE G_NAME \= ? AND G_MEMBER LIKE ?
atn.1.DescriptionsSupported=true
atn.1.SQLGetUsersPassword=SELECT U_PASSWORD FROM USERS WHERE U_NAME \= ?
atn.1.SQLUserExists=SELECT U_NAME FROM USERS WHERE U_NAME \= ?
atn.1.SQLListMemberGroups=SELECT G_NAME FROM GROUPMEMBERS WHERE G_MEMBER \= ?
atn.1.SQLListUsers=SELECT U_NAME FROM USERS WHERE U_NAME LIKE ?
atn.1.SQLGetUserDescription=SELECT U_DESCRIPTION FROM USERS WHERE U_NAME \= ?
atn.1.SQLListGroups=SELECT G_NAME FROM GROUPS WHERE G_NAME LIKE ?
atn.1.SQLGroupExists=SELECT G_NAME FROM GROUPS WHERE G_NAME \= ?
atn.1.SQLIsMember=SELECT G_MEMBER FROM GROUPMEMBERS WHERE G_NAME \= ? AND G_MEMBER \= ?
atn.1.SQLGetGroupDescription=SELECT G_DESCRIPTION FROM GROUPS WHERE G_NAME \= ?
atn.1.GroupMembershipSearching=unlimited
atn.1.MaxGroupMembershipSearchLevel=0
atn.1.DataSourceName=POOL1
atn.1.PlaintextPasswordsEnabled=true
atn.1.ControlFlag=REQUIRED
atn.1.Name=my-authenticator
atn.1.EnableGroupMembershipLookupHierarchyCaching=false
atn.1.MaxGroupHierarchiesInCache=100
atn.1.GroupHierarchyCacheTTL=60
cm.1.mbean=weblogic.security.providers.credentials.DefaultCredentialMapperMBean
cm.1.Name=my-credential-mapper
cm.1.CredentialMappingDeploymentEnabled=true
rm.1.mbean=weblogic.security.providers.xacml.authorization.XACMLRoleMapperMBean
rm.1.Name=my-role-mapper
rm.1.RoleDeploymentEnabled=true
atz.1.mbean=weblogic.security.providers.xacml.authorization.XACMLAuthorizerMBean
atz.1.Name=my-authorizer
atz.1.PolicyDeploymentEnabled=true
adj.1.mbean=weblogic.security.providers.authorization.DefaultAdjudicatorMBean
adj.1.RequireUnanimousPermit=false
adj.1.Name=my-adjudicator
Customize the property file by updating the store.StoreProperties property to reflect your database driver information, connection URL, and username and password of the user that connects to the database. This is how the default property is set (in practice, this setting should be on one line):
store.StoreProperties=DriverName=oracle.jdbc.driver.OracleDriver, ConnectionURL=jdbc:oracle:thin:@mymachine:1521:orcl, Username=wlevs, Password=wlevs
Leave all the other properties to their default values.
Create a new security configuration file (security.xml) by executing the following cssconfig command:
prompt> cssconfig -p myDBMS.properties -c security.xml -i security-key.dat
In the preceding command, myDBMS.properties is the property file you created in step 4, security.xml is the name of the new security configuration file, and security-key.dat is an existing file, generated by the Configuration Wizard, that contains the identity key.
See Section C.1, "The cssconfig Command-Line Utility" for additional information.
Change to the ORACLE_CEP_HOME/ocep_11.1/utils/security/sql directory:
prompt> cd d:\oracle_cep\ocep_11.1\utils\security\sql
This directory contains SQL scripts for creating the required security-related database tables and populating them with initial data. These scripts are:
atn_create.sql—Creates all tables required for authentication.
atn_drop.sql—Drops all authentication-related tables.
atn_init.sql—Inserts default values into the authentication-related user and group tables. In particular, the script inserts a single default administrator user called wlevs, with password wlevs, into the user table and specifies that the user belongs to the wlevsAdministrators group. The script also inserts the default groups listed in Table 10-1 into the group table.
atz_create.sql—Creates all tables required for authorization.
atz_drop.sql—Drops all authorization-related tables.
If, when you created your domain using the Configuration Wizard, you specified an administrator user other than the default wlevs, edit the atn_init.sql file and add the INSERT INTO USERS and corresponding INSERT INTO GROUPMEMBERS statements accordingly.
For example, to add an administrative user juliet, with password shackell, add the following statements to the atn_init.sql file:
INSERT INTO USERS (U_NAME, U_PASSWORD, U_DESCRIPTION) VALUES ('juliet','shackell','default admin');
INSERT INTO GROUPMEMBERS (G_NAME, G_MEMBER) VALUES ('wlevsAdministrators','juliet');
Run the following SQL script files, in the order listed, against the database you specified as the database store in step 4:
atn_create.sql
atn_init.sql
atz_create.sql
Optionally, configure password strength in your new security.xml file.
Password strength is a measurement of the effectiveness of a password as an authentication credential. How the password strength is configured determines the type of password a user can specify, such as whether the password can contain the username, the minimum length of the password, the minimum number of numeric characters it can contain, and so on.
You configure the strength of the passwords used for Oracle Event Processing authentication by updating the security configuration file (security.xml), located in the DOMAIN_DIR/servername/config directory, where DOMAIN_DIR refers to your domain directory, such as d:/oracle_cep/user_projects/domains/mydomain, and servername refers to your server, such as defaultserver.
The password strength configuration is contained in the <password-validator> element.
Example 10-3 shows a snippet from the security.xml file with the default values after creating a new domain using the Configuration Wizard.
Example 10-3 Default password-validator Element in the security.xml File
<sec:password-validator
xmlns:pas="http://www.bea.com/ns/weblogic/90/security/providers/passwordvalidator"
xsi:type="pas:system-password-validatorType">
<sec:name>my-password-validator</sec:name>
<pas:reject-equal-or-contain-username>true</pas:reject-equal-or-contain-username>
<pas:reject-equal-or-contain-reverse-username>
false
</pas:reject-equal-or-contain-reverse-username>
<pas:max-password-length>50</pas:max-password-length>
<pas:min-password-length>6</pas:min-password-length>
<pas:max-instances-of-any-character>0</pas:max-instances-of-any-character>
<pas:max-consecutive-characters>0</pas:max-consecutive-characters>
<pas:min-alphabetic-characters>1</pas:min-alphabetic-characters>
<pas:min-numeric-characters>1</pas:min-numeric-characters>
<pas:min-lowercase-characters>1</pas:min-lowercase-characters>
<pas:min-uppercase-characters>1</pas:min-uppercase-characters>
<pas:min-non-alphanumeric-characters>0</pas:min-non-alphanumeric-characters>
</sec:password-validator>
Table 10-2 describes all the child elements of <password-validator> you can configure.
If you manually update the security.xml file, you must restart the Oracle Event Processing server instance for the changes to take effect.
Table 10-2 Child Elements of <password-validator>
| Child Element | Description | Default Value |
|---|---|---|
|
|
When set to When set to |
|
|
|
When set to When set to |
|
|
|
Specifies the maximum length of a password. A value of 0 means there is no restriction. Valid values for this element are integers greater than or equal to 0. |
50 |
|
|
Specifies the minimum length of a password. Valid values for this element are integers greater than or equal to 0. |
6 |
|
|
Specifies the maximum number of times the same character can appear in the password. For example, if this element is set to 2, then the password A value of 0 means there is no restriction. Valid values for this element are integers greater than or equal to 0. |
0 |
|
|
Specifies the maximum number of repeating consecutive characters that are allowed in the password. For example, if this element is set to 2, then the password A value of 0 means there is no restriction. Valid values for this element are integers greater than or equal to 0. |
0 |
|
|
Specifies the minimum number of alphabetic characters that a password must contain. A value of 0 means there is no restriction. Valid values for this element are integers greater than or equal to 0. |
1 |
|
|
Specifies the minimum number of numeric characters that a password must contain. A value of 0 means there is no restriction. Valid values for this element are integers greater than or equal to 0. |
1 |
|
|
Specifies the minimum number of lowercase characters that a password must contain. A value of 0 means there is no restriction. Valid values for this element are integers greater than or equal to 0. |
0 |
|
|
Specifies the minimum number of uppercase characters that a password must contain. A value of 0 means there is no restriction. Valid values for this element are integers greater than or equal to 0. |
0 |
|
|
Specifies the minimum number of non-alphanumeric characters that a password must contain. Non-alphanumeric characters include A value of 0 means there is no restriction. Valid values for this element are integers greater than or equal to 0. |
0 |
Oracle Event Processing uses one-way Secure Sockets Layer (SSL) to secure the network traffic between:
A browser running the Oracle Event Processing Visualizer and the Oracle Event Processing instance that hosts the data-services application that the Oracle Event Processing Visualizer uses.
The wlevs.Admin command-line utility and an Oracle Event Processing instance.
The member servers of a multi-server domain.
You configure SSL in the server's config.xml file. When you create an Oracle Event Processing server using the Configuration Wizard, the server's config.xml automatically includes a default SSL configuration.
This section describes:
For more information, see Section 10.1.4, "SSL".
This section describes how to configure SSL in Oracle Event Processing.
Create a domain using the Configuration Wizard.
See:
Using your favorite XML editor, open the Oracle Event Processing server config.xml file.
By default, the Configuration Wizard creates the config.xml file in the ORACLE_CEP_HOME/user_projects/domains/DOMAIN_DIR/servername/config directory, where ORACLE_CEP_HOME refers to the Oracle Event Processing installation directory (such as d:/oracle_cep), DOMAIN_DIR refers to the domain directory (such as my_domain), and servername refers to the server instance directory (such as server1).
For more information, see Section 1.3.1, "Oracle Event Processing Server Configuration Files".
Example 10-4 shows the default ssl element the Configuration Wizard creates.
Example 10-4 Default ssl Element
<ssl>
<name>sslConfig</name>
<key-store>./ssl/evsidentity.jks</key-store>
<key-store-pass>
<password>{Salted-3DES}sdlUX8aEDeNpQ4VhsaCnFA==</password>
</key-store-pass>
<key-store-alias>evsidentity</key-store-alias>
<key-manager-algorithm>SunX509</key-manager-algorithm>
<ssl-protocol>TLS</ssl-protocol>
<enforce-fips>false</enforce-fips>
<need-client-auth>false</need-client-auth>
</ssl>
The key-store element points to a certificate file. The Configuration Wizard creates a default certificate file, called evsidentity.jks, in the DOMAIN_DIR/servername/ssl directory; its password is the same as that entered when creating a server with the Configuration Wizard.
By default, the password for the certificate private key will be the same as the password for the identity keystore.
Note:
The Oracle Event Processing Server will not start unless the password for certificate private key is the same as the password for the identity keystore.
The evsidentity.jks contains a self-signed certificate. Optionally, create your own certificate file and either replace the evsidentity.jks file, or update the key-store element in the config.xml file.
Note:
In a production environment, the system administrator should replace the default self-signed certificate with a CA signed certificate.
For more information on creating a key-store yourself, see Section 10.5.2, "How to Create a Key-Store Manually".
For more information on the enforce-fips element, see Section 10.6, "Configuring FIPS for Oracle Event Processing Server".
Configure a netio element for SSL.
Example 10-5 shows the default netio element the Configuration Wizard creates.
Example 10-5 Default netio Element
<netio>
<name>sslNetIo</name>
<ssl-config-bean-name>sslConfig</ssl-config-bean-name>
<port>9003</port>
</netio>
The ssl-config-bean-name must match the ssl element name child element (see step 3).
Optionally, change this port to a port number that suits your needs.
The default secure port is 9003 by default.
Configure the jetty element to add a secure-network-io-name child element.
Example 10-6 shows the default jetty element the Configuration Wizard creates.
Example 10-6 Default jetty Element
<jetty>
<name>JettyServer</name>
<network-io-name>NetIO</network-io-name>
<work-manager-name>JettyWorkManager</work-manager-name>
<secure-network-io-name>sslNetIo</secure-network-io-name>
</jetty>
The secure-network-io-name must match the SSL netio element name child element (see step 4).
Save and close the config.xml file.
Restart the Oracle Event Processing server (if running).
See Section 1.5.4, "Starting and Stopping Oracle Event Processing Servers".
By default, the Configuration Wizard creates a default key-store certificate file, called evsidentity.jks, in the DOMAIN_DIR/servername/ssl directory; its password is the same as that entered when creating a server with the Configuration Wizard. Optionally, you can manually create your own key-store.
For more information, see:
To create a key-store manually:
Use the JDK keytool command to generate a key-store:
keytool -genkey -alias evsidentity -keyalg RSA -validity 10958 -keystore evsidentity.jks -keysize 1024
Enter the key-store password, as prompted:
Enter keystore password:
Enter the key-store attributes, as prompted:
What is your first and last name? [Unknown]: CEP What is the name of your organizational unit? [Unknown]: SOA What is the name of your organization? [Unknown]: ORACLE What is the name of your City or Locality? [Unknown]: SF What is the name of your State or Province? [Unknown]: CA What is the two-letter country code for this unit? [Unknown]: US Is CN=CEP, OU=SOA, O=ORACLE, L=SF, ST=CA, C=US correct? [no]: y
When prompted for a key password, do not enter a password; just press RETURN:
Enter key password for <evsidentity>
(RETURN if same as keystore password):
Note:
The Oracle Event Processing Server will not start unless the password for certificate private key is the same as the password for the identity keystore.
Using your favorite XML editor, open the Oracle Event Processing server config.xml file.
By default, the Configuration Wizard creates the config.xml file in the ORACLE_CEP_HOME/user_projects/domains/DOMAIN_DIR/servername/config directory, where ORACLE_CEP_HOME refers to the Oracle Event Processing installation directory (such as d:/oracle_cep), DOMAIN_DIR refers to the domain directory (such as my_domain), and servername refers to the server instance directory (such as server1).
For more information, see Section 1.3.1, "Oracle Event Processing Server Configuration Files".
Configure the ssl element.
Example 10-4 shows the default ssl element the Configuration Wizard creates.
Example 10-7 Default ssl Element
<ssl>
<name>sslConfig</name>
<key-store>KEYSTORE_PATH</key-store>
<key-store-pass>
<password>PASSWORD</password>
</key-store-pass>
<key-store-alias>KEYSTORE_ALIAS</key-store-alias>
<key-manager-algorithm>SunX509</key-manager-algorithm>
<ssl-protocol>TLS</ssl-protocol>
<enforce-fips>false</enforce-fips>
<need-client-auth>false</need-client-auth>
</ssl>
Where:
KEYSTORE_PATH is the file path to the key-store file (the file name is from the -keystore argument to the keytool command).
PASSWORD is the cleartext keystore password.
KEYSTORE_ALIAS is the keystore alias (from the -alias argument to the keytool command).
Save and close the config.xml file.
Encrypt the cleartext password in the key-store-pass element password child element of the config.xml file by using the encryptMSAConfig utility.
See Section C.2, "The encryptMSAConfig Command-Line Utility."
The following procedure shows how to configure one-way SSL between the server that hosts the Oracle Event Processing Visualizer data-services application and another server in a multi-server domain.
In the procedure, it is assumed that the server that hosts the Oracle Event Processing Visualizer data-services application is called server1 and the other server is called server2, and that both are located in the /oracle_cep/user_projects/domains/mydomain directory. Repeat this procedure for other servers in the domain, if required.
For information on securing the messages sent between servers in a multi=-server domain, see:
Oracle Coherence: Section 5.3, "Securing the Messages Sent Between Servers in a Multi-Server Domain"
Oracle Event Processing Native Clustering: Section 7.3, "Securing the Messages Sent Between Servers in a Multi-Server Domain"
For information on starting Oracle Event Processing Visualizer in a multi-server domain, see "How to Start Oracle Event Processing Visualizer in a Multi-Server Domain" in the Oracle Fusion Middleware Visualizer User's Guide for Oracle Event Processing.
To configure SSL in a multi-server domain for use by Oracle Event Processing Visualizer:
Ensure that SSL is configured for the two servers in the domain.
If you used the Configuration Wizard to create the servers, then SSL is configured by default.
See Section 10.5.1, "How to Configure SSL Manually" for details, as well as information on how to change the default configuration.
Start server2.
See Section 1.5.4, "Starting and Stopping Oracle Event Processing Servers".
Open a command window and set your environment as described in "Setting Your Development Environment" in the Oracle Fusion Middleware Developer's Guide for Oracle Event Processing for Eclipse.
Change to the ssl sub-directory of the server1 directory:
prompt> cd /oracle_cep/user_projects/domains/mydomain/server1/ssl
Generate a trust keystore for server1 that includes the certificate of server2 by specifying the following command (split for readability; in practice, the command should be on one line):
prompt> java -classpath ORACLE_CEP_HOME\ocep_11.1\common\lib\evspath.jar;ORACLE_CEP_HOME\ocep_11.1\utils\security\wlevsgrabcert.jar com.bea.wlevs.security.util.GrabCert host:secureport -alias=alias truststorepath
where
ORACLE_CEP_HOME refers to the Oracle Event Processing installation directory (such as d:/oracle_cep)
host refers to the computer on which server2 is running.
secureport refers to the SSL network i/o port configured for server2. Default value is 9003.
For more information, see Example 10-5 in Section 10.5.1, "How to Configure SSL Manually."
alias refers to the alias for the certificate in the trust keystore. Default value is the hostname.
truststorepath refers to the full pathname of the generated trust keystore file; default is evstrust.jks
For example (split for readability; in practice, the command should be on one line):
prompt> java -classpath C:\OracleCEP\ocep_11.1\common\lib\evspath.jar;C:\OracleCEP\ocep_11.1\utils\security\wlevsgrabcert.jar com.bea.wlevs.security.util.GrabCert server2:9003 -alias=server2 evstrust.jks
For more information, see Section C.3, "The GrabCert Command-Line Utility".
When prompted, enter the Oracle Event Processing administrator password:
Please enter the Password for the supplied user : wlevs
When prompted, select the certificate sent by server2:
Created TrustStore evstrust.jks Opening connection to server2:9003... Starting SSL handshake... No certificates in evstrust.jks are trusted by server2:9003 Server sent 1 certificate(s): 1 Subject CN=localhost, OU=Event Server, O=BEA, L=San Jose, ST=California, C=US Issuer CN=localhost, OU=Event Server, O=BEA, L=San Jose, ST=California, C=US sha1 00 07 c0 f4 10 48 9a f9 07 82 4f b6 9c 7f 7c d0 37 57 90 7d md5 a4 d4 ff d2 43 69 95 ca c3 43 e6 f6 b8 08 df b7 Enter certificate to add to trusted keystore evstrust.jks or 'q' to quit: [1]
Update the config.xml file of server1, adding trust keystore information to the ssl element and adding a use-secure-connections element, as shown in bold in the following snippet:
<ssl>
<name>sslConfig</name>
<key-store>./ssl/evsidentity.jks</key-store>
<key-store-pass>
<password>{Salted-3DES}s4YUEvH4Wl2DAjb45iJnrw==</password>
</key-store-pass>
<key-store-alias>evsidentity</key-store-alias>
<key-manager-algorithm>SunX509</key-manager-algorithm>
<ssl-protocol>TLS</ssl-protocol>
<trust-store>./ssl/evstrust.jks</trust-store>
<trust-store-pass>
<password>wlevs</password>
</trust-store-pass>
<trust-store-alias>evstrust</trust-store-alias>
<trust-store-type>JKS</trust-store-type>
<trust-manager-algorithm>SunX509</trust-manager-algorithm>
<enforce-fips>false</enforce-fips>
<need-client-auth>false</need-client-auth>
</ssl>
<use-secure-connections>
<value>true</value>
</use-secure-connections>
The config file is located in the config subdirectory of the main server directory, such as /oracle_cep/user_projects/domains/mydomain/server1/config/.
Encrypt the cleartext password in the trust-store-pass element password child element of the config.xml file by using the encryptMSAConfig utility.
See Section C.2, "The encryptMSAConfig Command-Line Utility."
Start server1.
You can configure Oracle Event Processing server to use a Federal Information Processing Standards (FIPS)-certified pseudo-random number generator.
For more information, see Section 10.1.5, "FIPS".
To configure FIPS for Oracle Event Processing server:
Configure Java SE security.
See Section 10.2, "Configuring Java SE Security for Oracle Event Processing Server".
Configure SSL.
See Section 10.5, "Configuring SSL to Secure Network Traffic".
Copy com.bea.core.jsafejcefips_version.jar:
From: ORACLE_CEP_HOME/ocep_11.1/utils/security
To: JRE_HOME/jre/lib/ext
Where ORACLE_CEP_HOME refers to the directory in which you installed Oracle Event Processing and JRE_HOME refers to the directory that contains your JRockit JRE:
If using the JRockit JDK installed with Oracle JRockit Real Time, copy the com.bea.core.jsafejcefips_version.jar into the JROCKIT_HOME/JROCKIT_RT_HOME/jre/lib/ext directory.
Where JROCKIT_HOME is the directory in which you installed Oracle JRockit Real Time, such as d:\jrockit.
If using the JRockit JDK installed with Oracle Event Processing, copy the com.bea.core.jsafejcefips_version.jar into the ORACLE_CEP_HOME/JROCKIT_HOME/jre/lib/ext directory.
Where ORACLE_CEP_HOME is the directory in which you installed Oracle Event Processing server such as d:\oracle_cep.
Stop the Oracle Event Processing server, if it is currently running.
See Section 1.5.4, "Starting and Stopping Oracle Event Processing Servers".
Edit the JRE_HOME/jre/lib/security/java.security file to add com.bea.core.jsafejcefips_2.0.0.0.jar as a JCE provider as Example 10-8 shows.
Example 10-8 Editing java.security to Add jsafejcefips JAR as a JCE Provider
security.provider.N=com.rsa.jsafe.provider.JsafeJCE
Where N is a unique integer that specifies the order in which Java accesses security providers.
To make the JsafeJCE provider the default provider, set N to 1. In this case, change the value of N for any other providers in the java.security file so that each provider has a unique number as Example 10-9 shows.
Edit the server.config file ssl element as Example 10-10 shows to add the following child elements:
enforce-fips: set this option to true.
secure-random-algorithm: set this option to FIPS186PRNG
secure-random-provider: set this option to JsafeJCE.
Example 10-10 Editing server.config to Enable Fips
<ssl>
<name>sslConfig</name>
<key-store>./ssl/evsidentity.jks</key-store>
<key-store-pass>
<password>s4YUEvH4Wl2DAjb45iJnrw==</password>
</key-store-pass>
<key-store-alias>evsidentity</key-store-alias>
<key-manager-algorithm>SunX509</key-manager-algorithm>
<ssl-protocol>TLS</ssl-protocol>
<enforce-fips>true</enforce-fips>
<need-client-auth>false</need-client-auth>
<secure-random-algorithm>FIPS186PRNG</secure-random-algorithm>
<secure-random-provider>JsafeJCE</secure-random-provider>
</ssl>
Restart the Oracle Event Processing server for the changes to take effect.
See Section 1.5.4, "Starting and Stopping Oracle Event Processing Servers".
This section describes how to lock down the server so that only HTTPS connections are allowed.
To configure HTTPS-Only connections for Oracle Event Processing server:
Ensure that SSL is configured for the server.
See Section 10.5, "Configuring SSL to Secure Network Traffic" for details.
Remove the HTTP port configuration from the server's DOMAIN_DIR/servername/config/config.xml file, leaving only the configuration for the HTTPS port.
Example 10-11 shows a config.xml snippet with a standard configuration in which both an HTTP and HTTPS port have been configured. The HTTP port is 9002 and the HTTPS port is 9003. Clients can access the Jetty server using both ports.
Example 10-11 Typical config.xml File With Both HTTP and HTTPS Access
<netio> <name>NetIO</name> <port>9002</port> </netio> <netio> <name>sslNetIo</name> <port>9003</port> <ssl-config-bean-name>sslConfig</ssl-config-bean-name> </netio> <jetty> <name>JettyServer</name> <network-io-name>NetIO</network-io-name> <secure-network-io-name>sslNetIo</secure-network-io-name> ... </jetty> <ssl> <name>sslConfig</name> <key-store>./ssl/evsidentity.jks</key-store> ... </ssl>
Example 10-12 shows the same config.xml file with HTTP access removed. Clients can now access the Jetty server only using the HTTPS port.
Example 10-12 Typical config.xml File With HTTP Access Removed
<netio> <name>sslNetIo</name> <port>9003</port> <ssl-config-bean-name>sslConfig</ssl-config-bean-name> </netio> <jetty> <name>JettyServer</name> <secure-network-io-name>sslNetIo</secure-network-io-name> ... </jetty> <ssl> <name>sslConfig</name> <key-store>./ssl/evsidentity.jks</key-store> ... </ssl>
If you have a multi-server domain, be sure that SSL has been configured between the member servers.
See Section 10.5.3, "How to Configure SSL in a Multi-Server Domain for Oracle Event Processing Visualizer" for details.
After you complete basic security tasks such as configuring Java SE security, a security service provider, and SSL, you can configure security details specific to the various services that Oracle Event Processing server provides.
This section describes:
Oracle Event Processing supports Jetty (see http://www.mortbay.org/) as Java Web server to deploy HTTP servlets and static resources.
The following security tasks affect Jetty configuration:
For more information on Jetty, see Chapter 11, "Configuring Jetty for Oracle Event Processing".
Clients that access the Oracle Event Processing server using JMX are subject to Oracle Event Processing role-based authentication.
For more information, see:
"Managing Groups" in the Oracle Fusion Middleware Visualizer User's Guide for Oracle Event Processing
"Managing Users" in the Oracle Fusion Middleware Visualizer User's Guide for Oracle Event Processing
For more information about JMX, see Chapter 12, "Configuring JMX for Oracle Event Processing".
If you update a data-source with a new password using the Configuration Wizard, the Configuration Wizard performs password encryption for you.
If you update the config.xml file manually by adding or modifying a data-source element, you enter the password in plain text and then encrypt the password using the encryption utility encryptMSAConfig.
Example 10-13 shows a config.xml file data-source element with a new plain text password secret specified in the properties element with name password.
Example 10-13 Oracle Event Processing config.xml File data-source Element After Encryption
<data-source>
<name>epcisDS</name>
<driver-params>
<url>jdbc:sqlserver://localhost:1433;databaseName=myDB;SelectMethod=cursor</url>
<driver-name>com.microsoft.sqlserver.jdbc.SQLServerDriver</driver-name>
<properties>
<element>
<name>user</name>
<value>juliet</value>
</element>
<element>
<name>password</name>
<value>secret</value>
</element>
</properties>
</driver-params>
</data-source>
<transaction-manager>
<name>TM</name>
<rmi-service-name>RMI</rmi-service-name>
</transaction-manager>
Example 10-14 shows the config.xml file data-source element after encryption. Note the plain text password has been encrypted.
Example 10-14 Oracle Event Processing config.xml File data-source Element After Encryption
<data-source>
<name>epcisDS</name>
<driver-params>
<url>jdbc:sqlserver://localhost:1433;databaseName=myDB;SelectMethod=cursor</url>
<driver-name>com.microsoft.sqlserver.jdbc.SQLServerDriver</driver-name>
<properties>
<element>
<name>user</name>
<value>juliet</value>
</element>
<element>
<name>password</name>
<value>{Salted-3DES}hVgC5iZ3nZA=</value>
</element>
</properties>
</driver-params>
</data-source>
<transaction-manager>
<name>TM</name>
<rmi-service-name>RMI</rmi-service-name>
</transaction-manager>
For more information, see:
For more information about JDBC, see Chapter 13, "Configuring JDBC for Oracle Event Processing"
After you configure at least one HTTP publish-subscribe server channel, you can use role-based authentication to control access to individual HTTP publish-subscribe server channels using the Oracle Event Processing Visualizer.
For more information, see:
Chapter 14, "Configuring HTTP Publish-Subscribe for Oracle Event Processing"
"Configuring Security for the HTTP Publish-Subscribe Channels" in the Oracle Fusion Middleware Visualizer User's Guide for Oracle Event Processing.
Oracle Event Processing Visualizer provides an Adobe Flash-based user interface with which you can create and configure event processing networks. In order to provide the most flexible default performance for Oracle Event Processing Visualizer, the software is installed with a configured trust level that allows access to Visualizer data from any domain. If you find that this trust level is inappropriate for your deployment, you can edit the application's Flash cross-domain policy file in order to restrict access.
You should review the domains which are allowed by the Flash cross-domain policy and determine whether it is appropriate for the application to fully trust both the intentions and security posture of those domains.
You'll find a more thorough description on editing cross-domain policy at the Adobe web site. For more information on using Adobe cross-domain policy files, see the Adobe security web site.
Updating cross-domain security involves opening the Oracle Event Processing Visualizer JAR file. Here are the high-level steps:
Locate the Oracle Event Processing Visualizer JAR file. By default in an Oracle Event Processing installation, you'll find it at:
CEP_HOME/modules/com.bea.wlevs.visualizer.jmxhttpadapter_version.jar
For example, on a Windows installation, that might be:
C:\Oracle\Middleware\ocep_11.1\modules\com.bea.wlevs.visualizer.jmxhttpadapter_11.1.1.6_0.jar
Expand the JAR file to locate crossdomain.war.
Expand crossdomain.war to locate crossdomain.xml.
Edit crossdomain.xml to reflect your cross-domain security needs.
Repackage crossdomain.war and the Oracle Event Processing Visualizer JAR file.
Oracle Event Processing provides a security auditor that logs security-related activity.
By default, the security auditor logs to DOMAIN_DIR/servername/legacy-rootdir/servers/legacy-server-name/logs/DefaultAuditRecorder.log file, where DOMAIN_DIR refers to the main directory of your domain, such as d:\oracle_cep\user_projects\domains\mydomain, and servername refers to the name of your server.
By default, the Oracle Event Processing security auditor will only log security errors or failures. This helps keep the security auditor log file at a manageable size.
Optionally, you can configure the level at which the Oracle Event Processing security auditor logs information.
For more information, see "Configuring the WebLogic Auditing Provider" in the Oracle Fusion Middleware Securing Oracle WebLogic Server.
To configure security auditor logging:
Change to the DOMAIN_DIR/servername/config directory, where DOMAIN_DIR refers to the main directory of your domain, such as d:\oracle_cep\user_projects\domains\mydomain, and servername refers to the name of your server:
prompt> cd d:\oracle_cep\user_projects\domains\mydomain\defaultserver\config
Using your favorite text editor, edit the security.xml file.
Locate the sec:auditor element.
Example 10-15 shows the default sec:auditor element configuration:
Example 10-15 Default sec:auditor Element
<sec:auditor xsi:type="wls:default-auditorType">
<sec:name>my-auditor</sec:name>
<wls:severity>CUSTOM</wls:severity>
<wls:rotation-minutes>720</wls:rotation-minutes>
<wls:error-audit-severity-enabled>true</wls:error-audit-severity-enabled>
<wls:failure-audit-severity-enabled>true</wls:failure-audit-severity-enabled>
</sec:auditor>
Modify the sec:auditor element as required:
wls:rotation-minutes: Specifies how many minutes to wait before creating a new DefaultAuditRecorder.log file. At the specified time, the audit file is closed and a new one is created. A backup file named DefaultAuditRecorder.YYYYMMDDHHMM.log (for example, DefaultAuditRecorder.200405130110.log) is created in the same directory.
wls:severity: Specifies the severity level appropriate for your Oracle Event Processing server as Table 10-3 lists. The Oracle Event Processing security auditor audits security events of the specified severity, as well as all events with a higher numeric severity rank. For example, if you set the severity level to ERROR, the Oracle Event Processing security auditor audits security events of severity level ERROR, SUCCESS, and FAILURE.
Table 10-3 Oracle Event Processing Security Auditor Severity Levels
| Event Severity | Rank |
|---|---|
|
|
1 |
|
|
2 |
|
|
3 |
|
|
4 |
|
|
5 |
You can also set the wls:severity level to CUSTOM, and then enable (set to true) or disable (set to false) the specific severity levels you want to audit using one or more of the following child elements as Example 10-15 shows:
wls:information-audit-severity-enabled: If the severity value is set to CUSTOM, setting this child element to true causes the Oracle Event Processing security auditor to generate audit records for events with a severity level of INFORMATION.
wls:warning-audit-severity-enabled: If the severity value is set to CUSTOM, setting this child element to true causes the Oracle Event Processing security auditor to generate audit records for events with a severity level of WARNING.
wls:error-audit-severity-enabled: If the severity value is set to CUSTOM, setting this child elemnent to true causes the Oracle Event Processing security auditor to generate audit records for events with a severity level of ERROR.
wls:success-audit-severity-enabled: If the severity value is set to CUSTOM, setting this child elemnent to true causes the Oracle Event Processing security auditor to generate audit records for events with a severity level of SUCCESS.
wls:failure-audit-severity-enabled: If the severity value is set to CUSTOM, setting this child elemnent to true causes the Oracle Event Processing security auditor to generate audit records for events with a severity level of FAILURE.
Save and close the security.xml file.
Restart the Oracle Event Processing server for the changes to take effect.
See Section 1.5.4, "Starting and Stopping Oracle Event Processing Servers".
You can disable security entirely on the Oracle Event Processing server. While this configuration may be appropriate for development environments, Oracle does not recommend disabling security in a production environment.
To temporarily disable security, you can run the startwlevs.cmd or startwlevs.sh script with the -disablesecurity argument on the command line. For example:
startwlevs.cmd -disablesecurity
Note:
In some sample domains, the startwlevs.cmd and startwlevs.sh scripts already include a -disablesecurity argument. Executing such a script with -disablesecurity on the command line will fail with an Illegal argument error.