Oracle Enterprise Scheduler security includes the following:
Protected operations on MetadataService
; protected by MetadataPermission
, which enforces access control on metadata objects. Only privileged users may create, delete, and update jobs and schedule metadata. For more information, see Oracle Enterprise Scheduler Metadata Access Control.
Access control for job requests, enforced by Oracle Fusion Data Security policies. For more information about using Oracle Fusion Data Security policies, see Configuring Oracle Fusion Data Security for Job Requests.
Support for the use of an application identity. Using an application identity enables elevated privileges to complete a job that requires higher privileges than those allotted to the user who submitted the job. For more information, see Job Execution Security.
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 66-1 shows the metadata security summary.
Figure 66-1 Design Time Metadata Security for Oracle Enterprise Scheduler
The summary of design metadata security for Oracle Enterprise Scheduler is as follows:
Define Oracle Enterprise Scheduler metadata objects.
Create grants to control access to all metadata.
Define principals to be used for security.
Create grants to assign permissions for the metadata objects.
Assign relevant roles to the metadata, and specify actions for each role.
Assemble the EAR file for the application, including any security-related files.
Deploy the EAR file to Oracle WebLogic Server, which verifies grants in the Oracle Metadata Store and permissions assigned to roles with the LDAP server.
When submitting a job request, the submitting user is the user under whose permissions the job request is submitted. At job request execution time, all code, including pre-processing, post-processing, Java jobs, and substitution, runs 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 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 whether the user has the required permissions to access resources such as metadata objects. For example, if a user named teller1 must 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, you must determine the job functions for which you want to enable access to particular metadata objects 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 ensure that the jazn-data.xml
is included in the application deployment, perform the following steps after assembling the EAR file for the application.
Ensure the security-related files are included with the EAR file:
You need to define roles before the roles are used in Oracle Enterprise Scheduler security. You can define two types of roles:
Enterprise roles: These are defined directly in Oracle WebLogic Server either using the Oracle WebLogic Server console, using the WLST scripts, or using the Oracle ADF Security Wizard in Oracle JDeveloper.
Application roles: These can be defined in the jazn-data.xml
file or using the Oracle ADF Security Wizard.
To define principals security:
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 Overview tab. 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....
The Add Role window displays.
In the Add Role window, enter a name in the Name field.
Click OK.
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.
The Create Application Policy window displays.
In the Create Application Dialog the Display Name field should contain the application name.
Click OK to accept the default Display Name.
On the Edit JPS Identity and Policy Store page, in the navigator expand Application Policy Store and expand the application name.
In the navigator, select Application Roles.
The Application Roles page displays.
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.
Click OK.
Access to all metadata is controlled by grants. To ensure access by the right identities, you need to give the correct grants.
First, create any required Oracle Enterprise Scheduler metadata in an application using File > New > Business Tier > Enterprise Scheduler Metadata. For more information about defining metadata, see About Creating a Job Definition.
Using Oracle JDeveloper, you can add security grants to Oracle Enterprise Scheduler metadata objects.
To secure Oracle Enterprise Scheduler metadata objects:
Figure 66-2 Security Roles for Oracle Enterprise Scheduler Metadata
There may be occasions when you want to create grants explicitly, for example when using wild cards. These steps show how to set up grants using the Oracle ADF Security wizard.
Note that these steps assume you have already created application roles.
To specify grants with the Oracle ADF Security wizard:
In the Application Navigator, expand the Application Resources panel.
Expand Descriptors and META-INF, as shown in Figure 66-3.
Figure 66-3 Security Configuration Files Including jazn-data.xml in META-INF
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.
In the JPS Identity & Policy Store dialog, in the navigator expand Application Policy Store.
Expand application-name, and select Application Roles.
Click New.
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.
Click OK.
With the new role selected in the Principals tab, make sure the Type is role
.
Select the Permissions tab, and click Add....
For the Name field, enter a full permission string or a partial string with wildcards; see Table 66-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.
Note:
If necessary, use the following workaround:
Right-click the jazn-data.xml
file and select Open.
Click the Source tab.
Under <jazn-policy><grant><grantee>
, remove the elements <display-name>
and <type>
.
Table 66-1 Sample Permission Grants for Security Using Oracle ADF
Name | Actions | Effect |
---|---|---|
|
|
Grants the ability to submit requests for a single metadata item. |
|
|
Grants to ability to create and execute any new metadata items in |
|
|
Grants ad hoc submission permission |
|
|
Grants wide-open permissions |
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 66-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 66-2 Grant Actions for Metadata Security
Action | Implies | Metadata Functions |
---|---|---|
|
|
get<Type>(), query<Type>() |
|
|
submitRequest() |
|
|
add<Type>() |
|
|
update<Type>() |
|
|
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.
Each time a user application calls a MetadataService
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
.
The following document provides additional information related to subjects discussed in this section:
For more information, see "Assembling Oracle Enterprise Scheduler Oracle Fusion Applications" in the Extensibility Guide for Developers.
For information about securing the Oracle Enterprise Scheduler web service, see the chapter "Securing the Oracle Enterprise Scheduler Web Service" in Developing Applications for Oracle Enterprise Scheduler.
For standalone cases, implement the application user session using Java or the PL/SQL API as described in Implementing Application User Sessions.
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 caculateFees
, Oracle Enterprise Scheduler ensures that teller1
has read permissions for metadata object caculateFees
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 About Elevating Access Privileges for a Scheduled Job.
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.
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:
Example 66-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>
Example 66-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>
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
.
Oracle Fusion Data Security for Oracle Fusion application 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 Implementing Oracle Fusion Data Security.
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:
A grantee, represented by grantee ID such as a user or application role, the ID should match the user GUID or application role GUID retrieved from Oracle Fusion Middleware.
A set of ESS_REQUEST
privileges represented by a menu ID mapped to a set of form functions.
A set of data represented by an INSTANCE_SET
ID. An INSTANCE_SET
is typically represented by a predicate which can be appended to a query to the job request data exposed to Oracle Fusion Applications (see Oracle Fusion Data Security Artifacts).
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.
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 66-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 66-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 |
---|---|---|
|
|
See table for the |
|
|
|
Table 66-4 shows the mapping of RuntimeService.QueryField
columns to the Oracle Enterprise Scheduler request_history_view
columns.
Table 66-4 Mapping RuntimeService.QueryField Columns to request_history_view Columns
RuntimeService.QueryField Columns | Request_history_view Columns |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table 66-5 maps FND_MENUS
to FND_FORM_FUNCTIONS
as reflected in FND_MENU_ENTRIES
.
Table 66-5 Mapping FND_MENUS to FND_FORM_FUNCTIONS
FND_MENUS in the Oracle Fusion Applications Schema | FND_FORM_FUNCTIONS |
---|---|
|
|
|
|
|
|
|
|
Table 66-6 lists the required data privilege (form_function
) for a user to perform an Oracle Enterprise Scheduler runtimeService
operation.
Table 66-6 Data Privileges Needed to Execute runtimeService Operations
RuntimeService API Operation | Data Privilege (FND_FORM_FUNCTIONS) | Notes |
---|---|---|
|
none |
|
|
none |
Two overloaded methods. |
|
none |
Five overloaded methods, which are secured by metadata security, not data security. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
none |
Not targeted to a request. |
|
none |
Not targeted to a request. |
|
none |
Not targeted to a request. |
|
none |
Table 66-7 displays the INSTANCE_SET
conditions provided by Oracle Authorization Policy Manager.
Table 66-7 INSTANCE_SET Conditions Provided by Oracle Authorization Policy Manager
INSTANCE_SET Condition | Description |
---|---|
|
Oracle Enterprise Scheduler requests that the submitter is the current session user. |
|
Oracle Enterprise Scheduler requests that the |
|
Oracle Enterprise Scheduler requests and subrequests are all submitted by the submitter. |
|
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 |
|
Oracle Enterprise Scheduler job request whose |
Table 66-8 lists the Oracle Fusion Data Security policies available for use with Oracle Enterprise Scheduler out of the box.
Table 66-8 Oracle Fusion Data Security Policies for Oracle Enterprise Scheduler
Oracle Fusion Data Security Policy | Description |
---|---|
|
The submitter of the job request is permitted to view and administer the requests they submitted. |
|
The submitter of the job requests and subrequests is permitted to view and administer on the requests they submitted. |
|
The |
|
The |
For more information about the runAs
user, or elevating access privileges, see About Elevating Access Privileges for a Scheduled Job.
The Oracle Fusion Data Security components described in Oracle Fusion Data Security Artifacts can be applied as follows.
To apply Oracle Fusion Data Security policies:
You can use Oracle Authorization Policy Manager to create functional and data security policies for Oracle Enterprise Scheduler.
To create functional and data security policies for Oracle Enterprise Scheduler:
Create a resource.
From the list of policies, expand the fcsm policy stripe and select fcsm > Resource Catalog > Resources.
From the Actions menu, click New.
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
.
Save the resource.
Define a resource policy.
Select the resource you just created and click Create Policy.
Add principals (grantees) by clicking the Add button.
In the Add Principal window, search for the relevant application role or roles. Select the roles and click Add.
In the Actions field, select the relevant actions and click Apply.
Create an authorization condition.
In the Authorization Management tab, select Global and search for the database resource you want to use. Table 66-8 lists the database resources related to Oracle Enterprise Scheduler.
Select the resource and click Edit.
Click the Conditions tab and select Actions > New.
Enter a name, display name and SQL predicate for the condition.
Define a data policy.
From the Actions menu, select New Policy.
In the New Policy window, use the Role and Database Resource fields to add the relevant roles and resources.
Select the role you defined. In Database Resource Details region, select the condition name you just created and choose the actions you require.
The following document provides additional information related to subjects discussed in this section:
For more information about creating policies in Oracle Authorization Policy Manager, see the section "Managing Authorization Policies" in the "Securing Oracle Fusion Applications" chapter of the Administrator's Guide.