Oracle Enterprise Scheduler Security

Introduction to Oracle Enterprise Scheduler Security

Oracle Enterprise Scheduler Security includes protected operations on MetadataService and support for the use of an application identity.

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 a privileged user may create, delete, and update job and schedule metadata. For more information see 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 Oracle Enterprise Scheduler Job Execution Security.

Oracle Enterprise Scheduler Metadata Access Control

At design time the metadata creator must 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 23-1 shows the metadata security summary.

Figure 23-1 Design Time Metadata Security for Oracle Enterprise Scheduler

Description of "Figure 23-1 Design Time Metadata Security for Oracle Enterprise Scheduler"

Oracle Enterprise Scheduler Job Execution Security

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 Elevating Privileges for Oracle Enterprise Scheduler Jobs.

Configuring Metadata Security for Oracle Enterprise Scheduler

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 must 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 must 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 them with a metadata object.

How to Enable Application Security with Oracle ADF Security Wizard

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.

To enable security using the ADF Security wizard:

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.
If you selected ADF Authentication and Authorization > Form-Based Authentication 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.

Including Security Files in EAR File

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.

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.
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 jazn-data.xml, jps-config.xml, and weblogic-application.xml are selected under the META-INF folder.
Click OK to save the descriptor.

How to Define Principals for Security

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.

To create the application role:

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 jazn-data.xml.
In the page showing jazn-data.xml, select the Applications Role tab. Note, if the Application Role tab is not shown, try closing jazn-data.xml and then opening it again.
Click the Add button in the Roles list and choose Add New Role.
Set the name to EssApplicationRole in the Name field.

Figure 23-2 Creating the Application Role

Description of "Figure 23-2 Creating the Application Role"

Creating Enterprise Role

To create the enterprise role:

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 jazn-data.xml.
In the page showing jazn-data.xml, select the Test Users & Roles tab. Note, if the Test Users & Roles tab is not shown, try closing jazn-data.xml and then opening it again.
Select the Enterprise Roles tab.
Click the Add button in the Roles list and choose Add New Role.
Set the name to EssEnterpriseRole in the Name field.

Figure 23-3 Creating the Enterprise Role

Description of "Figure 23-3 Creating the Enterprise Role"

How to Create Grants with Oracle Enterprise Scheduler Metadata Pages

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

Using Oracle JDeveloper, you can add security grants to Oracle Enterprise Scheduler metadata objects.

To secure 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 23-4.
Repeat for as many roles as needed.

Figure 23-4 Security Roles for Oracle Enterprise Scheduler Metadata

Description of "Figure 23-4 Security Roles for Oracle Enterprise Scheduler Metadata"

About MetadataPermission APIs

Grants for metadata are part of the class oracle.as.scheduler. 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 MetdataObjectId#toPermissionString().

Table 23-1 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 getJobDefinition(), getJobType(), getJobSet().

Table 23-1 Grant Actions for Metadata Security

Action	Implies	Metadata Functions
`READ`	`None`	get<Type>(), query<Type>()
`EXECUTE`	`READ`	submitRequest()
`CREATE`	`READ`	add<Type>()
`UPDATE`	`READ`	update<Type>()
`DELETE`	`READ`	delete<Type>()

If you are submitting ad-hoc requests, you can have full wildcard ("*") permission with both EXECUTE and 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 EXECUTE and CREATE actions.

What Happens When You Configure Metadata Security

Each time a user application calls a MetdataService or 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 updateJobDefinition(), require UPDATE permissions.

For all 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.

The 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 SystemProperty.USER_NAME is overwritten at submission time; the user cannot spoof an identity at submission time using SystemProperty.USER_NAME.

Configuring Data Security for Oracle Enterprise Scheduler

The Oracle Enterprise Scheduler standalone data security implementation is based on functional security permission checking using the RuntimeDataPermission class.

By default, Oracle Enterprise Scheduler supports the following levels of data security enforcement:

A user can only operate on the requests that he or she submits.
A user can be granted permission to see all requests regardless of who submits them by assigning the user to the Admin, Operator, or Monitor roles.
A user can view the output generated by the requests that he or she submits or executes.

