Browser version scriptSkip Headers

Oracle® Fusion Applications Security Guide
11g Release 5 (11.1.5)
Part Number E16689-05
Go to contents  page
Contents
Go to Feedback page
Contact
Us

Go to previous page
Previous
Go to previous page
Next

5 Function Security

This chapter contains the following:

Function Security: Explained

Securing Functions: Points to Consider

FAQs for Role Based Access Control

Function Security: Explained

Function security consists of privileges unconditionally granted to a role and used to control access to a page or a specific widget or functionality within a page, including services, screens, and flows, and typically used in control of the main menu. Function security involves granting a user, by means of the user's membership in a role, the ability to perform operations in pages or task flows such as view or manage.

Function Security Policies

A function security policy consists of privileges assigned to duty roles and those duty roles assigned to a job or abstract role. Function security policies are defined in the Authorization Policy Manager (APM).

Implementation

Function security is implemented using JAAS (Java Authentication and Authorization Services) permissions representing an Application Development Framework (ADF) artifact. These permissions are stored in the Oracle Platform Security Services (OPSS) policy store and are checked by Application Development Framework (ADF) at runtime.

When a user accesses the functions of a task flow, the OPSS policy store determines the access entitlement that applies to that user through the roles provisioned to the user.

Securing Functions: Points to Consider

The functions that a user can access via roles are interface elements, such as the pages or widgets of a task flow.

Functions are organized separately from menu navigation and access to functions is granted to users via roles. Policies comprised of grants with access entitlement to components are stored in the policy store, and application roles within role hierarchies are defined with access rights through policies. The access entitlement to a component consists of allowable actions, or privilege, on the component.

Users of Oracle Fusion Applications must be able to access the functions necessary for performing their jobs and be excluded from functions that are irrelevant or improper to their roles in the enterprise. This may require changes to the roles available for provisioning.

For the broadest possible access to the functionality in Oracle Fusion Applications, the role to which broad entitlement is granted would be a role high in the role hierarchy, such as worker. Such broad entitlement should not include access rights to any functions that violate the security policies of the enterprise, but allow performance of all duties associated with the role.

Job Role Changes

A job role is constructed by identifying each of the duty roles and abstract roles it inherits. In Oracle Identity Manager (OIM) and Applications Authorization Policy Manager (APM), job roles are external roles and duty roles are application roles.

No function security privileges can be assigned directly to a job role. Job roles may inherit other job roles, abstract and duty roles. Data security policies using either job or duty roles may reference data entitlement. The reference within the data security policy to a duty role is a security guideline because it allows more flexibility in asserting exactly what any given job means.

Most job role changes are created by implementing role hierarchies of the predefined Oracle Fusion Applications roles in ways that fulfill the needs of your enterprise.

Create a new job role by creating a new group in the Lightweight Directory Access Protocol (LDAP) Store and mapping the duties to the group in the role hierarchy.

Duty Role Changes

Duty roles are one of the building blocks of Oracle Fusion Applications security.

Duty roles may carry both function and data security grants. As a security guideline, make duty roles self-contained and pluggable into any existing or new job or abstract role to avoid introducing definition conflicts in the owning application.

New duty roles may be required with extensions for Oracle Fusion Applications. All predefined Oracle Fusion Applications functions that need to be secured correspond to a duty role. A duty role should carry no segregation of duties risk within it.

Data Role Changes

A data role carries the function security entitlement inherited from the role hierarchies and data security entitlement conditionally granted on each object and condition.

Implementation consultants typically define data roles required by the data requirements of the enterprise. Commonly data roles limit access for control and performance reasons within tools, applications, or areas of a deployment such as department or cost centers.

Role Incompatibilities

Role incompatibility can occur in function control, as well as in segregation of duties.

FAQs for Role Based Access Control

What's the difference between an enterprise role and an application role?

Enterprise roles are the abstract, job, and data roles shared across all applications. Enterprise roles and role memberships are stored in the Lightweight Directory Access Protocol (LDAP) identity store. Oracle Identity Manager (OIM) and Applications Authorization Policy Manager (APM) refer to enterprise roles as external roles.

An application role is supplied by a single application or pillar of applications. Application roles are stored in the policy store.

Users acquire application function and data access by being granted membership to an enterprise role.

In the security reference implementation, an application role corresponds to a duty role. Users acquire duty role privileges by being provisioned with the parent job or abstract roles of the duty role. Security policies in the policy stores (LDAP and Oracle Fusion Data Security) define which functions and data the duty role is authorized to access.

Both enterprise and application roles participate in security policies.