Skip Headers
Oracle® Fusion Applications Developer's Guide for Oracle Enterprise Scheduler
11g Release 1 (11.1.1.5)
Part Number E10142-01
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Feedback page
Contact Us
Go to previous page
Previous		 Go to next page
Next
View PDF

16 Oracle Enterprise Scheduler Security

Oracle Enterprise Scheduler Security features provide access control for Oracle Enterprise Scheduler resources and application identity propagation for job execution.

16.1 Introduction to Oracle Enterprise Scheduler Security

Oracle Enterprise Scheduler Security includes the following:

16.1.1 Oracle Enterprise Scheduler Metadata Access Control

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 16-1 shows the metadata security summary.

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

Design time metadata security for ESS

16.1.2 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 Section 16.5, "Elevating Privileges for Oracle Enterprise Scheduler Jobs."

16.2 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 needs to call getJobDefinition to access a Metadata object named caclulateFees, Oracle Enterprise Scheduler ensures that teller1 has READ permission for the Metadata object caclulateFees 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:

Oracle JDeveloper ADF Security wizard creates the roles you use; the roles must be created before you can register roles with a metadata object.

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

  1. In Oracle JDeveloper, with an application open, from the Application menu select Secure.

  2. From the dropdown list, select Configure ADF Security. The Configure ADF Security wizard displays.

  3. In the Enable ADF Security page, select either ADF Authentication and Authorization or ADF Authentication and click Next.

  4. In the Select authentication type page, select either HTTP Basic Authentication or Form-Based Authentication and click Next.

  5. In the Enable automatic policy grants page, select the appropriate options from the Enable Automatic Grant area, and click Next.

  6. In the Specify authenticated welcome page, select options as needed and click Next.

  7. In the Summary page verify the options and click Finish.

  8. 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 3.6.3, "How to Assemble the EAR File for Scheduler Sample Application."

Ensure the security related files are included with EAR file:

  1. In Oracle JDeveloper, select Application > Application Properties.

  2. In the Application Properties page, in the Navigator select Deployment.

  3. In the Deployment Profiles area, select the EAR file Deployment descriptor. For example, for the sample application this is shown in Section 3.6.3, "How to Assemble the EAR File for Scheduler Sample Application".

  4. Click Edit. This displays the Edit EAR Deployment Profile Properties page.

  5. In the Edit EAR Deployment Profile Properties page, expand File Groups > Application Descriptors > Filters.

  6. In the Filters area, select the Files tab.

  7. Ensure that the files jazn-data.xml, jps-config.xml, and weblogic-application.xml are selected under the META-INF folder.

  8. Click OK to save the descriptor.

16.2.2 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 define principals security:

  1. In Oracle JDeveloper, open the application and expand Application Resources in the Application Navigator.

  2. In the Application Resources area, expand Descriptors and META-INF.

  3. In META-INF, double-click to open jazn-data.xml.

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

  5. Click Application Roles...(Manage Users and Roles).

  6. On the Edit JPS Identity and Policy Store page, in the navigator expand Identity Store and jazn.com.

  7. In the navigator, select Roles and click Add.... This displays the Add Role dialog.

  8. In the Add Role dialog, enter a name in the Name field.

  9. Click OK.

  10. 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:

    1. Select Application Policy Store.

    2. Click New... . This displays the Create Application Policy dialog.

    3. In the Create Application Dialog the Display Name field should contain the application name.

    4. Click OK to accept the default Display Name.

  11. On the Edit JPS Identity and Policy Store page, in the navigator expand Application Policy Store and expand the application name.

  12. In the navigator, select Application Roles. This displays the Application Roles page.

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

  14. Click OK.

16.2.3 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 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 3.5, "Creating Metadata for Scheduler Sample Application."

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

To secure Oracle Enterprise Scheduler metadata objects:

  1. Open the Editor page for any Oracle Enterprise Scheduler Metadata object.

  2. In the Access Control area, click Add to add a new access control item.

  3. In the Add Access Control dialog, select a Role from the dropdown list. This selects a role to grant access privileges.

  4. Select one or more actions from the list, Read, Execute, Update, or Delete.

  5. Click OK. This displays the updated role, as shown in Figure 16-2.

  6. Repeat for as many roles as needed.

Figure 16-2 Security Roles for Oracle Enterprise Scheduler Metadata

Security roles for Oracle Enterprise Scheduler metadata

16.2.4 How to Create Grants with Oracle ADF Security Wizard

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.

