Administration and Configuration Guide

Configuring Security for Oracle CEP

This section contains information on the following subjects:

Overview of Security in Oracle CEP

Oracle Complex Event Processing, or Oracle CEP for short, 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.

Oracle CEP supports various security providers for authentication, authorization, role mapping, and credential mapping. As initially installed, Oracle CEP is configured to use the file-based providers for both authentication and authorization. You can also configure the system to use an LDAP or DBMS provider.

Oracle CEP uses role-based authorization control to secure the Visualizer Administration Console and the wlevs.Admin command-line utility. There are six default out-of-the-box security groups. You can add users to different groups to give them the different roles. Oracle CEP also provides one-way SSL to protect network traffic between Visualizer and the server instance upon which the data-services application runs, as well as the network traffic between server instances of a multi-server domain.

Security Providers

Oracle CEP 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 CEP resource is permitted or denied based on the user’s security role and the security policy assigned to the requested Oracle CEP 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 because the Configuration Wizard did it for you. However, if you want to use the LDAP or DBMS providers, further configuration is required.

Because the LDAP provider can be used only for authentication, while the DBMS provider can be used for both authentication and authorization, the following configurations are discussed in this section:

Once you have configured the security provider, you can start using Visualizer to add new users, assign them to groups, and map groups to roles. See Overview of Users, Groups, and Roles for general information, and then Overview of Visualizer for instructions on using Visualizer.

Overview of Users, Groups, and Roles

Administrators who use Visualizer, wlevs.Admin, or any custom administration application that uses JMX to connect to an Oracle CEP instance use role-based authorization to gain access. Users that successfully authenticate themselves when using 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 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. Once the domain has been created, the administrator can create new groups using Visualizer, assign roles to them, and then create new users and assign them to groups.

The following table describes the default Oracle CEP security 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 7-1 Available Oracle CEP Roles and Groups
Role	Description	Associated Group Name
Operator	Has read-only access to all server resources, services, and deployed applications.	wlevsOperators
Monitor	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.)	`wlevsMonitors`
ApplicationAdmin	Has all Operator privileges as well as permission to update the configuration of any deployed application.	wlevsApplicationAdmins
Deployer	Has all Operator privileges as well as permission to deploy, undeploy, update, suspend, and resume any deployed application.	wlevsDeployers
BusinessUser	Has all Operator privileges as well as permission to update the EPL rules associated with the processor of a deployed application.	wlevsBusinessUsers
Admin	Has all privileges of all the preceding roles, as well as permission to: Create users and groups Configure HTTP publish-subscribe security Change the system configuration, such as Jetty, work manager, and so on.	`wlevsAdministrators`

Security in Oracle CEP Examples and Domains

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 CEP 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 CEP 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.

Securely Specifying User Credentials When Using the Command-Line Utilities

Oracle CEP includes the following command-line utilities for performing a variety of tasks:

wlevs.Admin. See wlevs.Admin Command-Line Reference for details
Deployer. See Deployer Command-Line Reference for details.
cssconfig. See The cssconfig Command Line Utility for details.
encryptMSAConfig. See 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 CEP includes a set of standard native libraries for this purpose, but it may not include the specific one you need.

Using the LDAP Provider For Authentication and DBMS Provider for Authorization

The following procedure describes how to configure the LDAP security provider for authentication and the DBMS provider for authorization.

WARNING:

When using LDAP for authentication, you can not add or delete users and groups using Visualizer, you can only change the password of a user.

Open a command window and set your environment as described in Setting Up Your Development Environment.
Add the ORACLE_CEP_HOME\ocep_10.3\bin directory to your PATH environment variable, where ORACLE_CEP_HOME is the main Oracle CEP installation directory, such as d:\oracle_cep:

prompt> set PATH=d:\oracle_cep\ocep_10.3\bin;%PATH% (Windows)

prompt> PATH=/oracle_cep/ocep_10.3/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 the section Sample LDAP/DBMS Properties File.

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:

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 The cssconfig Command Line Utility for additional information.

Change to the ORACLE_CEP_HOME/ocep_10.3/utils/security/sql directory:

prompt> cd d:\oracle_cep\ocep_10.3\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 Overview of 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.

Sample 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:
#  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
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

Using the DBMS Provider for Both Authentication and Authorization

The following procedure describes how to configure the DBMS security provider for both authentication and authorization.

