15 Customizing Security for Oracle ADF Application Artifacts

This chapter describes how to customize security for custom and extended business objects and related custom and extended application artifacts defined by Oracle Application Development Framework (Oracle ADF) in Oracle Fusion applications. Developers customize security using Oracle Authorization Policy Manager and Oracle JDeveloper.

Security customization in the production environment is typically restricted to the security administrator using Oracle Authorization Policy Manager; however, during the development phase of application customization, you can perform similar security customization tasks using Oracle Authorization Policy Manager and JDeveloper.

This chapter includes the following sections:

• Section 15.1, "About the Oracle Fusion Security Approach"

• Section 15.2, "About Extending the Oracle Fusion Applications Security Reference Implementation"

• Section 15.3, "About Extending and Securing Oracle Fusion Applications"

• Section 15.4, "Defining Data Security Policies on Custom Business Objects"

• Section 15.5, "Enforcing Data Security in the Data Model Project"

• Section 15.6, "Defining Function Security Policies for the User Interface Project"

15.1 About the Oracle Fusion Security Approach

Oracle Fusion Applications is secure as delivered. The Oracle Fusion security approach tightly coordinates various security concerns of the enterprise, including:

• The ability to define security policies to specify the allowed operations on application resources, including viewing and editing data and invoking functions of the application.

• The ability to enforce security policies by using roles assigned to end users, and not by directly enforcing those policies on the end users of the system.

A role is an identity that end users are anticipated to fill when interacting with Oracle Fusion Applications that specifically determines the user's permitted access to data and application functions. For example, when an end user attempts to access a task flow, whether or not the end user has the right to enter the task flow and view the contained web pages is specified by the roles provisioned to the end user and the security policies defined for those roles.

In the enterprise, the security administrator ensures end users are provisioned with the privileges to perform the duties of their various jobs. A privilege determines the user right to access data and application functions of Oracle Fusion applications. The provisioning tasks involve Oracle Fusion Middleware tools that integrate with Oracle Fusion Applications and allow IT personnel to extend the security reference implementation. These tools directly update a copy of the security reference implementation in the deployed application's security policy store and identity store. The security reference implementation provides role-based access control in Oracle Fusion Applications, and is composed of predefined security policies that protect functions, data, and segregation of duties.

From the standpoint of application developers who seek to apply the Oracle Fusion security approach to an Oracle Fusion application that they extend, the security implementation process overlaps with tasks performed by IT personnel. You may or may not need to extend the Oracle Fusion Applications security reference implementation, depending upon how end users will interact with the new resource. At the end of the process, you must ensure that any new resource you create, such as a business object in the data model project or a task flow in the user interface project, has sufficient security policies to grant access privileges and suitable roles to receive the access privileges.

15.1.1 How to Proceed with This Chapter

Customizing security is a complex process that involves working with several tools, familiarity with diverse technologies, and coordination between the application developer and security administrator. For a concise summary of the security customization scenarios and corresponding tasks, see Table 15-1 in Section 15.3.3, "Oracle Fusion Security Customization Scenarios."

After familiarizing yourself with the types of security customizations performed by the application developer, read the following sections to gather a more complete understanding of the security customization process:

• For an overview of the Oracle Fusion Applications security reference implementation, see Section 15.2.

• For a list of security guidelines that dictate which security artifacts in the Oracle Fusion Applications security reference implementation you may or may not modify, see Section 15.3.1.

• For an overview of the steps you follow to secure a new resource, see Section 15.3.2.

• For additional background about the type of resource customizations that require customizing security, see Section 15.3.4 and Section 15.3.5.

• For details about the security artifacts that you define to create security policies, see Section 15.3.6 through Section 15.3.9.

• For a list of tasks that may be performed only by a security administrator, see Section 15.3.10.

• For a list of prerequisite tasks to be completed before customizing security, see Section 15.3.11.

• For information about the tools involved in customizing security, see Section 15.4 through Section 15.6.

15.1.2 Related Security Documents

The following related documents contain important information specific to customizing security in Oracle Fusion Applications. References to these documents appear throughout this chapter. Consult these documents for complete details.

• Oracle Fusion Applications Security Guide

  Describes the concepts and best practices of the Oracle Fusion security approach. This is the main document addressing the Oracle Fusion security approach.

• Oracle Fusion Applications Security Hardening Guide

  Describes how security administrators proceed to implement the Oracle Fusion Applications security reference implementation for their enterprise.

• Oracle Fusion Applications security reference manuals

  Describes the segregation of duties in the Oracle Fusion Applications security reference implementation. Each Oracle Fusion application has its own reference manual.

• Oracle Fusion Applications Developer's Guide

  Describes how to secure new custom resources in Oracle Fusion Applications. Includes chapters describing how to implement data security and function security for new resources.

• Oracle Fusion Applications Administrator's Guide

  Summarizes available security administration tasks in a single chapter.

• Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition)

  Describes how to create and modify data security policies and data role templates.

• Oracle Fusion Middleware Application Security Guide

  Describes the concepts and best practices of Oracle Platform Security Services (OPSS) upon which Oracle Fusion security is based. This is the main document addressing the architecture of Oracle security services.

• Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework (Oracle Fusion Applications Edition)

  Describes ADF Security, through which Oracle ADF components interact with OPSS.

• Oracle Fusion Middleware User's Guide for Oracle Identity Manager

  Describes role provisioning and other identity management tasks.

• Oracle Database Security Guide

  Describes implementing security policies at the level of the database.

• JDeveloper online help topics

  Describes the tools used to create database objects using JDeveloper.

15.2 About Extending the Oracle Fusion Applications Security Reference Implementation

The Oracle Fusion Applications security approach is embodied in the security reference implementation, which delivers predefined roles and security policies that address the common business needs of the enterprise. The reference implementation can be extended to adjust to the needs of a specific enterprise. The predefined security policies implement role-based access control: a set of roles recognizable as jobs, a role hierarchy that contains the duties for those jobs, and a set of role provisioning events and workflows. The Oracle Fusion Applications security reference implementation represents what Oracle considers to be the general security guidelines for jobs, roles, duties, and segregation of duties.

