7 Customizing Security for Oracle ADF Application Artifacts

In general, when you create new functionality, not supported by Oracle Fusion Applications, do not include authorization to that functionality from within the security artifacts that Oracle Fusion Applications delivers in the security reference implementation.

Specifically, Oracle Fusion security guidelines suggest customization developers and security administrators must not modify the following security artifacts in the security reference implementation when introducing new functionality, through custom or extended business objects:

• Predefined duty roles, specifically:

  • Do not change the role hierarchy by removing member duty roles assigned to parent duty roles or job roles.

  • Do not remove (also called revoke) existing permissions granted to duty roles.

  • Do not add (also called grant) new permissions to duty roles.

• Predefined security policies (including data and function), specifically:

  • Do not remove existing instance sets from predefined data security policies.

  • Do not remove existing member resources from predefined function security policies.

  • Do not revoke existing actions (mapped by Oracle Fusion security to resource operations) granted on each resource or instance set.

Customization developers and security administrators may modify security artifacts in the security reference implementation in the following ways:

• Do modify job roles to add a custom duty role (permissible by security administrator only).

• Do modify data role templates to add a new job role as the base role or to add access permissions to a custom business object.

Customization developers and security administrators may create the following security artifacts and add them to the security reference implementation:

• Do create custom duty roles when a custom application resource requires a new duty role to support the segregation of duties or when a custom application resource introduces new permissions to a predefined business object.

• Do create data role templates when a custom business object is used as a data stripe and when explicit data security policies grant access to the data stripe. A data stripe is a dimensional subset of the data granted by a data security policy and associated with a data role. For example, create a data role template when you need to grant data roles access to a specific business unit or organization.

You do not need to customize security for every type of customization that you may make in the extended application. Whether or not a security policy is needed will depend on the application resource and the type of customization performed.

The following table summarizes the security customization scenarios that Oracle Fusion security supports. The "Application Developer Tasks" column of the table provides a brief description of the security artifacts involved in each scenario, but presumes some familiarity with the Oracle Fusion security approach (for guidance see What You Need to Know Before Proceeding with This Chapter).

In Oracle Fusion Applications, when you want to extend the application to expose additional data, you create an ADF entity object and implement the operations that may be performed over a particular set of data records. The ADF entity object you create encapsulates the data as business object instances, corresponding to data records from a database table or view, such as an invoice or a purchase order. Typical operations are business functions like viewing, editing, or creating an instance of the business object.

Security concerned with controlling the operations that can be performed against specific data is called data security. Data security policies involve granting an end user, by means of the end user's membership in a role, the ability to perform operations on specific sets of data. For example, an accounts payable manager in the enterprise's western regional office may be expected to view and edit invoice data records, but only for the customers in the western region. The Accounts Payable Manager role provisioned to the accounts payable manager authorizes access to the business functions required to view and edit invoice instances, and, in this case, the specific instances of the invoice business object that is striped for the western region.

Data security policies are implemented using Oracle Fusion Data Security, which is the technology that implements the security repository for data security policies. Oracle Fusion Data Security is implemented as a series of Oracle Fusion Applications database tables, sometimes referred to as FND tables (note that FND refers to resources in foundation tables) and includes tables like FND_OBJECTS that defines the database resource and FND_GRANTS that defines the access permissions for those database resources.

To secure the business object in the extended application, where it has been exposed as an ADF entity object, is a multi-step process: 1.) A database resource definition must be created in the FND_OBJECTS table to identify the same table or view backing the ADF entity object. The database resource in Oracle Fusion Data Security is the data resource on which data security is enforced. 2.) After the business object is defined as an Oracle Fusion Data Security database resource, then a security policy must be created to grant access to the data records. The security policies for the database resource specify access permissions such as read, update, and delete permissions on specific sets of data records exposed by the business object. 3.) Finally, to enforce the newly created data security policy, the entity object in the data model project must enforce authorization checking on the data operations that access the protected data records exposed by the business object.

As an Oracle Fusion Applications security guideline, a new data security policy must be created instead of modifying predefined data security policies of the security reference implementation. For example, a new data security policy is required to expose additional data records or operations for an existing business object. Additionally, a custom duty role must be created as the recipient of the new data security access permissions because granting permissions to a predefined duty role would alter the segregation of duties defined by the security reference implementation.

Additionally, the security reference implementation uses database-level security policies to protect most of the confidential personally identifiable information (PII), also called internally private data, that exists in the Oracle Fusion Applications schema. This type of security is implemented in Virtual Private Database (VPD) policies directly on the PII tables. In general, database administrators and other personnel with access to the database must not modify VPD policies implemented for Oracle Fusion Applications. However, when you create a business object that introduces confidential data and that data needs to be treated as internally private within the enterprise, then certain roles may be granted access to the confidential data for valid business reasons. For example, a human resources representative may require access to the employee's home addresses, while a dispatcher may require access to the home telephone numbers of on-call staff.