To specify grants with the ADF Security wizard:

  1. In the Application Navigator, expand the Application Resources panel.

  2. Expand Descriptors and META-INF, as shown in Figure 16-3.

    Figure 16-3 Security Configuration Files Including jazn-data.xml in META-INF

    Security configuration files

  3. Double-click 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.

  4. In the JPS Identity & Policy Store dialog, in the navigator expand Application Policy Store.

  5. Expand application-name, and select Application Roles.

  6. Click New.

  7. Enter the display name you wish for this grant, and click OK.

  8. Select the Principals tab, and click Add... .

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

  10. Click OK.

  11. With the new role selected in the Principals tab, make sure the Type is role.

  12. Select the Permissions tab, and click Add....

  13. For the Name field, enter a full permission string or a partial string with wildcards; see Table 16-1 for examples. In the Class field, enter oracle.as.scheduler.security.MetadataPermission. Click OK.

  14. With the new permission selected in the Permissions tab, enter the desired actions in the Actions Field.

  15. Click OK to save the grant.

    Note:

    If necessary, use the following workaround:

    1. Right-click the jazn-data.xml file and select Open.

    2. Click the Source tab.

    3. Under <jazn-policy><grant><grantee>, remove the elements <display-name> and <type>.

Table 16-1 Sample Permission Grants for Security Using Oracle ADF

Name Actions Effect

package-part.JobDefinition.MyJavaSucJobDef

EXECUTE

Grants the ability to submit requests for a single Metadata item.

mypackage.subpackage.*

CREATE,EXECUTE

Grants to ability to create and execute any new Metadata items in /mypackage/subpackage

JobDefinition.SYS_AdHocRequest

CREATE,EXECUTE

Grants ad hoc submission permission

mypackage.*

CREATE,EXECUTE,DELETE

Grants wide-open permissions

16.2.5 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 16-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 getJobDefinition(), getJobType(), getJobSet().

Table 16-2 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.

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

16.3 Configuring Web Service Security for Oracle Enterprise Scheduler

For information about securing the Oracle Enterprise Scheduler web service, see Section 10.9, "Securing the Oracle Enterprise Scheduler Web Service."

16.4 Configuring PL/SQL Job Security for Oracle Enterprise Scheduler

For standalone cases, implement the application user session using Java or the PL/SQL API as described in the chapter "Implementing Application User Sessions" in Oracle Fusion Applications Developer's Guide.

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

For more information about enabling elevating privileges, see Section 9.13, "Elevating Access Privileges for a Scheduled Job."

16.6 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 run time 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.

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

  1. Open the ejb-jar.xml file.

  2. Under the message-driven element, add an activation-config-properties element with the value applicationStripe.

  3. 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 16-1 shows an applicationStripe configuration for the policy context ESS_FUNCTIONAL_TEST_APP_STRIPE.

    Example 16-1 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>

  4. If your application has a web module, configure the web module JpsFilter to use the same applicationStripe in the file web.xml. Example 16-2 shows a code sample.

    Example 16-2 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>

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

16.6.3 What Happens at Runtime

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

16.7 Configuring Oracle Fusion Data Security for Job Requests

Oracle Fusion Data Security for Oracle Fusion Applications enforces security authorizations for access and modification of specific data records. Oracle Fusion Data Security integrates with Oracle Platform Security Services (OPSS) by granting actions to OPSS principals. The grant defines who (the principals) can do what (the actions) on a given resource. A grant in Oracle Fusion Data Security can use any enterprise user or enterprise group as principals. For more information about implementing Oracle Fusion Data Security, see the chapter "Implementing Oracle Fusion Data Security" in Oracle Fusion Applications Developer's Guide.

In the context of Oracle Enterprise Scheduler, a job request access control data security policy comprises a grant, a grantee and a set of ESS_REQUEST privileges for a set of job requests as follows:

The job request access control data security policy can be managed using Oracle Authorization Policy Manager as are other Oracle Fusion Data Security policies. If Oracle Authorization Policy Manager is not available, you can use SQL scripts to manipulate the Oracle Fusion Data Security artifacts.

16.7.1 Oracle Fusion Data Security Artifacts

To use Oracle Enterprise Scheduler job request access control feature in the context of Oracle Fusion Applications, the Oracle Fusion Applications schema and Oracle Enterprise Scheduler schema must be located in a single database.

Oracle Enterprise Scheduler implements job request data security on top of the request_history and request_property tables. It exposes Oracle Enterprise Scheduler job request related data to the Oracle Fusion Applications schema through the following views: request_history_view and request_property_view. Two synonyms are created in the Oracle Fusion Applications schema which are linked to the Oracle Enterprise Scheduler schema.

