This chapter includes the following sections:
Oracle Enterprise Scheduler Security includes the following:
Protected operations on
MetadataService; protected by
MetadataPermission, which enforces metadata access control. Access control on metadata objects. Only privileged user may create, delete, and update job and schedule metadata. For more information see Section 18.1.1, "Oracle Enterprise Scheduler Metadata Access Control."
Support for the use of an application identity. Using an application identity enables elevated privileges for completing a job that requires higher privileges than those allotted to the submitting user. For more information, see Section 18.1.2, "Oracle Enterprise Scheduler Job Execution Security."
At design time the Metadata creator needs to decide which job functions can access which Metadata objects. This is expressed by associating each Metadata object with one or more roles and specifying one or more actions for each role. Figure 18-1 shows the metadata security summary.
During job submission, the user under whose permissions the job request is submitted is called the submitting user. At request execution time all user Java code including pre-processing, post-processing, Java jobs, and substitution, is run as the submitting user, retaining all roles and credentials.
If the job metadata specifies
SYS_RUNAS_APPLICAITONID, however, the job runs under the elevated privileges of an application ID. For more information, see Section 18.5, "Elevating Privileges for Oracle Enterprise Scheduler Jobs."
When a user accesses Oracle Enterprise Scheduler services using the RuntimeService or
MetadataService, the identity of the user is acquired and Oracle Enterprise Scheduler checks if the user has the required permissions to access resources (for example Metadata objects). For example, if a user named teller1 needs to call
getJobDefinition to access a Metadata object named
calculateFees, Oracle Enterprise Scheduler ensures that teller1 has
READ permission for the Metadata object
calculateFees before returning the object.
At design time the Metadata creator needs to decide which job functions can access which Metadata objects. This is expressed by associating each Metadata object with one or more roles and specifying one or more actions for each role.
There are two options for Metadata role assignments:
Using Oracle JDeveloper Tools Oracle ADF Security Wizard
Using Oracle JDeveloper Oracle Enterprise Scheduler add-in Metadata pages
Oracle JDeveloper ADF Security wizard creates the roles you use; the roles must be created before you can register roles with a metadata object.
These steps describe a minimal, validated security setup for an application using Oracle Enterprise Scheduler.
Follow these steps to create a working
jps-config.xml and a partially-populated
jazn-data.xml. Use these steps to configure servlets to work with JPS.
In Oracle JDeveloper, with an application open, from the Application menu select Secure.
From the dropdown list, select Configure ADF Security. The Configure ADF Security wizard displays.
In the Enable ADF Security page, select either ADF Authentication and Authorization or ADF Authentication and click Next.
In the Select authentication type page, select either HTTP Basic Authentication or Form-Based Authentication and click Next.
In the Enable automatic policy grants page, select the appropriate options from the Enable Automatic Grant area, and click Next.
In the Specify authenticated welcome page, select options as needed and click Next.
In the Summary page verify the options and click Finish.
In the Security Infrastructure Created dialog, click OK.
Next, to enable security and to ensure that the
jazn-data.xml is included in the application deployment, perform the following steps after assembling the EAR file for the application. For more information, see Section 5.6.3, "How to Assemble the EAR File for Oracle Enterprise Scheduler Sample Application."
In Oracle JDeveloper, select Application > Application Properties.
In the Application Properties page, in the Navigator select Deployment.
In the Deployment Profiles area, select the EAR file Deployment descriptor. For example, for the sample application this is shown in Section 5.6.3, "How to Assemble the EAR File for Oracle Enterprise Scheduler Sample Application".
Click Edit. This displays the Edit EAR Deployment Profile Properties page.
In the Edit EAR Deployment Profile Properties page, expand File Groups > Application Descriptors > Filters.
In the Filters area, select the Files tab.
Ensure that the files
weblogic-application.xml are selected under the
Click OK to save the descriptor.
You need to define roles before the roles are used in Oracle Enterprise Scheduler security. There are two types of roles that may be defined:
Enterprise roles: These are defined directly in Oracle WebLogic Server either using the Oracle WebLogic Server console, using the WLST scripts, or using the ADF Security Wizard in Oracle JDeveloper.
Application roles: These can be defined in the
jazn-data.xml file or using the ADF Security Wizard.
In Oracle JDeveloper, open the application and expand Application Resources in the Application Navigator.
In the Application Resources area, expand Descriptors and META-INF.
In META-INF, double-click to open
In the page showing
jazn-data.xml, select the Overview tab. Note, if the Overview tab is not shown, try closing
jazn-data.xml and then opening it again.
Click Application Roles...(Manage Users and Roles).
On the Edit JPS Identity and Policy Store page, in the navigator expand Identity Store and jazn.com.
In the navigator, select Roles and click Add.... This displays the Add Role dialog.
In the Add Role dialog, enter a name in the Name field.
On the Edit JPS Identity and Policy Store page, in the navigator select Application Policy Store. If there is a sub-element with the same name as the application, go to the next step, Otherwise, do the following:
Select Application Policy Store.
Click New... . This displays the Create Application Policy dialog.
In the Create Application Dialog the Display Name field should contain the application name.
Click OK to accept the default Display Name.
In the navigator, select Application Roles. This displays the Application Roles page.
In the Application Roles page, click Add... to add roles. For correct functionality at least one enterprise role must be mapped to the application role by adding enterprise roles in the Member Roles tab.
Access to all Metadata is controlled by grants. In order to ensure access by the right identities, you need to give the correct grants. It is expected that most Metadata grants will be done using the Oracle Enterprise Scheduler Oracle JDeveloper add-in.
First, create any required Oracle Enterprise Scheduler Metadata in an application using File > New > Business Tier > Enterprise Scheduler Metadata. For more information on creating Metadata, see Section 5.5, "Creating Metadata for Oracle Enterprise Scheduler Sample Application."
Using Oracle JDeveloper, you can add security grants to Oracle Enterprise Scheduler metadata objects.
Open the Editor page for any Oracle Enterprise Scheduler Metadata object.
In the Access Control area, click Add to add a new access control item.
In the Add Access Control dialog, select a Role from the dropdown list. This selects a role to grant access privileges.
Select one or more actions from the list, Read, Execute, Update, or Delete.
Click OK. This displays the updated role, as shown in Figure 18-2.
Repeat for as many roles as needed.
There may be occasions where you want to create grants explicitly, for example when using wildcards. These steps show how to set up grants using the ADF Security wizard.
Note that these steps assume you have already created application roles.
In the Application Navigator, expand the Application Resources panel.
Expand Descriptors and META-INF, as shown in Figure 18-3.
jazn-data.xml to open the file. In the editor panel for
jazn-data.xml, select the Overview tab, and click Application Roles... (Manage Users and Roles). This displays the JPS Identity & Policy Store dialog. Note, if the Overview tab is not shown, try closing
jazn-data.xml and then opening it again.
In the JPS Identity & Policy Store dialog, in the navigator expand Application Policy Store.
Expand application-name, and select Application Roles.
Enter the display name you wish for this grant, and click OK.
Select the Principals tab, and click Add... .
Enter the name of the application role which will receive the grant; this should be one of the role names created. Leave the Class field as is.
With the new role selected in the Principals tab, make sure the Type is
Select the Permissions tab, and click Add....
For the Name field, enter a full permission string or a partial string with wildcards; see Table 18-1 for examples. In the Class field, enter
oracle.as.scheduler.security.MetadataPermission. Click OK.
With the new permission selected in the Permissions tab, enter the desired actions in the Actions Field.
Click OK to save the grant.
If necessary, use the following workaround:
jazn-data.xml file and select Open.
Click the Source tab.
<jazn-policy><grant><grantee>, remove the elements
Grants the ability to submit requests for a single Metadata item.
Grants to ability to create and execute any new Metadata items in /mypackage/subpackage
Grants ad hoc submission permission
Grants wide-open permissions
Grants for Metadata are part of the class
security.MetadataPermission. The name, or target of the permission is based on the package, Metadata object type, and name of the Metadata object being protected; this identifier can be retrieved from
Table 18-2 lists the actions for the grants. The notation <Type> is a placeholder for all of the metadata object types. For example, get<Type>() refers to the methods
If you are submitting ad-hoc requests, you can have full wildcard ("*") permission with both
CREATE actions. When submitting ad-hoc requests, that is, using
submitRequest() without certain
MetadataObjectIds, you can grant permissions with the full wildcard ("*") name using the
Each time a user application calls a
RuntimeService method, Oracle Enterprise Scheduler checks the current subject for privileges on the metadata accessed by the methods. For example, submitting a request requires
EXECUTE permissions on the job definition or job set metadata object associated with the submission. Methods that change metadata, for example calling
MetadataService methods except queries, an exception is thrown when the user tries to access a Metadata object for which the user does not have permission.
MetadataService query methods have different behavior. When a user performs a query Oracle Enterprise Scheduler only returns Metadata objects that have
READ permission. Thus a user who has no permissions on Metadata objects receives an empty list for all queries, but this user would not see an exception thrown due to lack of permissions.
The value of
USER_NAME is overwritten at submission time; the user cannot spoof an identity at submission time using
For information about securing the Oracle Enterprise Scheduler web service, see Section 11.9, "Securing the Oracle Enterprise Scheduler Web Service."
The PL/SQL job does not enforce data security checks when calling ess_runtime package apis.
When a user accesses Oracle Enterprise Scheduler services using the
MetadataService interfaces, the identity of the user calling the methods is acquired. This identity is used to check whether the user has the required permissions to access certain resources such as metadata objects. For example, if user
teller1 calls the method
getJobDefinition for metadata object
caclulateFees, Oracle Enterprise Scheduler ensures that
teller1 has read permissions for metadata object
caclulateFees before returning the object.
The caller identity is also used to run jobs requested by the user. For example, if user
teller1 calls the method
submitRequest() for a Java job, the requested jobs run under
teller1 and retain all roles and credentials assigned to that user.
Oracle Enterprise Scheduler supports the use of an application identity. Using an application identity enables elevated privileges for completion of a job that requires higher privileges than those allotted to the submitting user.
Oracle Platform Security policy store serves as the repository for authorization policies. Authorization policies load at runtime into the Java Virtual Machine, and are used to make decisions regarding authorization. Authorization policies comprise a hierarchy of application roles, the mapping of enterprise roles to application roles and permissions grants to application roles. Application roles can also be hierarchical.
Aside from authorization policies, Oracle Platform Security policy store also stores administrative constructs that help in maintaining these authorization policies, including resource catalogs (with associated resource types), permission sets and role categories. The authorization polices and administrative components are scoped to an application. This is known as an application stripe.
An application stripe is a collection of JAAS policies applicable to the application with which it is associated. Out of the box, an application stripe maps to an Oracle Java EE application. Oracle Platform Security also supports mapping multiple Java EE applications to one application stripe. The application ID string identifies the name of the application or applications.
Oracle Enterprise Scheduler allows specifying an
applicationStripe name and mapping it to a JPS policy context ID. You can assign multiple Oracle Enterprise Scheduler hosting applications to a single policy context.
message-driven element, add an
activation-config-properties element with the value
jpsinterceptor-class element, configure the
Make sure to match the value of
applicationStripe under the
<message-driven> element with the
application.name value under the
Example 18-1 shows an
applicationStripe configuration for the policy context
<ejb-jar> .... <enterprise-beans> <message-driven> <ejb-name>ESSAppEndpoint</ejb-name> <ejb-class>oracle.as.scheduler.ejb.EssAppEndpointBean</ejb-class> <activation-config> .... <activation-config-property> <activation-config-property-name>applicationStripe</activation-config-property-name> <activation-config-property-value>ESS_FUNCTIONAL_TESTS_APP_ STRIPE</activation-config-property-value> </activation-config-property> </activation-config> </message-driven> ..... </enterprise-beans> <interceptors> <interceptor> <interceptor-class>oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class> <env-entry> <env-entry-name>application.name</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>ESS_FUNCTIONAL_TESTS_APP_STRIPE</env-entry-value> <injection-target> <injection-target-class>oracle.security.jps.ee.ejb.JpsInterceptor </injection-target-class> <injection-target-name>application_name</injection-target-name> </injection-target> </env-entry> </interceptor> </interceptors> </ejb-jar>
If your application has a web module, configure the web module
JpsFilter to use the same
applicationStripe in the file
web.xml. Example 18-2 shows a code sample.
<web-app> <filter> <filter-name>JpsFilter</filter-name> <filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class> ... <init-param> <param-name>application.name</param-name> <param-value>ESS_FUNCTIONAL_TESTS_APP_STRIPE</param-value> </init-param> </filter> </web-app>
At design time, an application stripe manifests as:
<application> element under the
<policystore> element in the
A node under the node
cn=<Weblogic.domain.name>,cn=JPSContext,cn=<root.node>, such as