In general, the Oracle Fusion Applications security reference implementation is designed to require only small changes to adjust Oracle Fusion security for a specific enterprise. The security reference implementation provides a comprehensive set of predefined security policies and predetermined data role templates that may be customized to generate security policies. From the standpoint of security administrators who address the specific security concerns of their organizations, typical tasks include changing or extending role definitions and role hierarchies, and managing security policies and data role templates. For example, enterprise IT security administrators eventually review the duties and access defined in the security reference implementation and specify how that matches with the job titles and tasks the enterprise expects to be performed in the deployed Oracle Fusion application.

A security administrator provisions end users with role membership, and defines the provisioning in the application's identity store. This configuration task is performed independent of security customization. The Oracle Fusion Applications security reference implementation contains four types of roles: duty, job, data, and abstract, and implements hierarchies between these roles to streamline provisioning access to end users. Each of the Oracle Fusion Applications roles is implemented in Oracle Fusion Middleware as one of the following roles:

• Internal roles are roles that are not assigned directly to end users. An internal role is also called an application role because it is specific to an application.

  Note that, in Oracle Fusion Applications, application roles are called duty roles. The security reference implementation defines a large number of duty roles that correspond to the duties of individual job roles. Duty roles are specific to applications, stored in the policy store, and shared within an Oracle Fusion Applications instance. For example, in your enterprise, the job of an application developer may also include project management duties. The duty role is a role that corresponds to a line on a job description for that job.

• External roles are roles associated with a collection of end users and other groups. They are also called enterprise roles because they are shared across the enterprise.

  In Oracle Fusion Applications, enterprise roles include:

  • The job role is a role that corresponds to a job title defined in human resources (HR).

  • The data role is a role that authorizes a person with a job to a particular dimension of data on which they can work. For example, the data role AP Manager - US Commercial Business Unit identifies who may access the accounts specific to the US division of the enterprise.

  • The abstract role is a role that is not a job title, but is a means to group end users without respect to specific jobs, for example, Employee and Line Manager are both abstract roles.

The division between internal roles and external roles is an important principle of the Oracle Fusion security approach. The principle, called least privilege, ensures that the end user acquires privileges specific only to the job they perform rather than to a variety of miscellaneous duties. Therefore, in adherence to the principle of least privilege, duty roles are defined by Oracle Platform Security Services (OPSS) as internal roles and cannot be assigned directly to end users.

To understand the Oracle Fusion security approach in detail and to learn more about using the Oracle Fusion security infrastructure to implement and administer security for the enterprise, see the "Introduction" chapter in the Oracle Fusion Applications Security Guide.

15.3 About Extending and Securing Oracle Fusion Applications

Oracle Fusion Applications is configured by default to deny end users access to the data of the application domain and the web pages that display the data. An important principle of Oracle Fusion security ensures that end users do not have unintended access to data and application artifacts exposed in the extended application.

To enable access to custom resources in the extended application, you may create security policies to specify "who can perform what operations on what specific data and on what specific application artifacts."

Note:

The term protected in this chapter refers to the default Oracle Fusion Applications condition that denies end users access to database resources and application artifacts. In contrast, the term secured refers to resources that have been made accessible to end users through security policies created for this purpose. Therefore, a security policy specifically enables access to the resource based on the privileges it confers to the end user.

To create the security policy, you must consider the additional duties the end users of the extended application will perform, and then grant the required roles the specific privileges to:

• Access the web pages of a custom task flow that supports the duty

• Access the specific data records, or instances of a custom business object, required to complete the duty

• Perform only those operations on that data required by the duty

When you need to secure new resources, you can expect to work with two different types of security policies: data security policies that control access to the data records of database tables or views in the Oracle Fusion Applications schema, and function security policies that control access to the Oracle Fusion application artifacts used to display the data. Because the representation of data security policies and function security policies differs, the environment you will use to define security policies depends on whether data security or function security is being implemented.

In the case of access to data records, a custom business object may be secured either explicitly or implicitly. For example, the AP Manager is authorized to an explicit list of business units specified by a data role, whereas the Project Manager is implicitly authorized to the projects that he manages. When you need to secure data records, then you can:

• Implicitly grant data access to abstract and job roles through data security policies you define on custom duty roles inherited by the abstract or job role.

  You can create custom duty roles to support a new duty introduced by a custom application resource.

• Explicitly grant data access to a data role through a data security policy you apply directly to the inherited job or abstract role using a data role template.

  You can customize the data role template before running the template to generate the data roles.

15.3.1 Oracle Fusion Security Customization Guidelines for New Functionality

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 privileges granted to duty roles.

  • Do not add (also called grant) new privileges 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 privileges 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 privileges 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.

Note:

You must not modify predefined duty roles, and you must always add custom duty roles to grant access privileges. Only the security administrator can add or remove duty roles associated with an existing job role. If a predefined job role that adequately describes the duties performed by a job does not exist, then the security administrator can also create a new job role.

15.3.2 Oracle Fusion Security Customization Process Overview

Creating a new, custom business object and exposing it in the extended application is one of the main customization tasks that you may perform. Although you may also extend existing business objects to introduce new functionality or to introduce additional data, the security customization process for new and existing business objects follows a similar pattern.

To secure a new business object in the extended Oracle Fusion application:

1. Create a custom duty role to serve as the grantee of the security policy privileges.

   For details about creating duty roles, see the "Managing Policies and Policy Objects" chapter in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).

2. Define a database resource in the Oracle Fusion Data Security repository to protect the data records of a database table that you intend to expose in the application.

   For details about registering a database table as a database resource, see Section 15.3.6, "What You Can Customize in the Data Security Policy Store at Design Time."

   This step causes Oracle Fusion security to protect the database table records, thus rendering the data inaccessible to the end user of the application. A data security policy will be required to grant access to the data defined by the database resource and a function security policy will be required to grant access to the application artifacts that display the data in the extended application.