Whether or not you will need to define a data security policy to grant access to data records depends on the type of customization, as summarized in Table 7-1. The scenarios for defining data security policies include the following.

When you want to extend an Oracle Fusion application user interface to support particular end user duties, you may either create a new ADF bounded task flow or customize an existing bounded task flow. The bounded task flow specifies the control flow that the end user is expected to follow when interacting with the web pages contained by the task flow. Similarly, top-level web pages (ones that are not contained by a bounded task flow) may be introduced or customized.

Security concerned with controlling access to a bounded task flow or top-level web page is called function security. Function security policies involve granting an end user, by means of the end user's membership in a role, the ability to access task flows and perform operations in the contained web pages. For example, the accounts payable manager must be granted access permissions to the task flow that provides the functions to manage the invoice data records. If the manager is authorized to access the task flow, then a data security policy governing the invoice records will specify the manager's right to access the actual data.

Function security is implemented at the most fundamental level as resource/action pairs that may be granted to secure specific application artifacts. Oracle ADF defines the actions needed to secure certain Oracle ADF application artifacts, including ADF bounded task flows and, in the case of top-level web pages, ADF page definitions files.

In the Oracle Fusion Applications environment, function security policies aggregate one or more resource/action pairs into an entitlement definition. The entitlement is the entity that is granted to a duty role. The function security policy for the Oracle ADF application artifact, confers the end user with function access permissions, such as view or manage, through a specific duty role.

The function security policies for all the resources of the Oracle Fusion application form the function security repository, which is implemented as an OPSS application policy store. The OPSS policy store in a test or production environment is an LDAP server running Oracle Internet Directory. At runtime, OPSS performs authorization checks against the application policy store to determine the end user's access permissions.

The security administrator for the enterprise exports the LDAP-based application policy store for a particular Oracle Fusion application into an XML file-based policy store that allows you to add security policies using the tools provided by JDeveloper. As an Oracle Fusion security guideline, you must define a new function security policy rather than modify the predefined function security policies of the security reference implementation. Additionally, a custom duty role must be created as the recipient (also called the grantee) of the new function security access permissions because granting permissions to a predefined duty role would alter the segregation of duties defined by the security reference implementation.

Whether or not you will need to define a function security policy to grant access to a task flow or top-level web page depends on the type of customization, as summarized in Table 7-1. The scenarios for defining function security policies include the following.

Data security policies are stored in the Oracle Fusion Data Security repository and are defined and edited using Oracle Authorization Policy Manager. You have access to this tool through Oracle Fusion Functional Setup Manager, from the Manage Data Security task available in the Setup and Maintenance work area of any Oracle Fusion Setup application.

Data security policies control access to the database resources of an enterprise. Database resources in the security reference implementation include database tables and views and are predefined standard business objects that must not be changed. However, for cases where custom database resources must be secured business objects (defined by ADF entity objects in the data model project), you can be entitled to create custom duty roles, manage database resources, and define new data security policies using Oracle Authorization Policy Manager.

The data security policy consists of permissions conditionally granted to a role to control access to instance sets of the business object. A permission is a single action corresponding to an end user's intended operation on a single business object. A data security policy therefore is a grant of a set of permissions to a role on a business object for a given instance set. You can define the instance sets as a single row of data, multiple rows of a single table, or all rows of a single table.

The following security artifacts are recorded in the Oracle Fusion Data Security repository for a new data security policy:

• A database resource that references a primary key corresponding to the database table or view of the business object on which data security will be enforced.

• One or more roles that will be assigned to the end users who can perform the granted actions.

  For more information about the roles used by Oracle Fusion Applications, see About Extending the Security Reference Implementation.

• A rule (also called a named condition) to define the available row instance sets in the form of a SQL predicate or simple filter (stored as XML) defined on the rows of the database resource.

  Instance sets may be a single row of data, multiple rows of a single table, or all rows of a single table. Only instance sets with multiple rows require creating a named condition.

• One or more actions (such as view, edit, and delete) performed on database records that correspond to the operations supported by the business object (which may include custom operations).

At runtime, data security policies make data available to end users based on their provisioned roles according to the following means:

• Action grants that specify whether the end user has the necessary permission to perform the intended operation

• Condition evaluation for individual actions (and its corresponding operation) that specify which data records from the database resource may be accessed

Related to data security is an Oracle Fusion security feature called the data role template. Oracle Fusion Applications supplies data role templates to anticipate typical Oracle Fusion security scenarios and to allow the enterprise to generate data security policies based on information that is specific to the enterprise, such as the names of business units on which to apply the data security policies. Typically, the implementation manager for Oracle Fusion Applications enters the template information and then runs the templates to generate data security policies and the supporting data roles.

When you create a new business object or expose a new set of data records in the extended application, you must confirm whether a data role template exists to generate data security policies for that business object. If a data role template exists, you can update the template to supply information pertaining to the business object, such as the data records to secure and the data dimensions to express data stripes, such as territorial or geographic information used to partition enterprise data. A data dimension is a stripe of data accessed by a data role, such as the data controlled by a business unit.