If you want to add or change the default data security permissions, you must reconfigure the jazn-data.xml file as shown in How to Change Data Security Permissions.

How to Change Data Security Permissions

This section describes how configure the jazn-data.xml file to change the a job request's data security from the "out-of-the-box" default settings described in Configuring Data Security for Oracle Enterprise Scheduler.

The following is an example of ajazn-data.xml permission section that defines RuntmeDataPermission.

<permission>
  <name>definition like 'oracle.apps.ess.custom.soa.*',product like         "SOA%",PROPERTY1=VALUE1</name>
  <class>oracle.as.scheduler.security.RuntimeDataPermission</class>
  <actions>ESS_REQUEST_READ,ESS_REQUEST_OUTPUT_READ</actions>
</permission

The permission conditions defined in the example above grant permission to a user to read the details of a job request and to read job request output if the job request matches the following criteria:

Its job definition matches the pattern: oracle.apps.ess.custom.soa.* and
If the value of the product field has "SOA"' and
A user-defined property named PROPERTY1 is set with the value of VALUE1

Conditions

Conditions are specified in the <name> element and use the “=" and “like/LIKE" operators. The “%" and “*" wildcard characters can be used with the “like/LIKE" operators. Note that you cannot use the “%" wildcard character in a field name that specifies a metadata object name, however, you can use it if the field name specifies other data such as products, and request categories. For example, the following examples work correctly:

definition LIKE 'oracle.apps.ess.custom.soa.*'
requestCategory LIKE 'EssFineGrained%',workAssignment LIKE 'FineGrainedWA%',className LIKE '%BasicJavaJob%'

While the following entry does not work correctly:

definition LIKE 'oracle.apps.ess.custom.soa.%'

Conditions are specified as sets of key-value pairs with the following specific delimiter syntax.

Key-value pairs in conditions are separated by the “," character.
Whitespace characters cannot be specified directly before or after the “," delimiter.
The value portion of a key-value condition can be unquoted, single-quoted, or double-quoted.
Multiple conditions specified in the same element are interpreted as logically ANDed together.
You can logically OR conditions by defining two or more permission resources for a same grantee.

The following rules apply to field names and reqProp keys:

The field name must be the value represented by fieldName of RuntimeService.QueryField. For example, QueryField.DEFINITION.fieldName().
You cannot specify ResultIndex as the field name because there is no equivalent field in Request History View for ResultIndex. The Request History View is the Database View created out of the Request_history table. The SQL query of the standalone data security gets executed against this view.
reqProp is a user property defined in Oracle Enterprise Scheduler job metadata or during request submissions. For example, PARTITION_NAME='SOA'.

Table 23-2 shows the list of valid field names and their corresponding request history view column entries:

Table 23-2 Condition Query Fields and Their Corresponding Request History View Column Entries

Query Field	Request History View Column
`QueryField.REQUESTID`	`requestid`
`QueryField.APPLICATION`	`application`
`QueryField.USERNAME`	`userName`
`QueryField.PRODUCT`	`product`
`QueryField.REQUEST_CATEGORY`	`requestCategory`
`QueryField.PRIORITY`	`priority`
`QueryField.NAME`	`name`
`QueryField.ABSPARENTID`	`absParentId`
`QueryField.TYPE`	`type`
`QueryField.DEFINITION`	`definition`
`QueryField.STATE`	`state`
`QueryField.SCHEDULE`	`schedule`
`QueryField.PROCESSSTART`	`processStart`
`QueryField.PROCESSEND`	`processEnd`
`QueryField.REQUESTEDSTART`	`requestedStart`
`QueryField.REQUESTEDEND`	`requestedEnd`
`QueryField.SUBMISSION`	`submission`
`QueryField.PARENTREQUESTID`	`parentRequestId`
`QueryField.WORKASSIGNMENT`	`workAssignment`
`QueryField.SCHEDULE`	`scheduled`
`QueryField.REQUESTTRIGGER`	`requesttrigger`
`QueryField.PROCESSOR`	`processor`
`QueryField.CLASSNAME`	`processor`
`QueryField.ELAPSEDTIME`	`elapsedtime`
`QueryField.WAITTIME`	`waittime`
`QueryField.SUBMITTER`	`submitter`
`QueryField.SUBMITTERGUID`	`submitterguid`