3. Define data security policies for the previously defined database resource to grant access to specific data records for a given role.

   For details about securing data, see Section 15.3.6, "What You Can Customize in the Data Security Policy Store at Design Time."

4. Extend the data model project (in the extended application) with a new entity object to expose the database table that you defined as an Oracle Fusion Data Security database resource.

   For details about creating custom business components to represent a database table, see Chapter 11, "Customizing and Extending Oracle ADF Application Artifacts."

5. Opt into the previously defined data security policies by enabling OPSS authorization checking on the operations of individual data model objects in the data model project.

   For details about enabling security, see Section 15.3.7, "What You Can Customize in the Data Model Project at Design Time."

6. Consult a security administrator to export all predefined function security policies of the application that you are customizing into a jazn-data.xml file.

   For details about how the security administrator exports the application policy store, see the "Securing Oracle Fusion Applications" chapter in the Oracle Fusion Applications Administrator's Guide.

7. Copy the exported jazn-data.xml file into your application workspace.

   For details about adding the file to your application, see the "Implementing Function Security" chapter in the Oracle Fusion Applications Developer's Guide.

8. Customize the Oracle ADF application artifacts in the user interface project to display the data records exposed by the extended data model.

   For details about creating securable custom application artifacts, see Chapter 11, "Customizing and Extending Oracle ADF Application Artifacts."

9. Define function security policies for the custom Oracle ADF application artifacts to specify the access privileges of end users.

   For details about securing application functions, see Section 15.3.9, "What You Can Customize in the Application Security Policy Store at Design Time."

10. Opt into the previously defined function security policies by running the ADF Security wizard to enable OPSS authorization checking.

    For details about enabling security on the user interface project, see Section 15.3.8, "What You Can Customize in the User Interface Project at Design Time."

15.3.3 Oracle Fusion Security Customization Scenarios

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.

Table 15-1 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 Section 15.1.1, "How to Proceed with This Chapter").

Note:

For simplicity, Table 15-1 does not make a distinction between explicit and implicit data security policies. You may also need to customize data role templates when a custom business object is used as a data stripe and explicit data security policies grant access to that data stripe. For more details about customizing data role templates, see Section 15.3.6, "What You Can Customize in the Data Security Policy Store at Design Time."

Table 15-1 Oracle Fusion Applications Security Customization Scenarios

Security Customization Goal	Security Policy Requirement	Application Developer Tasks
Control whether the end user associated with a particular role may access a new task flow and view all the web pages of the flow.	Create a new security policy. The new task flow will be inaccessible by default (also called protected) and will require a new function security policy to grant end users access.	Enable ADF Security on the user interface project to protect all task flows (and the web pages they contain). Then, in the file-based policy store, create a resource definition for the task flow and assign the definition as a member of an entitlement (defined in the policy store as a permission set) that you name. Then, create the security policy by granting the entitlement to a custom application role that you either created or consulted with a security administrator to create for you. As a security guideline, do not modify a predefined function security policy by granting additional entitlements to a predefined duty role.
Control whether the end user associated with a particular role may access a customized task flow and view the new or customized web pages of the flow.	Do not create a security policy. The customized Oracle Fusion application task flow will already have a function security policy defined by the security reference implementation; because this type of change does not require new duties, there is no need to grant access to a new duty role.	Consult the security administrator who can make a customized task flow accessible to additional end users through role provisioning. If the same group of end users requires access to the customized task flow, then no change to the provisioned end users is required.
Control whether the end user associated with a particular role may access a new top-level web page. In Oracle Fusion Applications, a top-level web page is one that is not contained by a task flow.	Create a new security policy. The new top-level web page will be inaccessible by default (also called protected) and will require a new function security policy to grant end users access. The ability to secure individual web pages in Oracle Fusion Applications is reserved for top-level web pages backed by an ADF page definition file only.	Enable ADF Security on the user interface project to protect all top-level web pages backed by ADF page definition files. Then, in the file-based policy store, create a resource definition for the web page and assign the definition as a member of an entitlement (defined in the policy store as a permission set) that you name. Then, create the security policy by granting the entitlement to a custom application role that you either created or consulted with a security administrator to create for you. As a security guideline, do not modify a predefined function security policy by granting additional entitlements to a predefined duty role.
Control whether the end user associated with a particular role may access a customized top-level web page. In Oracle Fusion Applications, a top-level web page is one that is not contained by a task flow.	Do not create a security policy. The customized top-level web page will already have a function security policy defined by the security reference implementation; because this type of change does not require new duties, there is no need to grant access to a new duty role.	Consult the security administrator who can make customized top-level web pages accessible to additional end users through role provisioning. If the same group of end users requires access to the web page, then no change to the provisioned end users is required.
Decide whether the end user associated with a particular role has the right to select the create, edit, or delete button in the displayed web page.	Do not create a security policy. Access to user interface components, such as buttons, is not controlled by a security policy, but can be controlled by rendering the button in the user interface based on the end user's role.	Conditionally render the component by entering ADF Security Expression Language (EL) utility methods on the rendered attribute of the button to test whether the end user has membership in a particular role.
Control whether the end user associated with a particular role may view or update a specific set of data records for an all new business object in the displayed web page.	Create a new security policy. After an Oracle Fusion Data Security database resource is defined for the data, the data records exposed by the new business object will be inaccessible by default (also called protected) and will require a new data security policy to grant end users read or update access on one or more specific sets of data records.	Enable authorization checking on the appropriate operations of the ADF entity object (read, update, and removeCurrentRow) that maps to a specific database table. Then, in the Oracle Fusion Data Security repository, add a custom duty role as the grantee of access privileges and create a named instance set of data records. Then, create the security policy by granting Oracle Fusion Data Security view or update privileges to the custom duty role for the data records. As a security guideline, do not modify a predefined data security policy by granting additional privileges to a predefined duty role.
Control whether the end user associated with a particular role may view or update a new set of data records for an existing business object in the customized web page.	Create a new security policy. Although an existing Oracle Fusion business object will have an existing data security policy, you must not modify privileges granted to predefined duty roles (those defined by the security reference implementation) and you must instead grant privileges only to custom duty roles that they define.	In the Oracle Fusion Data Security repository, add a custom duty role as the grantee of access privileges and create a named instance set for the new data records. Then, create the security policy by granting Oracle Fusion Data Security view or update privileges to the custom duty role for the data records. As a security guideline, do not modify a predefined data security policy by granting additional privileges to a predefined duty role.
Control whether the end user associated with a particular role may view or update new sensitive data exposed on a new attribute of an existing business object in the customized web page. Sensitive data is defined as any personally identifiable information (PII) that is considered "public within the enterprise" (also called "internally public"). Internally public PII data is secured from access external to the enterprise.	Create a new security policy. Sensitive PII data exposed by a new attribute that is added to an existing Oracle Fusion application business object will be secured by the business object's data security policies and will require a new data security policy to grant end users read or update access on a specific column of data.	Column-level OPSS authorization checking is not supported for ADF entity objects. Instead create a custom OPSS permission to control access to the column read or update operation, and then, in the Oracle Fusion Data Security repository, map the operation to a custom privilege and grant the privilege to the custom duty roles for the sensitive data records. Last, conditionally render the attribute by testing whether the end user has the custom privilege either 1.) by entering an ADF Security Expression Language (EL) utility method using an EL expression on the user interface component that displays the attribute or 2.) by entering a Groovy expression on the ADF view object to which the user interface component is bound.
Control whether the end user associated with a particular role may view or update new confidential data exposed on a new business object that the customized web page displays. Confidential data is defined as any personally identifiable information (PII) that is considered "private within the enterprise." Exposure of such information outside the enterprise could result in harm, such as loss of business, benefit to a competitor, legal liability, or damaged reputation. Confidential PII data is secured from access external to the enterprise and is secured additionally to prevent access within the enterprise even by highly privileged end users (such as database administrators).	Create a new security policy. In Oracle Database, the Virtual Private Database (VPD) feature only supports securing a set of data records and therefore will require a new table in a custom schema that you create for Oracle Fusion Applications. The confidential PII data exposed by the new business object will be inaccessible by default (also called protected) and will require a new data security policy to grant end users read or update access on a specific set of data records.	Column-level policies are not supported by Virtual Private Database (VPD). Instead, the database administrator must create a new table in your custom schema for Oracle Fusion Applications, create a view for that table, and then define a VPD policy to filter the PII data records by associating a PL/SQL function with that view. Then, in the Oracle Fusion Data Security repository, create an action with the same name as the database view and create the security policy by granting Oracle Fusion Data Security view or update privileges to the custom duty role for the confidential data records. Last, in the data model project, enable OPSS authorization checking on the appropriate operations of the ADF entity object (read, update, and removeCurrentRow) that maps to the new PII database table.