Open a command window and set your environment as described in Setting Up Your Development Environment.
Add the ORACLE_CEP_HOME\ocep_10.3\bin directory to your PATH environment variable, where ORACLE_CEP_HOME is the main Oracle CEP installation directory, such as d:\oracle_cep:

prompt> set PATH=d:\oracle_cep\ocep_10.3\bin;%PATH% (Windows)

prompt> PATH=/oracle_cep/ocep_10.3/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 the section Sample DBMS Property File.

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 The cssconfig Command Line Utility for additional information.

Change to the ORACLE_CEP_HOME/ocep_10.3/utils/security/sql directory:

prompt> cd d:\oracle_cep\ocep_10.3\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 insers the default groups listed in Table 7-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

Sample 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:
#  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
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

Configuring Password Strength

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 CEP 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. The following snippet from the security.xml file shows the default values after creating a new domain using the Configuration Wizard:

<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>

The following table describes all the child elements of <password-validator> you can configure and what they mean.

If you manually update the security.xml file, you must restart the Oracle CEP server instance for the changes to take effect.

Table 7-2
Child Element of `<password-validator>`	Description	Default Value
reject-equal-or-contain-name	When set to `true`, Oracle CEP rejects a password if it is the same as, or contains, the username. When set to `false`, Oracle CEP does not reject a password for this reason.	true
reject-equal-or-contain-reverse-username	When set to `true`, Oracle CEP rejects a password if it is the same as, or contains, the reversed username. When set to `false`, Oracle CEP does not reject a password for this reason.	false
max-password-length	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
min-password-length	Specifies the minimum length of a password. Valid values for this element are integers greater than or equal to 0.	6
max-instances-of-any-character	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 `bubble` is invalid. A value of 0 means there is no restriction. Valid values for this element are integers greater than or equal to 0.	0
max-consecutive-characters	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 `bubbble` is invalid. A value of 0 means there is no restriction. Valid values for this element are integers greater than or equal to 0.	0
min-alphabetic-characters	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
min-numeric-characters	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
min-lowercase-characters	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
min-uppercase-characters	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
min-non-alphanumeric-characters	Specifies the minimum number of non-alphanumeric characters that a password must contain. Non-alphanumeric characters include `$`, `#`, `@`, `&`, `!` and so on. A value of 0 means there is no restriction. Valid values for this element are integers greater than or equal to 0.	0

Changing the Default Administration User

When you create a server using the Configuration Wizard, you enter the name and password of the main administrative user. If you later need to change this user, follow these steps:

Using Visualizer, create a new user and assign it to the wlevsAdministrators group. Be sure that the wlevsAdministrators group is mapped to the Admin role. See Typical Security Tasks in the Visualizer online help for details.

For simplicity, assume that the new user is called cepAdmin, with password supersecret.

Update the DOMAIN_DIR/servername/config/security-config.xml file of the server, changing the values of the <boot-user-name-encrypted> and <password> child elements of <msa-security> accordingly, as shown below:

<msa-security>
   <boot-user-name-encrypted>cepAdmin</boot-user-name-encrypted>
   <password>supersecret</password>
</msa-security>

Encrypt the cleartext password in the <password> of the security-config.xml file by using the encryption utility. See The encryptMSAConfig Command Line Utility.

Using SSL to Secure Network Traffic

Oracle CEP uses 1-way SSL to secure the network traffic between:

A browser running the Visualizer Administration Console and the Oracle CEP instance that hosts the data-services application used by Visualizer.
The wlevs.Admin command-line utility and an Oracle CEP instance.
The member servers of a multi-server domain.

How SSL Is Configured in Oracle CEP

This section how SSL is configured in Oracle CEP, as well as the default SSL configuration for a new server.

SSL is configured in the server’s config.xml file. When you create an Oracle CEP server using the Configuration Wizard, the server’s config.xml automatically includes a default SSL configuration. In particular, the config.xml file includes a <netio> configuration object that specifies the secure port (9003 by default); for example:

   <netio>
      <name>sslNetIo</name>
      <ssl-config-bean-name>sslConfig</ssl-config-bean-name>
      <port>9003</port>
   </netio>

The Jetty HTTP server’s configuration in turn configures this network i/o port for its secure connection:

   <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 port is configured at the time the Configuration Wizard is run, but you can later change it to suit your needs.

The SSL configuration itself looks like the following:

   <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. The evsidentity.jks contains a self-signed certificate. You can create your own certificate file and either replace the evsidentity.jks file, or update the <key-store> element in the config.xml file.

Configuring SSL In a Multi-Server Domain for Use By Visualizer

