Overview of the ADF security model

The following diagram shows the different artifacts which are used to specify the access rights in an Oracle ADF application. This is basically a high level view on the data stored in the src/META-INF/jazn-data.xml file:

Essentially, there are two separate areas involved, the Enterprise Scope and the Application Scope.

Application Scope

In the Application Scope, the Developer of the ADF application specifies the policies which are specific to the application. The policies define which Actions are permitted on which Resources of the ADF application. Resources are Web pages, Task flows or other artifacts which are used to build the application. Actions can be customize, grant, personalize and view.

Actions are granted on Resources either through Resource Grants (where each resource grant refers to one specific resource) or through Entitlement Grants (where each Entitlement Grant can group more than one resource of possibly different types). Using Entitlement Grants has the advantage that all Resources which belong to a specific task (for example, all task flows and the main web page which references the task flows) can be grouped – otherwise, a separate resource grant would be necessary for each resource.

Note that, when editing the jazn-data.xml file  in JDeveloper, Entitlement Grants are still visible (but not editable) in the Resource Grants tab as separate entries.

The grants are assigned to Application Roles which essentially make up the interface to the application specific security definition. Once installed, the Administrator can map the Application Roles to Enterprise Roles (see below). Application Roles are hierarchical, so that one Application Role can inherit the grants from other Application Roles. Application Roles can also be grouped into Role Categories – Role Categories are a flat list of Application Roles to group similar Application Roles.

Enterprise Scope

In the Enterprise Scope, the Administrator of the application defines the Users and Enterprise Roles (sometimes also called “Groups“) which are specific to the enterprise where the application is deployed. Most likely, a user and group structure already exists when a new ADF application is deployed, so the primary task for the administrator is to map the existing Enterprise Roles to the Application Roles of the application, so that users can access the application.

As a developer, during development of the application, it is also necessary to define a (probably small) set of Users and Enterprise Roles, so that it is possible to test the application. However, when the application is deployed, only the application related definitions are packed into the .ear file (obviously, the developer can not foresee which users exist at the sites where the application is installed).

Fusion Applications Role Based Access

In Oracle Fusion Applications, there are additional role types defined. An Enterprise Role can be either an Abstract Role, a Job role or a Data role. An Application Role is called a Duty role. This is usually reflected in the name of the roles – job roles have a _JOB suffix, and duty roles have a _DUTY suffix. See the Oracle Fusion Applications Security Guide for more information.