15.3.4 Scenarios Related to Extending and Securing Data Model Components

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 protected database resource and FND_GRANTS that defines the access privileges for those database resources.

To protect the business object in the extended application, where it has been exposed as an ADF entity object, a database resource definition in the FND_OBJECTS table identifies 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. 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 privileges such as read, update, and delete privileges on specific sets of data records exposed by the business object.

Note:

When an ADF entity object exposes a business object that does not require security, then no database resource for that business object needs to be defined in the Oracle Fusion Data Security repository. For complete details about Oracle Fusion Data Security, see the "Implementing Oracle Fusion Data Security" chapter in the Oracle Fusion Applications Developer's Guide.

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 privileges because granting privileges to a predefined duty role would alter the segregation of duties defined by the security reference implementation.

Note:

Developers are not entitled to modify the role hierarchy defined by the Oracle Fusion Applications security reference implementation. Therefore, whenever you create a new duty role, you must consult the security administrator to assign the custom duty role to a job role or data role.

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 15-1. The scenarios for defining data security policies include the following.

When a new business object is introduced and it needs to be secured:

When you seek to secure additional data records in the extended application because a new ADF entity object is introduced, then an Oracle Fusion Data Security database resource must be defined to protect the data records and a new data security policy must be created to grant end users access to the data records exposed by the business object that the ADF entity object defines. The data records exposed by the business object will be unprotected (accessible to all end users) until a database resource identifying the business object is defined in the Oracle Fusion Data Security repository.

Note that the operations to be secured on the new business object will also require enabling OPSS authorization checking for those operations on the ADF entity object in the data model project, as described in Section 15.3.7, "What You Can Customize in the Data Model Project at Design Time."

When a new business object attribute is introduced and it maps to sensitive data:

When you modify an existing ADF entity object to include a new attribute that maps to data that not all end users need to view, then a new data security policy must be defined to grant end users access to the sensitive data. This is accomplished through a combination of a data security policy that grants a custom privilege and enforcement of the privilege in the application source.

Because Oracle Fusion Data Security does not support automatic enforcement of custom data security privileges, column-level security is not supported by default. You enforce the custom privilege in the application source by enabling OPSS authorization checking at the level of the user interface component or its databound ADF view object. Otherwise, without the custom data security privilege and custom privilege check, the data records (including the sensitive fields) exposed by the business object would be secured by the data security policy that already exists for the business object.

Important:

Oracle Fusion Data Security alone will not prevent sensitive data from being accessed by highly privileged end users, such as database administrators. If the data needs to be treated as internally private (confidential data), then consider implementing additional security using Virtual Private Database (VPD) policies. However, do not implement column-level VPD policies to protect sensitive data exposed by attributes, because security for attributes is not supported by VPD in Oracle Fusion Applications.

When a new business object attribute is introduced and it maps to confidential data:

When you create an ADF entity object that introduces data that is to be treated as confidential to the enterprise, then define row-level VPD policies to control access to PII data by privileged users, including database administrators. Implementing VPD policies requires saving the confidential information in a new table in a custom schema for Oracle Fusion Applications.