The request_history_view contains all columns that correspond to RuntimeService.QueryField, which is used when constructing the filter for queryRequest() operations, as well as two other columns: submitter and submitterguid. Be sure to define your INSTANCE_SET based on these columns only.

Table 16-3 lists the Oracle Fusion Applications schema tables and their Oracle Enterprise Scheduler synonyms, as well as the columns used to define data security policies.

Table 16-3 Mapping Oracle Fusion Applications Schema Synonyms to Oracle Enterprise Scheduler Schema Views and Relevant Columns

Oracle Fusion Applications Schema Synonym Link to Oracle Enterprise Scheduler Schema View Columns

ess_request_history

request_history_view

See table for the QueryField and View Column mapping.

ess_request_property

request_property_view

create or replace view request_property_view

as

select

requestid,

name,

scope,

datatype,

value,

lobvalue,

lobflag

from request_property

with read only;

Table 16-4 shows the mapping of RuntimeService.QueryField columns to the Oracle Enterprise Scheduler request_history_view columns.

Table 16-4 Mapping RuntimeService.QueryField Columns to request_history_view Columns

RuntimeService.QueryField Columns Request_history_view Columns

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

classname

QueryField.ELAPSEDTIME

elapsedtime

QueryField.WAITTIME

waittime

QueryField.SUBMITTER

submitter

QueryField.SUBMITTERGUID

submitterguid

Table 16-5 maps FND_MENUS to FND_FORM_FUNCTIONS as reflected in FND_MENU_ENTRIES.

Table 16-5 Mapping FND_MENUS to FND_FORM_FUNCTIONS

FND_MENUS in the Oracle Fusion Applications Schema FND_FORM_FUNCTIONS

ESS_REQUEST_ADMIN

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_VIEW

ESS_REQUEST_READ

ESS_REQUEST_OPERATE

ESS_REQUEST_READ

ESS_REQUEST_HOLD

ESS_REQUEST_CANCEL

ESS_REQUEST_LOCK

ESS_REQUEST_RELEASE

ESS_REQUEST_OUTPUT_ADMIN

ESS_REQUEST_OUTPUT_VIEW

ESS_REQUEST_OUTPUT_DELETE

Table 16-6 lists the required data privilege (form_function) for a user to perform an Oracle Enterprise Scheduler runtimeService operation.

Table 16-6 Data Privileges Needed to Execute runtimeService Operations

RuntimeService API Operation Data Privilege (FND_FORM_FUNCTIONS) Notes

open

none

  

close

none

Two overloaded methods.

submitRequest

none

Five overloaded methods, which are secured by metadata security, not data security.

getRequestParameter

ESS_REQUEST_READ

  

getRequestState

ESS_REQUEST_READ

  

getRequests

ESS_REQUEST_READ

  

getRequestDetail

ESS_REQUEST_READ

  

getRequestDetailBasic

ESS_REQUEST_READ

  

lockRequest

ESS_REQUEST_LOCK

  

updateRequestParameter

ESS_REQUEST_UPDATE

  

queryRequests

ESS_REQUEST_READ

  

holdRequest

ESS_REQUEST_HOLD

  

releaseRequest

ESS_REQUEST_RELEASE

  

cancelRequest

ESS_REQUEST_CANCEL

  

deleteRequest

ESS_REQUEST_DELETE

  

purgeRequest

ESS_REQUEST_PURGE

  

publishEvent

none

Not targeted to a request.

isHandleRollbackOnly

none

Not targeted to a request.

setHandleRollbackOnly

none

Not targeted to a request.

replaceSchedule

none

  

Table 16-7 displays the INSTANCE_SET conditions provided by Oracle Authorization Policy Manager.

Table 16-7 INSTANCE_SET Conditions Provided by Oracle Authorization Policy Manager

INSTANCE_SET Condition Description

REQS_SUBMITTEDBY_SESSIONUSER

Oracle Enterprise Scheduler requests that the submitter is the current session user.

REQS_RUNAS_SESSIONUSER

Oracle Enterprise Scheduler requests that the RunAs user is the current session user.

REQS_SUBREQS_BY_SUBMITTER

Oracle Enterprise Scheduler requests and subrequests are all submitted by the submitter.

REQS_ALL_OF_ONE_APP

Indicates all Oracle Enterprise Scheduler requests related to a product within a logical application. This condition takes two parameters that match the job request parameter values of SYS_application and SYS_product.

ESS_REQS_BY_NAME_VALUE_PARAM