Using Oracle Authorization Policy Manager, you may perform the following data security-related customization tasks:

• Manage database resources.

  An existing database resource must not have its primary key altered, but you can define new named conditions and add new actions to map any new operations that you implement. If you create a new business object for a database table or view, you can create an all new database resource with named conditions (see the next list entry) and actions.

• Create named conditions to filter the rows of the business object. (Optional)

  The database resource conditions are specified as SQL queries that, when added to a security policy, filter the data and generate an instance set of available data records. Conditions specify the entitlements available to the end user for specific business objects. Conditions may be static or they may be parameterized to allow instance sets to be specified generically but granted specifically. Note a condition is required only when the data security policy does not secure either a single data record or all data records: Both of these cases may be defined without named conditions when creating the security policy.

  Note that instance sets generated with parameters cannot be used for data security that is enforced declaratively. Instead, you must write code to enforce OPSS authorization checking.

• Define data security policies consisting of permissions for a specific application role, named condition (optional), and business object.

  A permission can map a standard action to a standard operation: read, update, and delete on a condition of a business object. The standard actions and the standard operations are named similarly.

  Alternatively, a permission can map a custom action to a custom operation on a condition of a business object. The custom permission, for example ApprovePO, is useful to secure a custom operation in the data model project or to secure any operation for row sets at the level of the individual ADF view object. The custom permission also supports securing operations on columns through an EL expression in the user interface project or Groovy scripting language expressions in the data model project.

  As an alternative to specifying a named condition, the data security policy can secure an instance set defined by a single data record or defined by all data records. Both of these cases may be selected when creating the data security policy.

• Generate data security policies by updating a data role template with data dimensions and data sets required to support the business object.

  A data role template generates data security policies for a business object based on supplied data dimensions to partition the data records into sets of data security policies. The template also maps instance sets for the data security policies it will generate to a particular data dimension. Instance sets are authored at the time the business object is registered as a database resource. Data dimensions and instance sets are specified as SQL clauses.

  Note that the SQL clauses cannot be modified after running the template.

For an overview of these tasks, see Defining Data Security Policies on Custom Business Objects.

You create a data model project in JDeveloper to map custom business objects to ADF entity objects. At runtime, the ADF entity object creates a row set of data records exposed by the business object and simplifies modifying the data by handling create, read, update, and delete operations. In the data model project, you then define one or more ADF view objects on top of the ADF entity object to shape the data to the row set required by the tasks of the application, such as populating a form that displays a customer's sales invoice.

Oracle Fusion security separates defining policies and enforcing policies. Thus, by default, data security policies for a business object will remain ineffective until you enable Oracle Platform Security Services (OPSS) authorization checking on the operations of the ADF business component. Enforcement of OPSS authorization checking can be specified either declaratively, at the level of ADF entity objects or ADF view objects, or programmatically, on any related code.

You can modify the data model project to opt into data security in two ways:

• At the level of the ADF entity object, to enable OPSS authorization checking on standard operations. Standard operations supported by ADF entity objects include, read, update, and delete current row. In this case, all ADF view objects based on the ADF entity object will have the same level of authorization checking enabled. The applicable data security policies will filter the data for each row set produced by these ADF view objects in exactly the same way.

• At the level of the ADF view object, to enable OPSS authorization checking on standard operations for a collection of rows. This provides a way to filter the data in the data model project based on an individual row set that the ADF view object defines. This level of authorization checking also supports defining a custom permission (corresponding to the ADF view object read operation) in the data security policy store.

Using JDeveloper, you can perform the following security-related customization tasks in the data model project:

• Enforce row-level security for standard operations.

  Standard operations that you can secure are read, update, and remove current row and are specific to the ADF entity object. OPSS authorization checking is enabled directly on the ADF entity object to be secured. Although the ADF entity object maps to all instances of the business object, the data security policy defines conditions to filter the rows displayed to the end user.

• Enforce row-level security for custom operations.

  You may wish to enforce security for custom operations that are specific to the custom business object. Custom operations are not supported by ADF Business Components on the ADF entity object. When a data security policy defines a custom operation, you must enable it using view criteria that you set on an ADF view object. The view criteria identifies the data security policy and business object.

• Enforce security for individual attributes of business objects.

  Column-level OPSS authorization checking is not supported on the attributes of ADF entity objects or ADF view objects. You must create a custom OPSS permission for the column-level read or update operation and then map that to a custom permission. Whether or not the user interface displays the column is specified by testing that custom permission in the user interface using an EL expression on the secured attribute displayed by the user interface component.

For an overview of these tasks, see About Enforcing Data Security in the Data Model Project.

Before you define function security policies, you will use JDeveloper to create a user interface project with the custom ADF bounded task flows or top-level web pages that you intend to secure.