In this case, the database administrator first creates the database table and the VPD policy to secure the PII data records. The VPD policy the database administrator creates associates a policy function (a PL/SQL function) with a particular view or synonym definition in the database. The policy function filters the rows for any query made against the PII data. Finally, you can create the actual data security policies by granting to an action that has been created with same name as the database view where the policy is defined.

For information about creating tables in a custom schema for Oracle Fusion Applications, see Section 11.8, "Customizing and Extending the Oracle Fusion Applications Schemas."

For information about creating VPD policies, see the "Using Oracle Virtual Private Database to Control Data Access" chapter in the Oracle Database Security Guide.

When new operations or new data records are introduced from an already secured business object:

When you introduce new operations or additional data records exposed by an existing ADF entity object into the extended application, you must not modify the predefined data security policies or data role templates that already exist for that business object. Instead, create a new data security policy to grant end users access to the operations or data records that had previously remained protected.

Note that the operations to be secured on the business object may also require enabling OPSS authorization checking for those operations on the ADF entity object in the data model project, as described in Section 15.3.7, "What You Can Customize in the Data Model Project at Design Time."

When already exposed operations or data records need to be accessible to additional end users:

When you introduce functionality into the extended application that changes the access requirements of the operations and data records exposed by an existing business object, then those end users may be provisioned by existing job roles or data roles. Consult the security administrator to make the data accessible to additional end users through role provisioning. This type of customization does not require modifying the access privileges or the duty roles of an associated data security policy.

15.3.5 Scenarios Related to Extending and Securing User Interface Artifacts

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 privileges 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 privileges, 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 privileges.

Note:

For more information about how Oracle Platform Security Services implements function security, see the "Understanding Security Concepts" part in the Oracle Fusion Middleware Application Security Guide.

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 create 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 privileges because granting privileges to a predefined duty role would alter the segregation of duties defined by the security reference implementation.

Note:

Developers are not entitled to modify the role hierarchy defined by the Oracle Fusion Applications security reference implementation. Therefore, whenever you create a new duty role, you must consult the security administrator to assign the custom duty role to a job role.

Whether or not you will need to create 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 15-1. The scenarios for defining function security policies include the following.

When a new task flow or top-level web page is introduced:

When you expose new functionality in the extended application through a new ADF bounded task flow or top-level web page that you create, then a new function security policy must be created to grant end users access to the application artifact.

The new ADF bounded task flow and top-level web page are the only scenarios that require a new function security policy for the extended application.

When a new web page is introduced into an existing task flow:

When you modify an existing task flow to include new web pages, those web pages will be secured by the containing task flow's existing security policy. In this case, because all web pages contained by a bounded task flow are secured at the level of the task flow, there is no need to grant more function security privileges specifically for the new page. You will, however, need to create a new data security policy to grant end users access to any new data records that were introduced by the customization.

When a web page is modified to display a new field of sensitive data:

When you modify a web page to display sensitive data for a single data record field (for example, by adding a column to a table component to display salary information), access to the field displayed by the component cannot be controlled by a function security policy. Authorization checking is not implemented by OPSS at the level of ADF Faces user interface components in the web page. Instead, you enter ADF Security Expression Language (EL) utility methods on that part of the databound ADF Faces component responsible for rendering the field and test the end user's associated role.

Note that using EL expressions to conditionally render a portion of a user interface component does not control access to the actual data; truly sensitive data must be secured on the business object with a data security policy, as described in Section 15.3.4, "Scenarios Related to Extending and Securing Data Model Components."

When a web page is modified to display components that must not be viewable by all end users:

When you modify a web page to display components that not all end users need to view (for example, a button that deletes data records), access to the components cannot be controlled with a function security policy. Authorization checking is not implemented by OPSS at the level of ADF Faces user interface components in the web page. Instead, you enter ADF Security Expression Language (EL) utility methods on the rendered property of the ADF Faces component to hide or render the entire component based the end user's associated role.

Note that using EL expressions to conditionally render a user interface component does not control access to the actual data (if that component displays data). Truly sensitive data must be secured on the business object with a data security policy, as described in Section 15.3.4, "Scenarios Related to Extending and Securing Data Model Components."

When existing task flows or top-level web pages must be accessible by additional end users:

When you introduce functionality into the extended application that changes the access requirements of an existing bounded task flow or top-level web page, then consult the security administrator to make the resource accessible to additional end users through role provisioning. This type of customization does not require changing the access privileges associated with the resource or the duties it defines.

15.3.6 What You Can Customize in the Data Security Policy Store at Design Time

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 area of any Oracle Fusion Setup application.

Note:

After you select the Manage Data Security task in Oracle Fusion Functional Setup Manager, the environment redirects to the data security customization user interface provided by Oracle Authorization Policy Manager. In this guide, although the data security customization tool is identified as Oracle Authorization Policy Manager, be aware that the tool must be accessed through Oracle Fusion Functional Setup Manager.

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 create new data security policies using Oracle Authorization Policy Manager.

Important:

As an Oracle Fusion Applications security guideline, the privileges granted by predefined data security policies assigned to duty roles of the Oracle Fusion Applications security reference implementation must not be changed by customization developers. Always create new data security policies to confer additional access privileges. Details about the security reference implementation can be found in the Oracle Fusion Applications security reference manuals.

The data security policy consists of privileges conditionally granted to a role to control access to instance sets of the business object. A privilege 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 privileges 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.

  After the database resource is defined in the data security repository, Oracle Fusion Data Security protects the data records and operations exposed by the business object by default, and a data security policy must be defined to grant end users access to the business object.

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

  For more details about the roles used by Oracle Fusion Applications, see Section 15.2, "About Extending the Oracle Fusion Applications 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 privilege 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

Note:

The application developer does not enforce data security policies when creating the policies. In the case of data security, you must enable OPSS authorization checking on each business object that needs data security. This enforcement is implemented in JDeveloper, as described in Section 15.3.7, "What You Can Customize in the Data Model Project at Design Time."

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.

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

  A privilege 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 privilege can map a custom action to a custom operation on a condition of a business object. The custom privilege, 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 privilege also supports securing operations on columns through ADF Security Expression Language (EL) utility methods 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 Section 15.4, "Defining Data Security Policies on Custom Business Objects." For detailed documentation, see the "Managing Oracle Fusion Applications Data Security Policies" and "Oracle Fusion Applications Data Role Templates" chapters in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).