Condition Examples

The following examples show validly specified conditions:

• fieldName=value
• fieldName like 'value%'
• fieldName like "value*"
• reqProp="value"
• reqProp LIKE "value*"
• PermissionName : <name>fieldName1=value1,fieldName2 like 'value2%',reqProp="value",reqProp like 'value*'</name>

Actions

Available actions include a combination of the following:

ESS_REQUEST_READ
ESS_REQUEST_UPDATE
ESS_REQUEST_HOLD
ESS_REQUEST_CANCEL
ESS_REQUEST_LOCK
ESS_REQUEST_RELEASE
ESS_REQUEST_DELETE
ESS_REQUEST_PURGE
ESS_REQUEST_OUTPUT_READ
ESS_REQUEST_OUTPUT_DELETE

Examples

Example 23-1 shows how permissions can be specified directly in the <permission> element.

Example 23-2 shows how permissions can be specified using permission sets.

Note:

The content defined in the <permission-sets> - <permission-set> - <member-resources> - <member-resource> - <resource-name> element must be the same as the content defined in the <resources> - <resource> - <name> element.

Example 23-1 PL/SQL Request Text Output

<app-roles>
  <app-role>
    <name>riyanu_soa_role</name>
    <class>oracle.security.jps.service.policystore.ApplicationRole</class>
    <members>
      <member>
        <name>riyanu_soa_group</name>
        <class>weblogic.security.principal.WLSGroupImpl</class>
      </member>
    </members>
  </app-role>
</app-roles>
<grant>
  <grantee>
    <description>Allow soa role to pass through</description>
    <principals>
      <principal>
        <class>oracle.security.jps.service.policystore.ApplicationRole</class>
        <name>riyanu_soa_role</name>
      </principal>
    </principals>
</grantee>
<permissions>
  <permission>
    <name>oracle.apps.ess.custom.soa.*</name>
    <class>oracle.as.scheduler.security.MetadataPermission</class>
    <actions>READ,EXECUTE,CREATE,DELETE,UPDATE</actions>
  </permission>
  <permission>
    <name>definition like oracle.apps.ess.custom.soa.*,           partitionName=SOA_PARTITION,product=SOA</name>
    <class>oracle.as.scheduler.security.RuntimeDataPermission</class>
    <actions>ESS_REQUEST_READ,ESS_REQUEST_UPDATE,              ESS_REQUEST_OUTPUT_READ</actions>
  </permission>
</permissions>
</grant>

Example 23-2 PLSQL Request Binary Output Example

<app-roles>
  <app-role>
    <name>riyanu_soa_role</name>
    <class>oracle.security.jps.service.policystore.ApplicationRole</class>
    <members>
      <member>
        <name>riyanu_soa_group</name>
        <class>weblogic.security.principal.WLSGroupImpl</class>
      </member>
    </members>
  </app-role>
</app-roles>
<resource-types>
  <resource-type>
    <name>ESSSOAMetadataResourceType</name>
    <display-name>ESSSOAMetadataResourceType</display-name>
    <description>ESS SOA Metadata Resource</description>
    <matcher-class>oracle.as.scheduler.security.MetadataPermission</matcher-class>
    <actions-delimiter>,</actions-delimiter>
    <actions>create,read,update,delete,execute</actions>
  </resource-type>
  <resource-type>
    <name>ESSSOARequestResourceType</name>
    <display-name>ESSSOARequestResourceType</display-name>
    <description>Resource type for simple ESS request accesscontrol</description>
    <matcher-class>oracle.as.scheduler.security.RuntimeDataPermission     </matcher-class>
    <actions-delimiter>,</actions-delimiter>
    <actions>ESS_REQUEST_READ,ESS_REQUEST_UPDATE,ESS_REQUEST_CANCEL,     ESS_REQUEST_DELETE,ESS_REQUEST_OUTPUT_READ</actions>
  </resource-type>