To simplify the task of securing the functions of the extended application, ADF Security defines a containment hierarchy that lets you define a single security policy for the ADF bounded task flow and its contained web pages. In other words, the security policy defined at the level of the bounded task flow, secures the flow's entry point and then all pages within that flow are secured by the same policy. For example, a series of web pages may guide new end users through a registration process and the bounded task flow controls page navigation for the process.

Specifically, the Oracle ADF application artifacts that you can secure in the user interface project of the extended Oracle Fusion application are:

• An ADF bounded task flow that protects the entry point to the task flow, which in turn controls the end user's access to the pages contained by the flow

  The ADF unbounded task flow is not a securable application artifact and thus does not participate in OPSS authorization checking. When you must secure the contained pages of an unbounded task flow, you define policies for the page definition files associated with the pages instead.

• ADF page definition files associated with top-level web pages

  For example, a page may display a summary of products with data coordinated by the ADF bindings of the page's associated ADF page definition file.

Oracle Fusion security separates defining policies and enforcing policies. Thus, by default, function security policies will remain ineffective until you enable OPSS authorization checking by running the ADF Security wizard in JDeveloper on the user interface project.

Using JDeveloper, you can perform the following security-related customization tasks in the user interface project:

• Enable OPSS authorization checking to protect Oracle ADF application artifacts.

  Oracle ADF application artifacts in the user interface project, including ADF bounded task flows and the top-level web pages (with a backing ADF page definition) will be protected when you configure ADF Security by running the ADF Security wizard with the Authentication and Authorization option selected. This ensures that end users do not have unintended access to sensitive task flows of the extended application.

• Conditionally display or hide user interface components in the web page.

  ADF Security implements utility methods for use in EL expressions to access Oracle ADF application artifacts in the security context. For example, you can use the ADF Security utility methods to specify whether the end user has use the EL expression to evaluate whether the end user has the necessary permission grant to access create, edit, or delete buttons. Good security practice dictates that your application must hide user interface components and capabilities for which the end user does not have access. For example, if the end user is not allowed access to a particular task flow, you can use the EL expression to evaluate whether the end user has the necessary permission grant to determine whether or not to render the navigation components that initiate the task flow.

For an overview of these tasks, see About Defining Function Security Policies for the User Interface Project.

You can use JDeveloper to add application security policies to a file-based policy store that the security administrator creates by exporting policies from the LDAP-based application security policy store. The file containing the exported policy store is the jazn-data.xml file.

As a security development guideline, use only JDeveloper tools to work on the exported file-based policy store. JDeveloper supports iterative development of security so you can locally define, test, and edit security policies that you define for Oracle ADF application artifacts. In JDeveloper, you can also create end user identities for the purpose of running and testing the application in JDeveloper's Integrated WebLogic Server. You provision a few end user test identities with roles to simulate how the actual end users will access the secured application artifacts in your local environment before deploying the application.

After testing in JDeveloper using Integrated WebLogic Server, you must consult with the security administrator to merge the LDAP-based application policy store in the staging environment with the security policies that you added to the exported XML file. Initially, the staging environment allows further testing using that server's identity store before deploying to the production environment. Thus, end user identities created in JDeveloper are not migrated to standalone Oracle WebLogic Server and are used only in Integrated WebLogic Server to test the extended application.

The basic security artifact for function security is the JAAS (Java Authentication and Authorization Service) permission, where each permission is specific to a resource type and maps the resource with an allowed action. In general, the JAAS permission specifies the allowed operations that the end user may perform on a particular application artifact. However, from the standpoint of Oracle Fusion Applications, end users typically need to interact with multiple resources to complete the duties designated by their provisioned roles. To simplify the task of creating function security policies in the Oracle Fusion Applications environment, you work with OPSS entitlements to grant permissions to a role for a variety of securable resources, including ADF task flows, web services, and service-oriented architecture (SOA) workflows.

Function security policies that comprise entitlement grants with multiple application artifacts are called entitlement-based policies. The following example shows the Oracle Fusion Applications entitlement policy Maintain Purchase Orders, which groups the OPSS permissions for ADF task flows, a web service, and a SOA workflow.

You use the security policy editor in JDeveloper to define the entitlement-based policy. JDeveloper modifies the source in the exported XML file. As the following example shows, entitlement-based policies in Oracle Fusion applications are defined in the <jazn-policies> element. The policy store section of the file contains the following definitions:

• A <resource-type> definition that identifies the actions supported for resources of the selected type

• A <resource> definition to identify the resource instance that you selected from your application and mapped to a resource type

• A <permission-set> definition to define the resources and actions to be granted as an entitlement

• A <grant> definition with one or more entitlements (defined in the XML as a <permission-set>) and granted to the desired application roles (the grantee)

While OPSS permissions granted for a single resource are not typically defined in the Oracle Fusion Applications environment, function security policies that use OPSS permissions for a single resource are called resource-based policies. Ultimately, a function security policy may have either one or more OPSS permissions, one or more OPSS permission sets (entitlements), but not both.