15.3.7 What You Can Customize in the Data Model Project at Design Time

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.

After you map the business object to an ADF entity object, enforcement of data security policies does not occur automatically on the data records of the exposed business object. The Oracle Fusion security approach protects the business object that has been registered as an Oracle Fusion Data Security database resource to ensure that end users do not have unintended access to sensitive data. In adherence to the security principle of protected by default, 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 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 privilege (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. 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 privilege. Whether or not the user interface displays the column is specified by testing that custom privilege 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 Section 15.5, "Enforcing Data Security in the Data Model Project." For detailed documentation, see the "Implementing Oracle Fusion Data Security" chapter in the Oracle Fusion Applications Developer's Guide.

15.3.8 What You Can Customize in the User Interface Project at Design Time

Before you create 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.

For details about creating bounded task flows and databound top-level web pages, see the "Introduction to Building Fusion Web Applications with Oracle ADF" chapter in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework (Oracle Fusion Applications Edition).

Although you can create function security policies for the custom resources of the user interface project, enforcement of function security does not occur automatically. The Oracle Fusion security approach protects securable Oracle ADF application resources to ensure that end users do not have unintended access. In adherence to the security principle of protected by default, 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.

Important:

After you run the ADF Security wizard, OPSS authorization checking is enforced on the bounded task flows and top-level pages. These application artifacts will be inaccessible when testing the application in JDeveloper. To enable access, you must create function security policies on the protected application artifacts, as described in Section 15.3.9, "What You Can Customize in the Application Security Policy Store at Design Time."

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 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 is allowed 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 the role membership of the end user to determine whether or not to render the navigation components that initiate the task flow.

For an overview of these tasks, see Section 15.6, "Defining Function Security Policies for the User Interface Project." For detailed documentation, see the "Implementing Function Security" chapter in the Oracle Fusion Applications Developer's Guide.

15.3.9 What You Can Customize in the Application Security Policy Store at Design Time

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 JDeveloper tools only to work on the exported file-based policy store, and do not edit the security definitions directly. JDeveloper supports iterative development of security so you can easily create, test, and edit security policies that you create 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.

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.

Note:

For details about implementing and testing security using JDeveloper, see the "Implementing Function Security" chapter in the Oracle Fusion Applications Developer's Guide.

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 privileges 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. Example 15-1 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.

Example 15-1 OPSS Entitlement-Based Policy Groups Permissions as a Set that May Be Granted to a Role

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

You use the security policy editor in JDeveloper to create the entitlement-based policy. JDeveloper modifies the source in the exported XML file. As Example 15-2 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)

Example 15-2 Entitlement-Based Security Policy Definition in jazn-data.xml File

<?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 privileges -->
          <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-policy></jazn-policy>
</jazn-data>

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.

Note:

Granting access to web pages in Oracle Fusion Applications is enforced at the level of ADF Controller components called bounded task flows. Task flows in Oracle Fusion Applications are ADF Controller components that assemble the application's web pages (or regions within a web page) into a workflow that supports the tasks to be performed by application end users. Defining security policies on task flows instead of individual web pages is a security best practice that blocks end users from directly accessing the pages of a task flow. Web pages that are not contained in a task flow are top-level pages and may have security policies defined individually.

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:

• Create 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.

• Create 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 only to authenticated end users (ones who visit the site and log in). For example, granting a view privilege 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 Section 15.6, "Defining Function Security Policies for the User Interface Project." For detailed documentation, see the "Implementing Function Security" chapter in the Oracle Fusion Applications Developer's Guide.

15.3.10 What You Cannot Do with Security Policies at Design Time

After you create 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.

  For information about how the security administrator merges the policies using Oracle Authorization Policy Manager, see the "Upgrading Oracle Fusion Applications Policies" chapter in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).

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

  For information about how the security administrator provisions enterprise users using Oracle Authorization Policy Manager, see the "Managing Policies and Policy Objects" chapter in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).

• 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. For information about how the security administrator reconciles GUIDs in a staging environment, see the "Securing Oracle Fusion Applications" chapter in the Oracle Fusion Applications Administrator's Guide.

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

  For more information, see the "Implementing Function Security" chapter in the Oracle Fusion Applications Developer's Guide.

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

  For information about how the security administrator migrates policies to a new environment, see the "Securing Oracle Fusion Applications" chapter in the Oracle Fusion Applications Administrator's Guide.

15.3.11 Before You Begin Customizing Security

Before you begin customizing security, you should be familiar with the Oracle Fusion application architecture that enables customization, as described in Chapter 1, "Customizing and Extending Oracle Fusion Applications." You should also understand the typical workflows for working with customizations, as described in Chapter 2, "Understanding the Customization Development Lifecycle."

You will need to do the following before you can begin customizing security:

1. Install JDeveloper and set up your development environment.

   For more information, see the "Setting Up Your Development Environment" chapter in the Oracle Fusion Applications Developer's Guide.

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 Chapter 10, "Using Oracle JDeveloper 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 Section 11.8, "Customizing and Extending the Oracle Fusion Applications 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, a view corresponding to the new table, and a VPD policy to associate a PL/SQL filter function with the view.

   The VPD policy filters the view to expose the data for which data security policies may be created. For information about creating the table in a custom schema, see Section 11.8, "Customizing and Extending the Oracle Fusion Applications Schemas." For information about creating VPD policies, see the "Using Oracle Virtual Private Database to Control Data Access" chapter in the Oracle Database Security Guide.

6. Obtain privileges to create 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 privileges. When you have the necessary privileges, 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 privileges 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 privileges to predefined duty roles.

   For information about creating application roles, see the "Managing Policies and Policy Objects" chapter in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).

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. For information about creating job roles, see the "Managing Roles" chapter in the Oracle Fusion Middleware User's Guide for Oracle Identity Manager.