The following procedure shows how to configure one-way SSL between the server that hosts the Visualizer data-services application and another server in a multi-server domain.

In the procedure, it is assumed that the server that hosts the Visualizer’s 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.

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 How SSL Is Configured in Oracle CEP for details, as well as information on how to change the default configuration.
Start server2.
Change to the ssl sub-directory of the main 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:

prompt> java GrabCert host:secureport [-alias=alias] [-noinput] [truststorepath]

where

host refers to the computer on which server2 is running.
secureport refers to the SSL network i/o port configured for server2; see How SSL Is Configured in Oracle CEP. Default value is 4098
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:

prompt> java GrabCert ariel:9003 -alias=ariel evstrust.jks

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}sdlUX8aEDeNpQ4VhsaCnFA==</password>
      </key-store-pass>
      <key-store-alias>evsidentity</key-store-alias>
      <key-manager-algorithm>SunX509</key-manager-algorithm>
      <trust-store>./ssl/evstrust.jks</trust-store>
      <trust-store-pass>
         <password>secret</password>
      </trust-store-pass>
      <trust-store-type>JKS</trust-store-type>
      <ssl-protocol>TLS</ssl-protocol>
      <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 <password> of the config.xml file by using the encryption utility. See The encryptMSAConfig Command Line Utility.

Disabling Security

To disable security in a domain, add the -disablesecurity flag to the java command that starts Oracle CEP in the startwlevs.cmd (Windows) or startwlevs.sh (UNIX) start script. This script is located in the server directory of your domain, such as ORACLE_CEP_HOME/user_projects/domains/wlevs30_domain/defaultserver.

The following snippet from the Windows startwlevs.cmd script shows in bold how to disable security:

%JAVA_HOME%\bin\java %DGC% %DEBUG% -Dwlevs.home=%USER_INSTALL_DIR% -Dbea.home=%BEA_HOME% -jar "%USER_INSTALL_DIR%\bin\wlevs.jar" -disablesecurity %1 %2 %3 %4 %5 %6

Locking Down the Server

This section describes how to lock down the server so that only HTTPS connections are allowed.

Ensure that SSL is configured for the server. See Using 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.

For example, the following config.xml snippet shows 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. The Jetty Server can be accessed using both ports. Only relevant parts of the config.xml file are shown:

<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>

A modified config.xml file with HTTP access removed would be as follows:

<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 Configuring SSL In a Multi-Server Domain for Use By Visualizer for details.

Configuring Java SE Security

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. For further details, see Java SE Security Overview.

Oracle CEP supports Java SE security by using the following security policies:

policy.xml—Defines the security policies of all the bundles that make up Oracle CEP. The first bundle set defines the policies for server-related bund;es; 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 Visualizer Web application.

Samples of the preceding files are shipped with the product and can be found in ORACLE_CEP_HOME/ocep_10.3/utils/security, where ORACLE_CEP_HOME refers to the directory in which you installed Oracle CEP, such as /oracle_home.

To enable all Java SE security features with Oracle CEP, follow these steps:

Stop the Oracle CEP server, if it is currently running.
Create the following two files in the DOMAIN_DIR/servername/config directory of your Oracle CEP server, where DOMAIN_DIR refers to the main Oracle CEP installation directory and servername refers to the name of your server, such as /oracle_cep/user_projects/domains/mydomain/myserver/config:

policy.xml
security.policy

Copy the sample content from the preceding links into the files.

Edit the two security policy files to suit your needs.
Update the server startup script for your platform, 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

The server startup files are located in the DOMAIN_DIR/servername directory. For example:

"%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 CEP 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 CEP server for the changes to take effect.

Security Command Line Utility Reference

Oracle CEP provides the a variety of command-line utilities for configuring security. See the following sections:

The cssconfig Command Line Utility
The encryptMSAConfig Command Line Utility
The passgen Command Line Utility (Deprecated)
The secgen Command Line Utility (Deprecated)

The cssconfig Command Line Utility

Use the cssconfig command line utility to generate a security configuration file (security.xml) that uses a password policy.

The cssconfig utility is located in the ORACLE_CEP_HOME/ocep_10.3/bin directory, where ORACLE_CEP_HOME is the main Oracle CEP installation directory, such as d:\oracle_cep. The utility comes in two flavors:

cssconfig.cmd (Windows)
cssconfig.sh (UNIX)

