Oracle Event Processing provides a variety of ways to protect server resources such as data and event streams, configuration, user name and password data, security policy information, remote credentials, and network traffic.
This chapter contains the following sections:
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 server 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 roles:
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 non-administration user can access an application, an administration user must grant the user the associated application role.
Application Isolation enables administrators to create new roles that can associate new roles to a given application to allow only a selected group access to this application. After the new role is created, non-admin users without this role cannot see the application in visualizer and cannot list or change the application configuration through Admin tool.
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 9-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, he or she enters an administrator user that is 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 oepadmin
with password welcome1
.
Table 9-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 9-1 Default Oracle Event Processing Task Roles and Groups
Task Role | Group | Privileges |
---|---|---|
|
|
Has all privileges of all the other roles, and permission to:
All JMX All
|
|
wlevsApplicationAdmins |
Has all Operator privileges and permission to update the configuration of any deployed application. All |
|
wlevsBusinessUsers |
Has all Operator privileges and permission to update the Oracle CQL rules associated with the processor of a deployed application. All
|
|
wlevsDeployers |
Has all Operator privileges and permission to deploy, undeploy, update, suspend, and resume any deployed application. All JMX |
|
wlevsMonitors |
Has all Operator privileges and permission to enable/disable diagnostic functions, such as creating a diagnostic profile and recording events (then playing them back.) Can also inject and trace events. All JMX All
|
|
wlevsOperators |
Has read-only access to all server resources, services, and deployed applications. |
Once the domain is 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 Using Visualizer for Oracle Event Processing
For more information, see:
The Java SE platform defines a standards-based and interoperable security architecture that is dynamic and extensible. Security for features such as cryptography, authentication and authorization, public key encryption, and more are built in.
See http://java.sun.com/javase/technologies/security/
for more information.
Oracle Event Processing supports Java SE security with the following security policy files. Oracle provides templates for these files in the product in the following directory: /Oracle/Middleware/my_oep/
oep/utils/security
.
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.
You can define Java SE security policies for the following Oracle Event Processing features:
All 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
Configure Java SE Security on a Server:
Stop the Oracle Event Processing server, if it is currently running.
Copy policy.xml
and security.policy
:
From:/Oracle/Middleware/my_oep/oep/utils/security
/
To:
/Oracle/Middleware/my_oep/user_projects/domains
/ <domainname>/
<servername>
/config
/
Edit the two security policy files as needed.
Update the server startup script for your platform in the <servername
> directory by adding the following properties to the java
command that starts the server:
-Djava.security.manager -Djava.security.policy=./config/security.policy -Dcom.bea.core.security.policy=./config/policy.xml
For example with everything 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
Edit the Jetty configuration in the config.xml
server file 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.
Oracle Event Processing supports the several security providers for authentication, authorization, role mapping, and credential mapping.
The default is the file-based provider. If you use the default file-based security provider, then you do not need to do any further configuration of your domain. If you want to use the LDAP or DBMS providers, you must perform further configuration. Once you have configured the security provider, you can add new users, assign them to groups, and map groups to roles. See Users, Groups, and Roles.
File-based: Default security provider that uses an operating system file to access security data such as user, password, and group information. This provider provides authentication and authorization. Authentication is the process whereby the identity of users is proved or verified. Authorization is the 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 user name and password combinations.
LDAP: Uses a Lightweight Data Access Protocol (LDAP) server to access user, password, and group information. Provides only authentication.
When you use LDAP for authentication, you cannot add or delete users and groups using Oracle Event Processing Visualizer, you can only change the password of a user.
RDBMS: Uses a DBMS to access user, password, and group information. Provides both authentication and authorization.
The following procedures describe two different ways to configure a security provider for authentication and authorization.
Configure Authentication with LDAP and Authorization with the DBMS Provider
Configure Authentication and Authorization with the DBMS Provider
Configure Authentication with LDAP and Authorization with the DBMS Provider
Add the Oracle/Middleware/my_oep
/oep/bin
directory to your PATH
environment variable:
set PATH=d:\Oracle\Middleware\my_oep\oep\bin;%PATH% (Windows) PATH=/Oracle/Middleware/my_oep/oep/bin:$PATH (UNIX)
Go to the config
directory for the server you want to configure.
By default, the config
directory is in /Oracle/Middleware
/
my_oep/ user-Projects/domains/<domainname>/<servername>
/config
/.
In a text editor, create a file called myLDAPandDBMS.properties
and copy the entire contents of the following example into it.
Note:
Make sure the certificate of the boot user in the evsidentity.jks
file is the same as what is configured in the security.xml
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=sslv3 #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 user name 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
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.
Create a new security configuration file (security.xml
) by executing the following cssconfig
command:
cssconfig -p myLDAPandDBMS.properties -c security.xml -i security-key.dat
myLDAPandDBMS.properties
: The property file you created in step 3. security.xml
: The name of the new security configuration file.security-key.dat
: An existing file generated by the Configuration Wizard that contains the identity key.
See The cssconfig Command-Line Utility for additional information.
Go to /Oracle/Middleware/my_oep/
oep/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 atz_create.sql SQL script against the database you specified as the database store in step 3.
Configure your LDAP server by adding the default groups described in Users, Groups, and Roles and the administrator user you specified when you created the domain. By default, this user is called oepadmin
.
Refer to your LDAP server documentation for details.
Optionally, configure password strength in your new security.xml
file.
See Password Strength.
Configure Authentication and Authorization with the DBMS Provider
Add the Oracle/Middleware/my_oep
/oep/bin
directory to your PATH
environment variable:
prompt> set PATH=d:\Oracle\Middleware\my_oep\oep\bin;%PATH% (Windows) prompt> PATH=/Oracle/Middleware/my_oep/oep/bin:$PATH (UNIX)
Go to the config
directory for the server you want to configure.
By default the config
directory is in /Oracle/Middleware
/
my_oep/ user-Projects/domains/<domainname>/<servername>
/config
/.
Make a backup copy of the existing security.xml
file, in case you need to revert.
In a text editor, create a file called myDBMS.properties
and copy the entire contents of the following example into it.
# 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 user name 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
Leave all the other properties to their default values.
Create a new security configuration file (security.xml
) by executing the following cssconfig
command:
cssconfig -p myLDAPandDBMS.properties -c security.xml -i security-key.dat
myDBMS.properties
: The property file you created in step 3.security.xml
: The name of the new security configuration file. security-key.dat
: An existing file generated by the Configuration Wizard that contains the identity key.
See The cssconfig Command-Line Utility for additional information.
Go to /Oracle/Middleware/my_oep/
oep/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 oepadmin
, with password welcome1
, into the user table and specifies that the user belongs to the wlevsAdministrators group. The script also inserts the default groups listed in Table 9-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, edit the atn_init.sql
file and add the INSERT INTO USERS
and corresponding INSERT INTO GROUPMEMBERS
statements.
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 3:
atn_create.sql
atn_init.sql
atz_create.sql
Optionally, configure password strength in your new security.xml
file.
See Password Strength.
Password strength measures the effectiveness of a password as an authentication credential. How you configure password strength determines the type of password a user can specify, such as whether the password can contain the user name, 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 <password-validator> element in the security configuration file (security.xml
).
By default, the security configuration file is in the Oracle/Middleware/my_oep/user_projects/domains/<domainname>/<servername>/config
directory.
The following example shows a snippet from the security.xml
file with the default values after you create a new domain.
<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 9-2 describes all the child elements of <password-validator>
that 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 9-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 provides one-way Secure Sockets Layer (SSL) to secure network traffic in certain situations.
The SSL works between:
A browser running the Oracle Event Processing Visualizer and the Oracle Event Processing server 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 multiserver domain.
You can configure Oracle Event Processing to use a Federal Information Processing Standards (FIPS)-certified pseudo-random number generator for SSL. After you configure SSL, you can configure the Oracle Event Processing server to accept only client requests on the HTTPS port. See HTTPS-Only Connections.
You configure SSL in the server's config.xml
file. When you create an Oracle Event Processing server, the server config.xml
includes a default SSL configuration. The following procedures show how to configure SSL and a key store.
By default, the Configuration Wizard creates a default key store certificate file called evsidentity.jks
.
By default the evsidentity.jks
file is in the Oracle/Middleware/my_oep/user_projects/domains/<domainname>/<servername>/ssl
directory.
The password is the same as the password you entered when you created the server. Optionally, you can create a key store manually.
In a multiserver domain, you can configure one-way SSL between the server that hosts the Oracle Event Processing Visualizer data services application and another server. In the following procedure, the server that hosts the data services application is myServer1,
and the second server is myServer2
. Both servers are in the /Oracle/Middleware/my_oep/user_projects/domains/myServer1
directory. Repeat this procedure for other servers in the domain, if required.
For information about securing the messages sent between servers in a multiserver domain, see:
Oracle Coherence: Secure the Messages Sent Between Servers
Native Clustering: Secure the Messages Sent Between Servers in a Multiserver Domain
For information about starting Oracle Event Processing Visualizer in a multiserver domain, see Using Visualizer for Oracle Event Processing.
Configure SSL in a Multiserver Domain for Use by Visualizer
You can use SSL to secure communications between the service provider (SP) and identity provider (IDP) in an SSO environment by configuring an Oracle Event Processing Server as a SAML2 SP and configure the SP with the needed SAML2 identity IDP options.
The following examples shows an ssl
element with a sample configuration. The procedure edits the example to configure SSL between a SAML2 SP and an IP.
<ssl> <name>samlsslConfig</name> <key-store>security_files/DemoIdentity.jks</key-store> <key-store-pass> <password>DemoIdentityKeyStorePassPhrase</password> </key-store-pass> <key-store-type>JKS</key-store-type> <trust-store>security_files/DemoTrust.jks</trust-store> <ssl-protocol>TLS</ssl-protocol> <key-store-alias>demoidentity</key-store-alias> <key-manager-algorithm>SunX509</key-manager-algorithm> <enforce-fips>false</enforce-fips> <need-client-auth>false</need-client-auth> </ssl>
Configure SSL between a SAML2 SP and an IP
com.rsa.jsafe.provider.JsafeJCE
security provider. Use this provider to configure Oracle Event Processing to use a FIPS-certified pseudo-random number generator for SSL.For more information, see:
You can configure Oracle Event Processing servers to use a FIPS-certified pseudo-random number generator.
Configure FIPS for an Oracle Event Processing Server
SSO enables you to have a user to sign on to an application once and gain access to many different application components even when these components have their own authentication schemes. Single sign-on enables users to log in securely to all of their applications with one identity.
There are two roles in a SAML2 SSO environment as Figure 9-1 shows:
Identity Provider (IDP): The process that performs authentication. You configure SAML2 options for the IDP in the Oracle Event Processing server config.xml
file.
Service Provider (SP): The process that delegates authentication to an IDP. You configure SAML2 options for the SP in the Oracle Event Processing security.xml
file.
In the context of Oracle Event Processing, the Oracle Event Processing server is the service provider. The identity provider is any SAML2-compliant system such as Oracle WebLogic Server or Oracle Access Manager.
Be aware that Oracle Event Processing Visualizer supports SSO with SAML2, but the Oracle Event Processing HTTP Publish-Subscribe Server (HTTP pub-sub server) does not support SSO with SAML2.
For more information, see:
Understanding Security for Oracle WebLogic Server
Developing Applications with the WebLogic Security Service
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
.
The following procedures explain how to configure SSO with SAML2 on an Oracle Event Processing server:
In this configuration, the Oracle Event Processing server receives client requests and delegates their authentication to a SAML2 IDP. You configure SAML2 SP options in the security.xml
file with the cssconfig
command-line tool.
Configure SAML2 Service Provider Options
In this configuration, you configure an Oracle Event Processing server with SAML2 IDP options that the server then uses to delegate authentication to a SAML2-compliant IDP. You configure SAML2 IDP options in the Oracle Event Processing server config.xml
file.
This procedure uses Oracle WebLogic Server as an example IDP. Refer to your IDP documentation for configuration details specific to your IDP and use this procedure as a guide.
Configure SAML2 Identity Provider Options
Obtain the IDP metadata file from your IDP.
If Oracle WebLogic Server is your IDP, you can generate the IDP metadata file as follows:
Open a browser and log into the Oracle WebLogic Server console:
http://localhost:1010/console
Under your domain, select Environment > Servers > SERVER_NAME > Federation > Services > SAML 2.0 General
Where SERVER_NAME is the name of your Oracle WebLogic Server.
Click Publish Meta Data and specify a file name.
In this example, call it myidp.xml
.
Change to the config
directory for the server you want to update.
By default, the directory is Oracle/Middleware/my_oep/user_projects/domains/<domainname>/<servername>/config
.
Copy the myidp.xml
file to your Oracle Event Processing server config
directory.
Make a backup copy of the existing config.xml
file, in case you need to revert:
In a text editor, edit the config.xml
file and add a saml2-identity-provider
element as the following example shows.
You can configure only one IDP per Oracle Event Processing server.
<saml2-identity-provider> <meta-data-file-name>myidp.xml</meta-data-file-name> <partner-name>partnerIdP1</partner-name> <redirect-uris> <uri>/unleashed_saml/</uri> <uri>/unheardof_saml/</uri> </redirect-uris> </saml2-identity-provider>
meta-data-file-name
: partner-name
: The name of this IDP instance.redirect-uris
: SAML2 authentication URIs.
Restart the Oracle Event Processing server for the changes to take effect.
You can lock down the server to allow only HTTPS connections.
Configure HTTPS-Only Connections for a Server
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 as a Java web server to deploy HTTP servlets and static resources. See http://mvnrepository.com/artifact/org.mortbay.jetty
. For more information about Jetty, see Jetty.
The following security tasks affect Jetty configuration:
Clients that access the Oracle Event Processing server with JMX are subject to Oracle Event Processing role-based authentication. For more information about roles, see: Users, Groups, and Roles.
For more information about JMX, see JMX.
If you update a data source with a new password using the Configuration Wizard, then the Configuration Wizard performs password encryption for you. If you update the config.xml
file manually by adding or modifying a data-source
element, then you enter the password in plain text and encrypt the password with the encryption utility, encryptMSAConfig
.
The following example shows a config.xml
file data-source
element with a new plain text password, secret,
specified in the properties
element with the name password
.
<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>
The following example shows the config.xml
file data-source
element after encryption. Note the plain text password is encrypted.
<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 JDBC.
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:
Oracle Event Processing Visualizer provides an Adobe Flash-based user interface with which you can create and configure event processing networks.
To provide the most flexible default performance for Visualizer, the software is installed with a configured trust level that allows access to Visualizer data from any domain. If this trust level is inappropriate for your deployment, you can edit the application's Flash cross-domain policy file to restrict access.
Review the domains the Flash cross-domain policy allows and determine whether it is appropriate for the application to fully trust both the intentions and security posture of those domains. See the Adobe web site for a thorough description of editing cross-domain policy. See the Adobe security web site for information about using the Adobe cross-domain policy files.
Update Cross-Domain Security
Locate the Oracle Event Processing Visualizer JAR file.
By default the file is in Oracle/Middleware/my_oep/oep/modules/ com.bea.wlevs.visualizer.jmxhttpadapter_version.jar
.
Expand the JAR file and locate the crossdomain.war
file.
Expand the crossdomain.war
file to locate the crossdomain.xml
file.
Edit the crossdomain.xml
file to reflect your cross-domain security needs.
Repackage the crossdomain.war
file 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
Oracle/Middleware/my_oep/user_projects/domains/<domainname>/ <servername>/legacy-rootdir/servers/legacy-server-name/logs
By default, the Oracle Event Processing security auditor logs security errors or failures to keep the security auditor log file at a manageable size. You can configure the level at which the Oracle Event Processing security auditor logs information.
To configure security auditor logging:
You can disable security entirely on the Oracle Event Processing server. While this configuration might 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.
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 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 CQ processors and monitor the event latency and throughput of an application. See About the 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 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 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 The encryptMSAConfig Command-Line Utility for details.
For each utility, you can specify user credentials (user name 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.
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 user name oepadmin
and password welcome1
. 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 oepadmin
, with password welcome1
, 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 user name and password to the java
command. If you use the Deployer or wlevs.Admin
utility, you must also pass this user name/password pair using the appropriate arguments.
For more information, see User Credentials for Command-Line Utilities.