Provisioning end users with role membership is defined in the application's identity store and is a configuration task to be performed by the security administrator, independent of security customization.

Using JDeveloper, you may perform the following function security customization tasks:

• Define an entitlement-based policy for all other application roles.

  An entitlement-based policy is a set of resource grants (set of OPSS permissions) that will be required by the end user to complete a task.

• Define a resource-based policy specifically for the built-in OPSS application role authenticated-role.

  A resource-based policy sets an OPSS permission on a single application resource and grants that permission to an application role. This type of function security is typically not used by securable resources in Oracle Fusion Applications. However, the resource-based policy must be used to make a custom resource accessible to any authenticated end user (ones who visit the site and log in). For example, granting a view permission to the built-in OPSS application role authenticated-role is the way to make an employee registration task flow accessible to all employees within the enterprise.

For an overview of these tasks, see About Defining Function Security Policies for the User Interface Project.

Resource Type: ADF Taskflow
Resource: PO Summary
Action: view

Resource Type: ADF Taskflow
Resource: PO Details
Action: view

Resource Type: ADF Taskflow
Resource: Supplier Details
Action: view

Resource Type: Web Service
Resource: SpendingLimitCheckWS
Action: invoke

Resource Type: Workflow
Resource: POApproval
Action: submit

<?xml version="1.0" ?>
<jazn-data>
  <policy-store>
    <applications>
      <application>
        <name>MyApp</name>
                
      <app-roles>
        <app-role>
          <name>AppRole</name>
          <display-name>AppRole display name</display-name>
          <description>AppRole description</description>
          <guid>F5494E409CFB11DEBFEBC11296284F58</guid>
          <class>oracle.security.jps.service.policystore.ApplicationRole</class>
        </app-role>
      </app-roles>
                
      <role-categories>
        <role-category>
          <name>MyAppRoleCategory</name>
          <display-name>MyAppRoleCategory display name</display-name>
          <description>MyAppRoleCategory description</description>
        </role-category>
      </role-categories>
                
      <!-- resource-specific OPSS permission class definition -->
      <resource-types>
        <resource-type>
          <name>APredefinedResourceType</name>
          <display-name>APredefinedResourceType display name</display-name>
          <description>APredefinedResourceType description</description>
          <provider-name>APredefinedResourceType provider</provider-name>
          <matcher-class>oracle.security.jps.ResourcePermission</matcher-class>
          <actions-delimiter>,</actions-delimiter>
          <actions>write,read</actions>
        </resource-type>
      </resource-types>
                
      <resources>
        <resource>
          <name>MyResource</name>
          <display-name>MyResource display name</display-name>
          <description>MyResource description</description>
          <type-name-ref>APredefinedResourceType</type-name-ref>
        </resource>
      </resources>
                
      <!-- entitlement definition -->
      <permission-sets>
        <permission-set>
          <name>MyEntitlement</name>
          <display-name>MyEntitlement display name</display-name>
          <description>MyEntitlement description</description>
          <member-resources>
            <member-resource>
              <type-name-ref>APredefinedResourceType</type-name-ref>
              <resource-name>MyResource</resource-name>
              <actions>write</actions>
            </member-resource>
          </member-resources>
        </permission-set>
      </permission-sets>
                
      <!-- Oracle function security policies -->
      <jazn-policy>
        <!-- function security policy is a grantee and permission set -->
        <grant>
          <!-- application role is the recipient of the permissions -->
          <grantee>
            <principals>
              <principal>
                <class>
                   oracle.security.jps.service.policystore.ApplicationRole
                </class>
                <name>AppRole</name>
                <guid>F5494E409CFB11DEBFEBC11296284F58</guid>
              </principal>
            </principals>
          </grantee>
          <!-- entitlement granted to an application role -->
          <permission-set-refs>
            <permission-set-ref>
              <name>MyEntitlement</name>
            </permission-set-ref>
          </permission-set-refs>
        </grant>
      </jazn-policy>
    </application>
  </applications>
 </policy-store>
</jazn-data>

After you define the security policies, consult a security administrator to migrate the policies to the staging environment.

The security administrator is responsible for the following tasks.

• After testing is completed in JDeveloper, the security administrator must merge the file-based policy store with the application policy store in the staging environment.

• The security administrator must provision enterprise users by mapping enterprise roles (defined in the staging environment identity store) to the custom application roles.

• Before running the application in the staging environment, the security administrator must reconcile the application role GUID of any data security policies that were created based on new custom application roles.

  When the file-based policy store is merged, the GUIDs of application roles are not preserved.

• Before running the application in the staging environment, the security administrator must modify the application to use the LDAP-based policy store provided by the testing environment.

• After testing is completed in the staging environment, the security administrator can migrate the application policy store from the staging environment to the policy store in production.