The Unix version of this utility starts with the #!/bin/ksh directive. On most Unix systems, this forces the Korn Shell program to be used when using the utility. If the ksh program is not present in the bin directory or if the shell language used cannot properly execute the utility, run the utility as shown below:

  prompt> $PATH_TO_KSH_BIN/ksh -c cssconfig.sh

where PATH_TO_KSH_BIN is the fully qualified path to the ksh program.

cssconfig Syntax

  cssconfig -p propertyfile [-c configfile] -i inputkeyfile [-d]

where:

propertyfile is a file that contains security configuratin properties. This option is required. property file provided by user to define what configuration s/he wants. See Sample LDAP/DBMS Properties File for an example.
configfile is the name of the generated file. This property is optional; default value is security.xml.
inputkeyfile is the fully qualified name of the input key file used to generate the security configuration file. Set this optoin to the security-key.dat file in the config directory.
-d enables debugging.

The encryptMSAConfig Command Line Utility

Use the encryptMSAConfig encryption command line utility to encrypt cleartext passwords, specified by the <password> element, in XML files. Examples of XML files that can contain the <password> elements include:

config.xml
security-config.xml
Component configuration files

The encryptMSAConfig utility is located in the ORACLE_CEP_HOME/ocep_10.3/bin directory, where ORACLE_CEP_HOME is the main Oracle CEP installation directory, such as d:\oracle_cep. The utility comes in two flavors:

encryptMSAConfig.cmd (Windows)
encryptMSAConfig.sh (UNIX)

encryptMSAConfig Syntax

  encryptMSAConfig directory XML_file msainternal.dat_file

where:

directory refers to the directory that contains the XML file which in turn contains a cleartext <password> element.
XML_file refers to the name of your XML file.
msainternal.dat_file parameter refers to the location of the .msainternal.dat file associated with your domain; this file is located in the DOMAIN_DIR/servername directory, where DOMAIN_DIR refers to the domain directory such as /oracle_cep/user_projects/domains/mydomain and servername refers to the server instance.

After you run the command, the value of the <password> element will be encrypted.

The passgen Command Line Utility

WARNING: The passgen command line utility has been deprecated as of Version 10.3 of Oracle CEP. This is because the Configuration Wizard automatically performs the required task for you.

Use the passgen command line utility to hash user passwords for addition to a security database.

The passgen utility is located in the ORACLE_CEP_HOME/ocep_10.3/bin directory, where ORACLE_CEP_HOME is the main Oracle CEP installation directory, such as d:\oracle_cep. The utility comes in two flavors:

passgen.cmd (Windows)
passgen.sh (UNIX)

passgen Syntax

  passgen [-a algorithm] [-s saltsize] [-h] [-?] [password]*

where:

Option

Description

Default Value

-a

algorithm specifies the hash algorithm to use:

SHA-1
MD2
MD5
SSHA
SHA-256

Note:

The actual list of algorithms that can be set depends on the security providers plugged into the JDK.

If not specified, the default is SHA-1.

-s

saltsize is the number of salt characters added to ensure a unique hash string.

If not specified, the default is 4.

-h, -?

Displays command line options and exits.

password

If passwords are specified on the command line they shall be hashed and printed out one per line in order from left to right. If no passwords are specified on the command line, then the tool shall prompt for passwords to hash interactively.

Note: Windows operating systems must use the .cmd version of this utility, Unix platforms should use the .sh version.

Note: The Unix version of this utility starts with the #!/bin/ksh directive. On most Unix systems, this forces the Korn Shell program to be used when using the utility. If the ksh program is not present in the bin directory or if the shell language used cannot properly execute the utility, run the utility as shown below:

Note: $PATH_TO_KSH_BIN/ksh -c passgen.sh

Note: where PATH_TO_KSH_BIN is the fully qualified path to the ksh program.

Examples of Using passgen

The following sections provide examples that use the passgen utility:

Using passgen interactively

The following is an example of using the passgen utility interactively:

     $ passgen

     Password ("quit" to end): maltese

     {SHA-1}LOtYvfQZj++4rV50AKpAvwMlQjqVd7ge

     Password ("quit" to end): falcon

     {SHA-1}u7NPQfgkHISr0tZUsmPrPmr3U1LKcAdP

     Password ("quit" to end): quit

     {SHA-1}2pPo4ViKsoNct3lTDoLeg9gHYZwQ47sV

In this mode, a password is entered and the resulting hashed version of the password is displayed. The hashed version of the password can then be entered into the password field of a security database.

Note:

In example, the passwords are shown to be echoed to the screen for demonstration purposes. In most situations, the password would not be displayed unless your platform does not support invisible passwords.