9. Identify the 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 business components, see Chapter 11, "Customizing and Extending Oracle ADF 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 Chapter 11, "Customizing and Extending Oracle ADF 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 privileges necessary to access the resources they intend.

    For information about running the wizard, see the "Implementing Function Security" chapter in the Oracle Fusion Applications Developer's Guide.

15.4 Defining Data Security Policies on Custom Business Objects

In Oracle Authorization Policy Manager, the general process for defining a data security policy is as follows:

1. Register the custom business object as a database resource.

2. Define the instance set of data records that you want to associate with specific securable operations of the business component.

   An instance set in Oracle Fusion Data Security is a security artifact called a condition. The security policy identifies conditions from the security repository to specify the row instance set available to the end user provisioned to the role with the privilege to perform the intended business component operation.

   In Oracle Authorization Policy Manager, a condition you create defines an instance set of multiple rows specified either by simple filters (XML-defined) or complex SQL queries whose values can be parameterized. No condition definition is needed in the case of a single row instance or all the row instances of the database resource.

3. Define the list of actions that you want to be able to grant to the role.

   Action are database equivalent create, read, update, delete (CRUD) operations and correspond to the names of securable operations of the business object that the end user may invoke. The data security policy you define will associate one or more actions with an instance set.

4. If the custom business object is not supported by a data role template, define the data security policy:

   1. Enter a name and start date for the data security policy.

   2. Select one or more job roles or duty roles to which the policy grants access. The roles you select entitle all end users assigned to those roles with access to the data.

      In Oracle Authorization Policy Manager, duty role names that you enter are identified as OPSS internal roles called application roles. Similarly, job role names are identified as OPSS external roles called enterprise roles.

   3. Specify an instance set on the database resource for which the security policy will control access. This may be a single row, all rows, or multiple rows (specified by a previously defined named condition).

   4. Specify one or more actions to secure on the database resource for the currently specified instance set.

   5. Repeat the steps to grant actions access to additional instance sets for the current data security policy and roles.

      Figure 15-1 illustrates the Actions tab in the Edit Data Security page after several actions have been selected. Available actions will be limited to the actions that had been defined for the database resource.

      Figure 15-1 Creating a Data Security Policy - Selecting Actions

      
      

5. If the custom business object is supported by a data role template, then update the data role template with the following information:

   1. When the job role grantees of the data security policies generated by the template are not already defined by the existing data role template, add a new external role.

      The data role template specifies which base roles to combine with which dimension values for a set of data security policies.

   2. When the custom business object expresses a new data stripe to apply to the generated data security policies, modify the SQL code that identifies the dimension values of the template.

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

   3. When the data role grantee of the data security policies generated by the template are not already defined by the existing data role template, configure a new data role name.

      The data role template constrains the data roles with access privileges for specific data records with particular actions. The data role provides provisioned end users with privileges to access a dimensional subset of the data granted by a data security policy.

   4. Select the database resource that you registered for the custom business object.

   5. Optionally, select one or more data sets that you specified as named conditions when you created the database resource.

      Alternatively, the template can generate policies based on the primary key of the database resource.

   6. Specify one or more actions to secure on the database resource for the currently specified instance set.

Before you begin:

If you will be creating or editing Oracle Fusion Data Security security policies in Oracle Fusion Applications, you will need specific privileges. When you have the necessary privileges, 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.

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 privileges to predefined duty roles. For information about creating roles, see the "Managing Policies and Policy Objects" chapter in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).

Task: Creating Conditions on a Business Object

A business object can define securable instance sets of data records called conditions. The data security policy you create may identify a specific data record, all data records of the object, or multiple data records. When you want to secure specific sets of records, then conditions must be created on the business object. From the Administration menu in the global area of Oracle Fusion Applications, choose Setup and Maintenance, and then choose Manage Data Security Policies. After you register the business object as a database resource in the General Information tab, click the Conditions tab and click New. In the Create Database Resource Condition dialog, enter the SQL predicate consisting of a query on the table named by the database resource. For more information, see the "Managing Oracle Fusion Applications Data Security Policies" chapter in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).

Task: Granting Access for a Privilege to a Specific Role and Object Condition

A business object can define conditions that query only the set of data records that are relevant to the members of a particular enterprise role or application role (also called job roles or duty roles, respectively). You can secure these sets of data records by making grants on conditions of the business object for a particular application role and privilege that you define. Condition-level security lets you secure any number of subsets of the business instances defined by the business object. As an alternative to standard privileges, you can define a custom privilege to create a security policy for operations that may be specific to a particular group of end users. Custom privileges also let you enforce security in the data model project at the level of the ADF view object and perform authorization checking to secure individual business object attributes. From the Administration menu in the global area of Oracle Fusion Applications, choose Setup and Maintenance, and then choose Manage Data Security Policies. After you register the business object as a database resource (using the General Information, Conditions, and Actions tabs sequentially), click the Policies tab and click New. You then use the policy workflow at the bottom of the Edit Data Security page (Roles, Rule, and Action tabs sequentially) to create the data security policy. For more information, see the "Managing Oracle Fusion Applications Data Security Policies" chapter in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).

Task: Granting Access to a Specific Data Role and Dimension Values

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. From the Administration menu in the global area of Oracle Fusion Applications, choose Setup and Maintenance, and Manage Data Role Templates. In the data role template workflow, you use the tabbed pages (External Role, Dimension, Naming, and Policies tabs sequentially) to create a data role template or revise an existing one. For more information, see the "Oracle Fusion Applications Data Role Templates" chapter in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).

15.5 Enforcing Data Security in the Data Model Project

Data security policies secure data from business objects based on the grants made to roles. The business object participating in data security defines a database resource (a database table or view) that has been registered in the Oracle Fusion Applications FND_OBJECTS table. When you need to expose data records in the extended application, you can use JDeveloper and Oracle ADF to create a data model project with ADF entity objects based on secured database resources. However, it is not sufficient to register the business object in FND_OBJECTS and define data security policies. Additionally, you must opt into those data security policies by enabling row-level OPSS authorization checking for specific operations on ADF entity objects in the data model project.