Oracle Enterprise Scheduler job request whose RequestParameter name value pair is specified in data security grants. This condition takes two parameters that match the one job request parameter's name and value.

Table 16-8 lists the Oracle Fusion Data Security policies available for use with Oracle Enterprise Scheduler out of the box.

Table 16-8 Oracle Fusion Data Security Policies for Oracle Enterprise Scheduler

Oracle Fusion Data Security Policy Description

ESS_REQUEST_SUBMITTER_ADMIN_SUBMITTED_REQUESTS

The submitter of the job request is permitted to view and administer the requests they submitted.

ESS_REQUEST_SUBMITTER_ADMIN_SUBMITTED_REQUESTS_SUBREQS

The submitter of the job requests and subrequests is permitted to view and administer on the requests they submitted.

ESS_REQUEST_RUNASUSER_ADMIN_EXECUTED_REQUESTS

The runAs user is permitted to view and administer the requests they execute.

ESS_REQUEST_RUNASUSER_VIEWOUTPUT_EXECUTED_REQUESTS

The runAs user is permitted to view the output of the job requests they executed.

For more information about the runAs user, or elevating access privileges, see Section 9.13, "Elevating Access Privileges for a Scheduled Job."

16.7.2 How to Apply Oracle Fusion Data Security Policies

The Oracle Fusion Data Security components described in Section 16.7.1, "Oracle Fusion Data Security Artifacts" can be applied as follows.

To apply Oracle Fusion Data Security policies:

  1. Examine the policies described in Table 16-8 and determine whether you can use any of them in your application.

    • If you can use one of these policies, skip to the last step.

    • If the policies do not apply, continue on to the next step.

  2. Determine whether any of the FND_MENUS listed in Table 16-5 suit the out-of-the-box Oracle Fusion Data security policy you selected for your application. If you cannot apply any of the FND_MENUS listed in Table 16-5, create your own FND_MENUS and FND_MENUS_ENTRIES as described in the chapter "Implementing Oracle Fusion Data Security" in the Oracle Fusion Applications Developer's Guide.

  3. Determine whether you can use the INSTANCE_SET conditions in Table 16-7 and the Oracle Fusion Data Security policies in your application. If you cannot use the conditions, create your own FND_INSTANCE_SET. For more information about creating an FND_INSTANCE_SET, see the chapter "Implementing Oracle Fusion Data Security" in the Oracle Fusion Applications Developer's Guide.

  4. Create an Oracle Fusion Data Security policy, as described in Section 16.7.3, "How to Create Functional and Data Security Policies for Oracle Enterprise Scheduler Components."

    Note:

    If developing an Oracle Fusion application, do not grant an Oracle Enterprise Scheduler access policy to the grantee of an authenticated-role or anonymous-role, as doing so may affect the behavior of Oracle Enterprise Scheduler or other products.

  5. Test your application.

16.7.3 How to Create Functional and Data Security Policies for Oracle Enterprise Scheduler Components

You can use Oracle Authorization Policy Manager to create functional and data security policies for Oracle Enterprise Scheduler.

For more information about creating policies in Oracle Authorization Policy Manager, see the chapter "Managing Security Artifacts" in Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).

To create functional and data security policies for Oracle Enterprise Scheduler:

  1. Create a resource.

    1. From the list of policies, expand the fcsm policy stripe and select fcsm > Resource Catalog > Resources.

    2. From the Actions menu, click New.

    3. Define a resource with the resource type ESSMetadataResourceType, as well as the name and display name of the Oracle Enterprise Scheduler component using the following syntax: oracle.apps.ess.applicationName.JobDefintitionName.JobName.

    4. Save the resource.

  2. Define a resource policy.

    1. Select the resource you just created and click Create Policy.

    2. Add principals (grantees) by clicking the Add button.

    3. In the Add Principal window, search for the relevant application role or roles. Select the roles and click Add.

    4. In the Actions field, select the relevant actions and click Apply.

  3. Create an authorization condition.

    1. In the Authorization Management tab, select Global and search for the database resource you want to use. TABLE XY lists the database resources related to Oracle Enterprise Scheduler.

    2. Select the resource and click Edit.

    3. Click the Conditions tab and select Actions > New.

    4. Enter a name, display name and SQL predicate for the condition.

  4. Define a data policy.

    1. From the Actions menu, select New Policy.

    2. In the New Policy window, use the Role and Database Resource fields to add the relevant roles and resources.

    3. Select the role you defined. In Database Resource Details region, select the condition name you just created and choose the actions you require.

Go to previous page
Previous		 Go to next page
Next
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Feedback page
Contact Us