Providing a Password on the Command Line

The following is an example using the passgen utility when providing the passwords to be hashed on the command line:

     $ passgen maltese falcon

     {SHA-1}g0PNXmJW0OBtp/GkHrhNAhpbjM+capNe

     {SHA-1}2ivZnjnKD9fordC1YFkrVGf0DHL6SVP1

When multiple passwords are provided, they are hashed from left to right:

{SHA-1}g0PNXmJW0OBtp/GkHrhNAhpbjM+capNe is hashed from maltese
{SHA-1}2ivZnjnKD9fordC1YFkrVGf0DHL6SVP1 is hashed from falcon.

The secgen Command Line Utility

WARNING: The secgen command line utility has been deprecated as of Version 10.3 of Oracle CEP. This is because the Configuration Wizard automatically performs the required task for you.

Use the secgen command line utility generates a security key or a security configuration file that uses encrypted passwords.

Note:

This utility creates a security file that does not use a password policy; if you require a password policy, use the cssconfig command-line utility instead. See The cssconfig Command Line Utility.

The secgen utility is located in the ORACLE_CEP_HOME/ocep_10.3/bin directory, where ORACLE_CEP_HOME is the main Oracle CEP installation directory, such as d:\oracle_cep. The utility comes in two flavors:

secgen.cmd (Windows)
secgen.sh (UNIX)

Generating a File-Based Provider Configuration File

Use the following command line options to generate a file-based security provider configuration file.

  secgen -F [-o outputfile] [-i inputkeyfile] [-e] [-P PropertyFilePath]

where:

Option	Description	Comments
`-F`	Generate a file-based security provider file; mutually exclusive with the `-k` option.	If not present, `-k` is assumed.
`-o`	`outputfile` is the name for the generated file.	Default output file name is `security.xml`.
`-i`	`inputkeyfile` is the fully qualified name of the input key file.	If not present, a default input key file named `security-key.dat` is expected.
`-e`	Enables unanimous adjudication during authorization.
`-P`	`PropertyFilePath` is the fully qualified path to a `secgen` property file which you can use to customize provider configurations. See Using the secgen Properties File for details.	A `SecGenTemplate.properties` template file is located at `ORACLE_CEP_HOME/ocep_10.3/bin` where `ORACLE_CEP_HOME` is the main installation directory of Oracle CEP, such as `/oracle_cep`.

Generating a Key File

Use the following command line options to generate a security key file.

 secgen [-k] [-o outputfile]

where:

Option	Description	Comments
`-k`	Generate a key file; mutually exclusive with the `-F` option.	If not present, `-k` is assumed.
`-o`	`outputfile` is the name for the generated file.	Default output file name is `security-key.dat`.

Using the secgen Properties File

When running secgen, you can use the -P option to specify a property file to customize provider configurations. A SecGenTemplate.properties template file is located in ORACLE_CEP_HOME/ocep_10.3/bin where ORACLE_CEP_HOME is the main installation directory of Oracle CEP, such as /oracle_cep.

You specify cleartext passwords the property file; however, these passwords will be stored encrypted in the generated configuration file.

The following example shows a property file used for file based provider customization:

  #File based provider related
  file.atn.file.store.path=myfileatnstore.txt
  file.atn.file.store.password=firewall
  file.atn.user.password.style=HASHED
  file.atn.file.store.encrypted=true
  file.atz.file.store.path=filatz
  file.atz.file.store.password=firewall
  file.rm.file.store.path=filerm
  file.rm.file.store.password=firewall
  file.cm.file.store.path=filecm
  file.cm.file.store.password=firewall

The legal values for file.atn.user.password.style are:

HASHED
REVERSIBLEENCRYPTED

Examples of Using secgen

The following example shows how to use the secgen utility to generate a key file with the name myKeyFile.dat:

  prompt> secgen -k -o myKeyFile.dat

The following example shows how to use the secgen utility to generate a file-based security provider configuration file named myConfigFile.xml which also uses the previously generated key file, myKeyFile.dat, and a properties file named mySecGen.properties:

  prompt> secgen -F -i myKeyFile.dat -o myConfigFile.xml -P  c:\msa\myMSAConfig\mySecGen.properties

Limitations of secgen

Windows operating systems must use the .cmd version of this utility, Unix platforms should use the .sh version.

  prompt> $PATH_TO_KSH_BIN/ksh -c secgen.sh

where PATH_TO_KSH_BIN is the fully qualified path to the ksh program.