</resource-types>
  <resources>
    <resource>
       <name>oracle.apps.ess.custom.soa.*</name>
       <type-name-ref>ESSSOAMetadataResourceType</type-name-ref>
       <description>All SOA ESS metadata</description>
       <display-name>All SOA ESS metaddata</display-name>
    </resource>
    <resource>
       <name>definition like "oracle.apps.ess.custom.soa.*",        partitionName=SOA_PARTITION,product=SOA</name>
       <type-name-ref>ESSSOARequestResourceType</type-name-ref>
       <description>Any ESS Multi request</description>
       <display-name>Any ESS Multi request</display-name>
    </resource>
  </resources>
  <permission-sets>
    <permission-set>
      <name>READ_ALL_SOA_MULTI_METADATA_RIYANU</name>
      <display-name>Read privilege on all SOA ESS metadata
      </display-name>
      <description>Read privilege on all SOA ESS metadata</description>
      <member-resources>
        <member-resource>
          <type-name-ref>ESSSOAMetadataResourceType</type-name-ref>
          <resource-name>oracle.apps.ess.custom.soa.*</resource-name>
          <actions>create,read,execute</actions>
        </member-resource>
      </member-resources>
    </permission-set>
  <permission-set>
    <name>READ_ALL_ESS_SOA_REQUESTS_RIYANU</name>
    <display-name>All privileges on all ESS Requests</display-name>
    <description>Allow read, update, cancel, hold, delete all the ESS      requests</description>
    <member-resources>
      <member-resource>
        <type-name-ref>ESSSOARequestResourceType</type-name-ref>
        <resource-name>definition like        "oracle.apps.ess.custom.soa.*",         partitionName=SOA_PARTITION,product=SOA</resourcename>
        <actions>ESS_REQUEST_READ,ESS_REQUEST_OUTPUT_READ</actions>
      </member-resource>
    </member-resources>
  </permission-set>
</permission-sets>
<jazn-policy>
  <grant>
    <grantee>
      <principals>
        <principal>
          <class>oracle.security.jps.service.policystore.ApplicationRole</class>
          <name>riyanu_soa_role</name>
        </principal>
      </principals>
    </grantee>
    <permission-set-refs>
      <permission-set-ref>
        <name>READ_ALL_SOA_MULTI_METADATA_RIYANU</name>
      </permission-set-ref>
      <permission-set-ref>
        <name>READ_ALL_ESS_SOA_REQUESTS_RIYANU</name>
      </permission-set-ref>
    </permission-set-refs>
  </grant>
</jazn-policy>

Configuring Web Service Security for Oracle Enterprise Scheduler

For information about securing the Oracle Enterprise Scheduler web service, see Using the Oracle Enterprise Scheduler Web Service .

Configuring PL/SQL Job Security for Oracle Enterprise Scheduler

The PL/SQL job does not enforce data security checks when calling ess_runtime package APIs.

Elevating Privileges for Oracle Enterprise Scheduler Jobs

When a user accesses Oracle Enterprise Scheduler services using the RuntimeService or 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.

Configuring a Single Policy Stripe in Oracle Enterprise Scheduler

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.

How to Configure a Single Policy Stripe in Oracle Enterprise Scheduler

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.

To configure an Oracle Enterprise Scheduler hosting application to a specific applicationStripe:

Open the ejb-jar.xml file.
Under the message-driven element, add an activation-config-properties element with the value applicationStripe.
Under the jpsinterceptor-class element, configure the JpsInterceptor.

Make sure to match the value of applicationStripe under the <message-driven> element with the application.name value under the <interceptor> element.

Example 23-3 shows an applicationStripe configuration for the policy context ESS_FUNCTIONAL_TEST_APP_STRIPE.
If your application has a web module, configure the web module JpsFilter to use the same applicationStripe in the file web.xml. Example 23-4 shows a code sample.

Example 23-3 Configuring the applicationStripe and the JpsInterceptor

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

Example 23-4 Configuring the Web Module in web.xml

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

What Happens When You Configure a Single Policy Stripe

At design time, an application stripe manifests as:

An <application> element under the <policystore> element in the jazn-data.xml file.
A node under the node cn=<Weblogic.domain.name>,cn=JPSContext,cn=<root.node>, such as cn=ATGDemo,cn=base_domain,cn=JPSContext,cn=MY_Node.

What Happens at Runtime

At runtime, an application stripe manifests as an instance of the class oracle.security.jps.service.policystore.ApplicationPolicy.