1. Install JDeveloper and set up your development environment.

   For more information, see About Installing Customization Tools.

2. Create a customization application workspace.

   Before you can implement customizations using JDeveloper, you must create an application workspace that imports the necessary parts of the application you want to customize. For more information, see Using for Customizations .

3. Start JDeveloper in the appropriate role.

   If you are implementing customizations on existing application artifacts, you must select the Oracle Fusion Applications Administrator Customization role when you start JDeveloper.

   If you are creating new custom application artifacts (such as, entity objects, view objects, and pages), you must select the Oracle Fusion Applications Developer role when you start JDeveloper.

4. Create the database resources in a custom schema for Oracle Fusion Applications.

   The database table exposes the data in your application. You are free to use any tool you wish to create database objects in your custom schema. For example, you may choose to work with the Database Navigator in JDeveloper to model database objects. For information about creating the table in a custom schema, see About Customizing and Extending the Schemas. For information about creating database objects, see the Designing Databases topics in the JDeveloper online help.

5. When securing confidential personally identifiable information (PII), create a new table in a custom schema for Oracle Fusion Applications and a VPD policy to associate a PL/SQL filter function with the table.

   The VPD policy filters the view to expose the data for which data security policies may be defined. For information about creating the table in a custom schema, see About Customizing and Extending the Schemas.

6. Obtain permissions to define or edit Oracle Fusion Data Security security policies.

   If you will be creating or editing Oracle Fusion Data Security security policies in Oracle Fusion Applications, you will need specific permissions. When you have the necessary permissions, Oracle Authorization Policy Manager allows you to access the data security customization user interface. Contact your security administrator for details.

7. In Oracle Authorization Policy Manager, create custom application roles.

   Data security and function security permit granting access permissions to Oracle Fusion Applications duty roles (also called OPSS application roles). Although Oracle Fusion Applications ships with standard duty roles, as an Oracle Fusion security guideline, you must create new duty roles rather than grant permissions to predefined duty roles.

   For information about creating application roles, see "Managing Policy Objects in an Application" in the online help for Oracle Authorization Policy Manager.

8. In human capital management (HCM) core applications, create job roles, as needed.

   Job roles (also called OPSS enterprise roles) provide access to application resources through the Oracle Fusion Applications role inheritance hierarchy, which specifies the inherited duty roles. Although Oracle Fusion Applications ships with standard job roles, the security administrator can create a new job role even when one does already exist that defines the new duties.

   The security administrator uses integrated Oracle Identity Management pages to create and manage job roles in Oracle Fusion Applications.

9. Identify the ADF business components in your application's data model project that you want to create or customize.

   You can create or customize ADF entity objects and ADF view objects using JDeveloper to expose business objects in your application and opt into data security policies. For information about creating these ADF business components, see Customizing and Extending Application Artifacts.

10. Identify the application artifacts in your user interface project that you want to create or customize.

    The following application artifacts that you create or customize using JDeveloper may be secured: ADF bounded task flows and ADF page definition files for top-level web pages. For information about creating these application artifacts, see Customizing and Extending Application Artifacts.