By default, after the database table or view backing the ADF entity object has been registered as a database resource in the FND_OBJECTS table, Oracle Fusion Data Security denies end users access to the business object data. Enabling OPSS authorization checking for the operations (such as view, edit, delete) by setting metadata on the ADF entity object of the data model project, ensures that only end users with sufficient privileges are authorized to perform the actions on the database resources corresponding to the ADF entity object.

JDeveloper saves the security metadata that you define on the data model project into an Oracle Metadata Services (MDS) repository.

Before you begin:

If the ADF entity object does not appear in the data model project, then you cannot opt into data security policies that may exist for the business object. You must use JDeveloper to create the ADF entity object based on a database table or database view that you intend to register in the Oracle Fusion Data Security schema. For more information, see Chapter 11, "Customizing and Extending Oracle ADF Application Artifacts."

For OPSS to enforce security, the database table or view backing the ADF entity object must be registered as a business object with the FND_OBJECTS table provisioned by Oracle Fusion Data Security (the registered business object is also called a database resource of the Oracle Fusion Data Security schema). You must use Oracle Authorization Policy Manager to register the custom business object corresponding to the ADF entity object data source. For more information, see the "Managing Oracle Fusion Applications Data Security Policies" chapter in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).

Enabling security for custom operations in the data model project requires a custom privilege in the data security policy defined on the business object. You must create the custom privilege in the data security repository. For more information, see Section 15.4, "Defining Data Security Policies on Custom Business Objects."

Task: Enforcing Row Security for the Standard Operations of a Business Object

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. In JDeveloper, you display the ADF entity object in the overview editor and, in the editor, click the General navigation tab and expand the Security section, and then you select the list of standard operations for which you want to enforce authorization checking against data security policies. For more information, see the "Implementing Oracle Fusion Data Security" chapter in the Oracle Fusion Applications Developer's Guide.

Task: Enforcing Row Security for a Custom Operation of a Business Object

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 privileges in the data security policies defined on the business objects. The view criteria creates a row set filter by naming the custom privilege and business object. Filtering of the business object by view criteria works only with custom operations. In JDeveloper, you display the ADF view object in the overview editor and, in the editor, click the Query navigation tab. 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. For more information, see the "Implementing Oracle Fusion Data Security" chapter in the Oracle Fusion Applications Developer's Guide.

Task: Enforcing Security for Attributes of a Business Object

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 privilege and grant the privilege to specify the roles that are authorized to view or update the data records. Last, in the user interface, you enter an ADF Security Expression Language (EL) utility method to test that custom privilege using an EL expression on the user interface component displaying the attribute. For more information, see the "Implementing Oracle Fusion Data Security" chapter in the Oracle Fusion Applications Developer's Guide.

15.6 Defining Function Security Policies for the User Interface Project

You can use JDeveloper to define function security policies directly in an exported version of the Oracle Fusion application security repository. The security administrator exports the policies that exist in the LDAP-based application security policy store (residing in a test 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 test environment.

In JDeveloper, the general process for defining function security policies is as follows:

1. Consult a security administrator to export all predefined function security policies of the application that you are customizing into a jazn-data.xml file.

   For details about how the security administrator exports the application policy store, see the "Securing Oracle Fusion Applications" chapter in the Oracle Fusion Applications Administrator's Guide.

2. Copy the exported jazn-data.xml file into your application workspace.

   This is the file that JDeveloper will update when you create function security policies. For JDeveloper to use the file, copy the file to your application workspace in the <JDevAppHome>/src/META-INF folder.

3. Create an entitlement to group one or more custom resources and their corresponding actions that together entitle end users to access the resource when needed to complete a specific duty.

   In the Oracle Fusion Applications environment, the basic security artifact for entitlement-based security polices is the entitlement (an entitlement is defined as a OPSS permission set).

4. Grant the entitlement to a custom duty role that was added to the Oracle Fusion application policy store.

   The entitlement grant to the role specifies that the end user must be a member of the role to access the resources specified by the entitlement. You must use custom duty roles and you must not grant entitlements to predefined duty roles.

   In JDeveloper, duty role names that you select are identified as OPSS internal roles called application roles.

5. Enable ADF Security for the application by running the Configure ADF Security wizard.

   The wizard configures files that integrate ADF Security with OPSS on Integrated WebLogic Server.

   After you run the ADF Security wizard, any web page associated with an ADF bounded task flow will be protected. Therefore before you can run the application and test security, you must define the security policies that grant end users access.

Before you begin:

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 more information about how the security administrator exports the application policy store, see the "Securing Oracle Fusion Applications" chapter in the Oracle Fusion Applications 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 Chapter 11, "Customizing and Extending Oracle ADF 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 privileges to predefined duty roles. For information about creating duty roles, see the "Managing Policies and Policy Objects" chapter in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).

Task: Defining Entitlement Grants for a Specific Application Role

An entitlement grant is a set of resource grants (set of OPSS permissions) that will be required by the end user to complete a task. Each permission in the entitlement grant names an OPSS permission class, a resource, and an action. Entitlements must be granted to custom application roles. In JDeveloper, you choose Application then Security and then Entitlement Grants. Then you name the entitlement, add member resources, and add the actions that you want to secure. Grant the entitlement to a custom application role. For more information, see the "Implementing Function Security" chapter in the Oracle Fusion Applications Developer's Guide.

Task: Defining Resource Grants for the Authenticated User Role

A resource grant sets an OPSS permission on a single application resource and grants that permission to an application role. In JDeveloper, to make the resource publicly accessible, choose Application then Security and then Resource Grants. Select the Oracle ADF artifact, the built-in OPSS role authenticated-role (or anonymous-role) as the grantee, and the action that you want to make public. For more information, see the "Implementing Function Security" chapter in the Oracle Fusion Applications Developer's Guide.