11. In JDeveloper, run the ADF Security wizard on your application.

    When you run the ADF Security wizard, it configures your application to enable authorization checking so that Oracle Platform Security Services (OPSS) running in Oracle WebLogic Server (and in JDeveloper's test environment, Integrated WebLogic Server) will utilize the security policies to authorize access to application resources by the end user. OPSS determines whether the end user (represented by the JAAS subject) has the permissions necessary to access the resources they intend.

Data security policies secure the database resources of an enterprise. The Oracle Fusion security reference implementation provides a comprehensive set of predefined data security policies for database resources that involve database tables and views that correspond to business objects; it is recommended that these database resources not be changed.

If you will be creating or editing Oracle Fusion Data Security security policies in Oracle Fusion Applications, you will need specific permissions. When you have the necessary permissions, Oracle Authorization Policy Manager allows you to access the data security customization user interface. Contact your security administrator for details.

The security reference implementation defines the job role IT Security Manager with a duty role hierarchy that includes the Application Data Security Administration Duty duty role. This duty role is entitled to manage data security policies (the entitlement is Manage Data Security Policy) and provides the access necessary to perform the Manage Data Security Policies task in Oracle Authorization Policy Manager. Contact your security administrator for details.

Collect the following information that you will use to define the data security policy in Oracle Authorization Policy Manager:

• The primary key of the database table or view that the custom business object represents

  You specified the primary key of the database table or view when you registered the database resource.

• The names of the conditions for which you want the security policy to control access

  When you registered the database resource, you may have created named conditions to control access to instance sets composed of multiple rows (Oracle Fusion Data Security does not require that you create a named condition when you want to grant access to instance sets composed either of a single row or of all rows of the database resource).

• The names of the actions for which you want to associate with a particular named condition (or instance set) to control access

  When you registered the database resource, you named actions to identify the securable operations of the custom business object. Action names must be identical to the names of the operations the business object supports. For example, the names of actions corresponding to the supported standard operations are view, edit, and delete. However, if your data model project defines custom operations, actions may have names corresponding to operations named, for example, as view_US_ONLY, edit_US_ONLY, or delete_US_ONLY .

• The names of the custom duty roles for which you want to grant access to the conditions and actions of the database resource associated with the custom business object

  As an Oracle Fusion Applications security guideline, predefined duty roles defined by the security reference implementation must not be modified. You must use Oracle Authorization Policy Manager to create a new duty role rather than grant data security permissions to predefined duty roles.

Data security consists of permissions conditionally granted to a role, and these grants are used to control access to instance sets of a business object. A permission is a single action corresponding to an operation on a single business object. Instance sets are rows of a database resource returned by a user-defined SQL WHERE clause; instance sets may be a single row of data, multiple rows of a single table, or all rows of a single table. A data security policy is, therefore, a set of permissions to a principal on a business object for a given instance set.

The security administrator uses Oracle Authorization Policy Manager to create and administer data security policies. A data security policy involves the following security artifacts:

• A database resource that references a primary key corresponding to the database table or view of the business object to be secured

• A role that has been provisioned with the users who can perform the granted actions

• A rule (also known as a condition) to define the available row instances in the form of an SQL predicate or simple filter (stored as XML) defined on the rows of the database resource

• One or more actions (such as view, edit, or delete) performed on database records that correspond to the operations supported by the business object, and which may include custom operations

A template or data role template specifies key characteristics of external roles and data security policies. These characteristics include:

• A set of base external roles

• A set of dimension values

• A set of naming rules

When run, the data role template generates all the external roles and the data security policies that satisfy the values in the template. The external roles generated (by a template run) are stored in the domain identity store; the data security policies generated are stored in the data security store; templates are stored in the metadata storage (MDS).

The basic principle behind the generation of external roles and data policies is that one can take the cross product of the first two sets of characteristics (external roles times dimension values) to obtain a set of external roles named according to the third set (naming rules), and associate them with a set of permissions, for a given data stripe, in data security policies.

The external roles and the data security policies that a template run generates are specified as a set of external roles and a set of dimensions (rows or attributes returned by an SQL query). Each dimension attribute is associated with an alias, which is used (by the naming conventions) to generate names for the roles and data security policies generated.

A dimension attribute can be the attribute return by an SQL query, such as, the following:

where territory=US, business unit=Finance, and legal entity=North America

The number of external roles generated equals the number of specified external roles times the number of rows returned by the query (or number of dimensions). Each external role generated inherits from the corresponding specified external role.

For example, a template specifying the external roles Employee-Role and Manager-Role, the dimensions US and UK, and the naming rule [external role]:[dimension code name] would generate the following four external roles:

Employee-Role:US, Employee-Role:UK, Manager-Role:US, Manager-Role:UK

Each of the four generated role inherits from one of the specified external roles, Employee-Role or Manager-Role.

The list of external roles and data security policies that a template run generates can be previewed, that is, displayed before the actual creation of roles and associated data security policies takes place.

If you will be creating or editing Oracle Fusion Data Security security policies in Oracle Fusion Applications, you will need specific permissions. When you have the necessary permissions, Oracle Authorization Policy Manager allows you to access the data security customization user interface. Contact your security administrator for details.

The security reference implementation defines the job role IT Security Manager with a duty role hierarchy that includes the Application Data Security Administration Duty duty role. This duty role is entitled to manage data security policies (the entitlement is Manage Data Security Policy) and provides the access necessary to perform the Manage Data Security Policies task in Oracle Authorization Policy Manager. Contact your security administrator for details.

Two particular data sources must be set using WebLogic Server before using data role, described in the following table. Each data source can be configured with the WebLogic Console by navigating to JDBC > Data Sources. The data source ApmRgxDimDBDS must be created with a credential that includes the database writing permission.

Additionally, collect the following information that you will use to define the data security policy in Oracle Authorization Policy Manager:

• The primary key of the database table or view that the custom business object represents

  You specified the primary key of the database table or view when you registered the database resource.

• The names of the conditions for which you want the security policy to control access

  When you registered the database resource, you may have created named conditions to control access to instance sets composed of multiple rows (Oracle Fusion Data Security does not require that you create a named condition when you want to grant access to instance sets composed either of a single row or of all rows of the database resource).

• The names of the actions for which you want to associate with a particular named condition (or instance set) to control access

  When you registered the database resource, you named actions to identify the securable operations of the custom business object. Action names must be identical to the names of the operations the business object supports. For example, the names of actions corresponding to the supported standard operations are view, edit, and delete. However, if your data model project defines custom operations, actions may have names corresponding to operations named, for example, as view_US_ONLY, edit_US_ONLY, or delete_US_ONLY .

• The names of the custom duty roles for which you want to grant access to the conditions and actions of the database resource associated with the custom business object

  As an Oracle Fusion Applications security guideline, predefined duty roles defined by the security reference implementation must not be modified. You must use Oracle Authorization Policy Manager to create a new duty role rather than grant data security permissions to predefined duty roles.

A business object can be mapped to a set of dimension values and data role naming rules defined by data role templates. A data role for a defined set of data describes the job an end user does within that defined set of data. A data role inherits job or abstract roles and grants entitlement to access data within a specific dimension of data based on data security policies. The dimension expresses data stripes, such as territorial or geographic information you use to partition enterprise data. You use data role templates to generate data roles and the template applies the values of the dimension and participant data security policies to the group of base roles.

The ADF entity object in a data model project defines metadata that enables OPSS authorization checking against data security policies for view, update, or delete operations (also called standard operations) of the registered business object. You enable row-level security for standard operations by selecting the operation on the ADF entity object that maps to the business object upon which data security policies exist. Although the ADF entity object maps to all instances of the business object, the data security policy defines business object conditions to filter the records available to the end user. Filtering of the business object for standard operations supports only row-level security.

To enforce authorization checking for standard operations:

1. In JDeveloper, display the ADF entity object in the overview editor.

2. In the editor, click the General navigation tab and expand the Security section, and then select the list of standard operations for which you want to enforce authorization checking against data security policies.

For further information about enforcing row security for standard operations, see the "Implementing Oracle Fusion Data Security" chapter of the Developer's Guide.

The ADF entity object in a data model project does not support OPSS authorization checking against data security policies for custom operations of the registered business object. You enable row-level security for custom operations by mapping view criteria that you create in the data model project to custom permissions in the data security policies defined on the business objects. The view criteria creates a row set filter by naming the custom permission and business object. Filtering of the business object by view criteria works only with custom operations.

To enforce authorization checking for a custom operation:

1. In JDeveloper, display the ADF view object that you will use to filter the rows and, in the overview editor for the view object, click the Query navigation tab.

2. Expand the View Criteria section and then you click the Add button to create a view criteria to enforce authorization checking for a custom operation. The view criteria must be defined as follows:

   • In the Create View Criteria dialog, create a named view criteria with no view criteria items and name the view criteria using the following format:

     FNDDS__permissionName__objectName__objectAlias
     

     where:

     permissionName is the permission name that is used to filter the data.

     objectName is the name of the secured database resource in the FND_OBJECTS table.

     objectAlias is optional and is the alias for the resource.

     Note:

     The delimiter is "__" (double underscore characters). This is because no other special character is allowed in a view criteria name.

   • Select Both for the Query Execution Mode.

     The query execution mode for the data security view criteria must be set to Both. If you leave the default setting Database selected, then the ADF Business Components association consistency feature will not work properly.

3. Double click the application module that defines the view instance to be filtered and, in the application module overview editor, select the Data Model navigation tab and select the view instance to filter, then click Edit to apply the previously defined view criteria.

For further information about enforcing row security for a custom operation, see the "Implementing Oracle Fusion Data Security" chapter of the Developer's Guide.

The ADF entity object in a data model project does not support authorization checks against data security policies for columns of the registered business object. You enable security for attributes by creating a custom OPSS permission to control access to the column read or update operation, and then, in the Oracle Fusion Data Security repository, you map the operation to a custom permission and grant the permission to specify the roles that are authorized to view or update the data records. Last, in the user interface, you enter an EL expression to test that custom permission on the user interface component displaying the attribute.

For further information about enforcing security for attributes of a business object, see the "Implementing Oracle Fusion Data Security" chapter of the Developer's Guide.

As a security development guideline, you must use only JDeveloper tools to define function security policies. This requires a security administrator to export the policies that exist in the LDAP-based application security policy store (residing in a production environment) into an XML file that can be loaded in JDeveloper and edited using the provided security policy editor.

After editing the XML file, you must consult the security administrator to merge the security policies into the production environment.

In addition, consult the security administrator to obtain the file-based application policy store in the form of a jazn-data.xml file. The security administrator can run an Oracle WebLogic Scripting Tool (WLST) script to export the LDAP-based application policy store to the XML file. For further information about how the security administrator exports the application policy store, see the "Extracting Data from an OID Store to a File" section in the Administrator's Guide.

If the custom bounded task flows or top-level web pages do not appear in the user interface project of the extended application, then you cannot define application security policies. You must use JDeveloper to create the securable Oracle ADF application artifacts. For more information, see Customizing and Extending Application Artifacts.

As an Oracle Fusion Applications security guideline, predefined duty roles defined by the security reference implementation must not be modified. You must use Oracle Authorization Policy Manager to create a new duty role rather than grant function security permissions to predefined duty roles. For further information about creating duty roles, see "Managing Policy Objects in an Application" in the online help for Oracle Authorization Policy Manager, where they are known as application roles.

Tasks that you perform to secure functions of the application depend on the type of function and whether the function should be publicly accessible.