An Oracle White Paper

March 2013

Function Security and Role-Based Access

Control (RBAC) in Oracle E-Business
Suite
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

Introduction ....................................................................................... 1
Terminology....................................................................................... 2
Responsibility-based Security ............................................................ 2
Functions in Responsibility-based Security .................................... 2
Menus ........................................................................................... 3
Responsibilities ............................................................................. 4
Role-Based Access Control (RBAC) .................................................. 5
Functions and Permissions in RBAC ............................................. 5
Permission Set .............................................................................. 6
Roles ............................................................................................. 7
Grants ......................................................................................... 13
Roles and Responsibilities ........................................................... 14
Using RBAC to Provide Different Authorization for Different Users .. 15
Role Hierarchy and Role Inheritance ........................................... 15
Using Role Hierarchies to Simplify User Administration ............... 17
Best Practices for Using RBAC with Function Security .................... 19
Best Practice: Optimize granularity of roles ................................. 19
Best Practice: Separate navigation from authorization ................. 20
Best Practice: Use appropriate pages or forms for setup ............. 20
Best Practice: Avoid modification of shipped objects ................... 20
Best Practice: Use delegated administration................................ 21
Conclusion ...................................................................................... 21
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

Introduction

There are two main ways to implement security in Oracle E-Business Suite: “traditional” Oracle
E-Business Suite responsibility-based security (usually referred to as “function security”) and
Role-Based Access Control (RBAC). Since they overlap in functionality, and RBAC
incorporates and builds upon responsibility-based security, there is often confusion about how
the two security models coexist and interact. This paper discusses the main similarities and
differences between the two types of security setups, as well as the objects involved.

1
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

Terminology

Page, Form, Screen, Window

In Oracle E-Business Suite, we often use these terms interchangeably, but in some cases we use the
word “page” to refer to an HTML-based or JSP-based application page, “form” to refer to an Oracle
Forms-based form, and “screen” or “window” to refer to either.

Navigation

For the purposes of this paper, navigation is the ability to move to a page or form in an application by
selecting a menu option from the Oracle E-Business Suite Home page or the Navigator, a Favorites
link, a tab or sub-tab on a dashboard, and so on.

Authorization

Authorization means users have the application privileges that allow them to use the functionality of a
page or form. If users cannot navigate to a screen at all, they are implicitly not authorized to use that
functionality. If users can navigate to the screen, they may or may not be authorized to use the
functionality on that screen.

Grant

A grant is an authorization to do some specific operation.

Responsibility-based Security
Responsibility-based security is usually referred to as “function security”. We will start with the basic
concepts in function security. Later in the paper we will discuss how those concepts differ and are
included under RBAC.

Functions in Responsibility-based Security

In the simplest terms, a function is a named piece of application functionality, such as a page, and a
permission is a named authorization to use that piece of functionality. A function is the smallest unit of
securable product functionality. Functions also represent actions that can be performed on an object or
on the system in general. A function is registered under a unique name for the purpose of assigning it
to a menu, calling it from somewhere in the application, or excluding it from a responsibility.

2
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

Function A Permission A

Figure 1. Function and Permission

Before RBAC was introduced in Oracle E-Business Suite, the concepts of navigation and authorization
were not explicitly separated, and function security did not include the term “permission” (or
authorization) as a separate concept. Instead, function security included two types of functions:
 Executable functions (originally called “form functions”)
 Non-executable functions (also called “abstract functions” and originally called “subfunctions”).
An executable function can be invoked from a generic navigator user interface (the general case of the
Home page or Navigator). Executable functions include navigation; that is, you can navigate to a page,
JSP, form, and so on. An executable function definition must contain all information necessary to
launch the function; often this includes the form name or a URL plus parameters.
A non-executable function represents a securable subset of a page or form's functionality. These
abstract functions provide a mechanism for controlling both the navigation access and authorization to
part of a page or form. Typically an abstract or non-executable function is defined as just a name in
the system, and then the function is assigned to a menu or permission set. The code that implements
an abstract function then calls the function security system to test whether the abstract function is on
the menu (granted). The system only allows the action if the function is granted.
Non-executable functions are not accessed through navigation controls such as a menu option, though
you may see visible effects such as hiding or showing a button that gives you direct access to another
screen. For example, you might be able to navigate to an Orders page (executable function), but you
may not see the Update button or be able to update the order within that page (non-executable
function).

Menus
A menu is a group of functions that are arranged in a hierarchical structure with submenus, prompts,
and so on. In early versions of Oracle E-Business Suite, before RBAC was introduced, menus attached
to responsibilities provided users with a two different things: a navigation path with prompts to get to
a particular piece of functionality, such as a form or page, and the authorization (or permission) to use
that piece of functionality. These two parts, navigation and authorization, were not separated. If a page
was on your menu, then you could navigate to the page, and you automatically had the authorization to
use the page.

3
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

Menu Grant
(Navigation) (Authorization)
Function
A þ
Function
B þ
Function
C þ
Function
D þ

Figure 2. Functions and Grant check box in menus

With the introduction of RBAC, that dual purpose of a menu has been explicitly split into its two parts.
Now when you create a menu, you first add functions to the menu with a prompt (the navigation part),
and you must then decide whether to check the Grant check box (the authorization part) for each
function on the menu.
If you are using “traditional” Oracle E-Business Suite responsibility-based security, you check the
check box for each function to explicitly grant the authorization to the function using the Menu form
(or the corresponding Menu page in the Function Administrator responsibility).
Historical note: When RBAC was introduced in Oracle E-Business Suite Release 11.5.10, all
existing function security menus were automatically upgraded to have the Grant check box
checked for backwards compatibility.

Responsibilities
A responsibility is a level of authority in Oracle E-Business Suite. It enables your access to those
functions and data appropriate for your enterprise role. Each user has one or more responsibilities,
and multiple users can share the same responsibility. A responsibility also provides a context in which a
user operates. This context can include profile option values, available concurrent programs, and so on.
One of the main purposes of a responsibility is to provide access to a menu of functions. For the
simplest case of responsibility-based security, a menu is attached to a responsibility, and then a
responsibility is assigned to a user. At that point, the user has access to all of the functions attached to
the menu through the responsibility. Note that if the Grant check box is not checked for a particular
function, the user cannot access that function.

4
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

Function Security (Responsibility)

User

Responsibility

Menu Grant
(Navigation) (Authorization)
Function
A þ
Function
B þ
Function
C þ
Function
D þ

Figure 3. Responsibility including navigation menu with grant check box checked

For those applications where RBAC has not been implemented, setting up functions, menus with the
Grant check box checked, responsibilities, and users is sufficient to set up responsibility-based security
for the application.

Role-Based Access Control (RBAC)

For the most part, RBAC includes the same concepts as function security, though some of the names
are different and the definitions of the concepts are broader and more generic in RBAC than in
function security.
RBAC has occasionally been referred to as the “grants security system” or the “grants model”.
Note: RBAC includes both function security and data security. Data security is beyond the scope of
this paper.

Functions and Permissions in RBAC

With the introduction of RBAC, we now explicitly use the term “permission” for the authorization
component of a function. A user must have a function on a menu for navigation AND have an
explicit permission to use the function. In the case of a function on a menu with the Grant check box
checked, the check mark is the explicit permission. In the case of a function on a menu where the
Grant check box is NOT checked, we have the navigation component but not the permission. For

5
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

that permission, we use a separate permission component that is assigned through a separate grant (not
the Grant check box).
A permission in RBAC is implemented in Oracle E-Business Suite as simply a name in the system
without any prompt or execution information attached to it, and code within the page or other
executable checks to see if that permission is granted for the user.

Grant

Permission Set
Menu Grant (Authorization)
(Navigation) (Authorization)

Function Permission
A o A

Function Permission
B o B

Function Permission
C o C

Function Permission
D o D

Figure 4. Menu for navigation and separate permissions for authorization

For backwards compatibility, existing function names can also be used as “permissions”. Abstract or
non-executable functions (subfunctions) are already simply names defined in the system, and they
already behave as permissions (authorization to use a specific piece of functionality). The names of
executable functions can also be used as permissions when added to a permission set and assigned
through a grant. For an executable function, any prompt and execution information (such as HTML
Call) is ignored when the function definition is used as a permission. Because of this backwards
compatibility, we often use the terms “function” and “permission” interchangeably in Oracle E-
Business Suite.
In the diagrams in this paper, we show “functions” as components of menus for navigation and
“permissions” as components of permission sets for authorization, but functions defined using the
Functions form or page can be used for either. Permissions defined using the Permissions page do not
contain execution information such as URLs, so they can only be used as non-executable functions
(subfunctions) or as permissions.

Permission Set
A permission set provides authorization to use a group of functions/permissions. A permission set is
similar to a menu, except that it does not provide navigation information such as submenus or
prompts. Generally a permission set is simply a named flat list of permissions/functions. Because a
menu is also a list of functions, it can also be used as a permission set. The navigation information

6
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

such as prompts and navigation hierarchy that the menu contains is ignored when the menu is used as
a permission set. The Grant check box is also ignored when a menu is used as a permission set.
A permission set defined using the Permission Set page cannot be used as a menu because it does not
contain navigation information. As with functions and permissions, Oracle User Management keeps
menus and permission sets separate in the Functional Administrator and Functional Developer
responsibilities, and you cannot query one in the page for the other. However, permission sets defined
in the Permission Sets page can be queried in the Menus form in the Application Developer
responsibility, where they appear with the “Permission Set” menu type.
Because of the Grant check box on the Menu form, a navigation menu with the Grant check box
unchecked for all functions, plus a separate permission set with the same functions, provides
equivalent behavior to a function security menu where Grant is checked for all functions.
Grant

Permission Set
Menu Grant or Menu
(Navigation)
Menu Grant
(Authorization) (Authorization)
(Navigation) (Authorization)
Function Permission
A o A
Function
A þ
Function Permission
B o B
Function
B þ
Function Permission
C o C
Function
C þ
Function Permission
D o D
Function
D þ

Figure 5. Equivalence of Grant check box to permissions

In the picture above, the permission set is attached to a named grant to provide authorization to use
those functions.

Roles
In general, a role is a job function within the context of an organization or enterprise. An individual
can have one or more roles. For example, a person could be a “Manager” as well as an “Employee” in
a company. Within Oracle E-Business Suite, a role is also a particular object that provides users with
access to and authorization for specific functionality.
Both roles and responsibilities provide users with access to specific functionality, but they have some
important differences. First of all, a role treats the authorization component of access differently than
a responsibility does: authorization in a role can be included either as grants on the menu itself or as a
separate grant to a permission set. Navigation paths in both cases are provided through a menu
attached to a responsibility, which may in turn be assigned to a role. Secondly, users see and choose
from a list of responsibility names in the Home page after logging in, unless users only have a single
assigned responsibility. No role name appears in the end user’s view of the applications. Other
important differences between a role and a responsibility are hierarchy and inheritance.

7
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

Roles and Navigation

A role explicitly requires both a navigation component (responsibility with attached menu) and an
authorization component (permission set or grants in the menu) to provide access to application
functionality. For a role to allow navigation to a function, you must have a responsibility attached to
the role, because the menu attached to the responsibility is the only way to provide the navigation path.
For the very simplest case, you can create a role and then assign an existing responsibility to the role.
The menu attached to the responsibility must already have the Grant check box checked for all
functions so the authorization component is available as part of the menu attached to the
responsibility.

User

Role

Responsibility

Menu Grant
(Navigation) (Authorization)
Function
A þ
Function
B þ
Function
C þ
Function
D þ

Figure 6. Simplest RBAC setup has responsibility assigned to role

Another option is creating the menu without the Grant check box checked and adding it to a
responsibility, and then creating a permission set, creating a grant to the permission set, and then
assigning both the responsibility and the grant to the role. The role can then be assigned to a user.

8
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

Role-Based Access Control (RBAC)

User

Role

Responsibility Grant

Menu Grant Permission Set

(Navigation) (Authorization) (Authorization)
Function Permission
A o A

Function Permission
B o B

Function Permission
C o C

Function Permission
D o D

Figure 7. Role with grant to a separate permission set

Note that to the end user, the result of the previous two setups would be the same. Similarly, as shown
in the following diagram, an end user would see the same behavior with either RBAC or responsibility-
based security. In this diagram, the navigation menu structure is the same, but authorization is granted
differently: either through a permission set or through the menu.

9
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

Role-Based Access Control (RBAC) Function Security (Responsibility)

User User

Role

Responsibility Grant Responsibility

Menu Grant Flag Permission Set

(Navigation)
Menu Grant Flag
(Authorization) (Authorization)
(Navigation) (Authorization)
Function Permission
A o A
Function
A þ
Function Permission
B o B
Function
B þ
Function Permission
C o C
Function
C þ
Function Permission
D o D
Function
D þ

Function Function Function Function Function Function Function Function

A Tab B Tab C Tab D Tab A Tab B Tab C Tab D Tab
The end user sees
the same result
Application Page A Application Page A
with either setup

Figure 8. Equivalent RBAC and Function Security setups and results

Note that you can have various combinations of authorization granted either through a permission set
or through the Grant check box on the menu, as shown in the following diagram:

10
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

Role-Based Access Control (RBAC) Role-Based Access Control (RBAC)

User User

Role Role

Responsibility Grant Responsibility Grant

Menu Grant Permission Set Menu Grant Permission Set

(Navigation) (Authorization) (Authorization) (Navigation) (Authorization) (Authorization)

Function Permission Function Permission

A o A A o A

Function Permission Function

B o B B þ
Function Permission Function Permission
C o C C o C

Function Permission Function Permission

D o D D o D

Figure 9. Mixed grants on menu and permission set

For simplicity and ease of maintenance, we recommend that you do not mix checked and unchecked
Grant check boxes as shown in the picture above, however. If you are using permission sets separate
from navigation menus, have all the grants come from the permission set instead of having some
grants come from the Grant check box.
Simply adding a role layer between a user and a responsibility adds complexity without providing any
real benefit. RBAC becomes more useful when you create roles that have multiple responsibilities or
roles attached to them. You can then set up a user’s navigation and authorization for multiple
responsibilities by assigning the single role to the user, rather than assigning the responsibilities
separately. For example, creating and assigning a single role called Sales that contains a responsibility
for an employee plus a responsibility for someone doing sales reduces the effort of making sure each
salesperson gets the correct responsibilities.

11
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

Simplest Useful RBAC Setup

User

Role

Responsibility 1 Responsibility 2

Menu Grant Menu Grant

(Navigation) (Authorization) (Navigation) (Authorization)
Function Function
A þ E þ
Function Function
B þ F þ
Function Function
C þ G þ
Function
D þ Function
H þ

Figure 10. Simplest useful RBAC setup: role containing multiple responsibilities

Here is the same setup showing an Employee responsibility with employee-specific functions and a
Sales responsibility with sales-specific functions. The two responsibilities are then combined to make
up a Sales role, which inherits the functions from both responsibilities.

12
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

Simple Useful RBAC Setup: Sales Role

User

Role (Sales)

Responsibility 1 (Employee) Responsibility 2 (Sales)

Menu Grant Menu Grant

(Navigation) (Authorization) (Navigation) (Authorization)
Function A Function E
(Check Payslip) þ (Create Quote) þ
Function B Function F
(Enter Timecard) þ (Enter Customer) þ
Function C Function G
(Update Address) þ (Enter Order) þ
Function D
(Request Vacation) þ Function H
(Request Approval) þ

Figure 11. Sales role made up of Employee and Sales responsibilities

Roles and Grants

Roles do not necessarily need to contain navigation information (a responsibility) at all. Roles may be
defined as simply as just a role name, where code somewhere in the application checks to see that the
user has the role assigned and then behaves accordingly. Similarly, a role might contain grants but not
have any assigned responsibilities. Typically roles without navigation components are used as part of
role hierarchies to fine-tune privileges given to users.

Grants
Grants in RBAC tie other objects together: grantees (usually roles that are then assigned to users),
permission sets, often for a particular context when the grant applies.
Grants must have at least a permission set assigned to them, and grants must be assigned to a grantee
(a role, a single user, or “all users”). Grants often also include optional data security objects.
Note: data security and data security objects are beyond the scope of this paper. For information
about data security, see Oracle® E-Business Suite System Administrator's Guide – Security, Release 12.1, Part
No. E12843-05.

13
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

Grants

Grantee (Role,
User, All Users)

Responsibility Grant

Menu Grant Permission Set Data Security

(Navigation) (Authorization) (Authorization) Object
Function Permission
A o A

Function Permission
B o B

Function Permission
C o C

Function Permission
D o D

Figure 12. A grant includes assignments to a grantee, a permission set, and optionally a data security object

A grant can and must be assigned to exactly one grantee (role/user/all users). You cannot use the same
grant for more than one grantee (for example, you could not use the same named grant for both the
SYSADMIN user and the “Administrator” role). You can assign the grant to a role and then assign
that role to as many users as needed, however.
Grants in RBAC are usually named objects so they are easier to maintain. In RBAC, a grant can be
applied under certain context conditions (for a certain responsibility or operating unit, for example).
Any permission granted anywhere in the role structure affects the entire structure, unless a specific
context is specified to limit when the grant is applied. For responsibility-based security with the Grant
check box on a menu, the granted permission always applies regardless of user context.

Roles and Responsibilities

Responsibilities are different from roles in that only responsibilities can contain navigation information
(through menus). On the other hand, only roles can have grants assigned to them, though non-
executable functions on a navigation menu can perform like grants for a responsibility. Only roles can
contain data security information (through grants).

14
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

Both roles and responsibilities can be arranged hierarchically, and the behavior for the end user is
similar. If you add a role under a responsibility, you must set up a grant for that role that specifies the
responsibility name in the security context for the grant to be sure that the effects of the grant only
appear while the user is in that responsibility.

Using RBAC to Provide Different Authorization for Different Users

RBAC allows you to set up a single navigation structure and selectively grant authorization to its
functions. For example, you might want to have one role where a salesperson can view sales orders,
but not approve them, while another role allows the sales manager to view and approve sales orders.
As shown in the following diagram, this is accomplished by using different grants and permission sets
with the same responsibility, which has a menu where the Grant check box is unchecked for all
functions.

User 1 (Salesperson) User 2 (Sales Manager)

Role 1 (Sales) Role 2 (Sales Manager)

Grant 1 Grant 2
Responsibility (Sales) Responsibility (Sales)
(View) (View, Approve)

Menu Grant Permission Set 1 Menu Grant Permission Set 2

(Navigation) (Authorization) (Authorization) (Navigation) (Authorization) (Authorization)
Function Permission A Function Permission A
A o (View Quote) A o (View Quote)

Function Permission B Function Permission B

B o (View Order) B o (View Order)

Function Function Permission C

C o C o (Approve Quote)

Function Function Permission D

D o D o (Approve Order)

Function Function Function Function Function Function

A Tab B Tab A Tab B Tab C Tab D Tab
End users see
Application Page A
only functions they are Application Page A
authorized to use

Figure 13. Using different permission sets with the same responsibility

Role Hierarchy and Role Inheritance

Role-based access control in Oracle E-Business Suite is based on standard security concepts, and one
of those standards is that roles can be hierarchical. That is, a role can belong to another role. Further,
roles are inherited as you move upwards in the role structure. For example, you might have an
employee role, a sales role, a manager role, and a sales manager role. The employee role is attached

15
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

both to the sales role and the manager role, because every salesperson and every manager is also an
employee. The sales manager role has both the sales role and the manager role attached to it. The
sales manager role inherits the employee role from both the salesperson and the manager roles, so the
employee role does not need to be attached directly to the sales manager role.

User (Sales Manager)

User (Salesperson) Role 4 (Sales Manager) User (Manager)

Role 3 (Sales) Role 1 inherited Role 2 (Manager)

by Role 4

User (Employee)

Role 1 (Employee)

Figure 14. Roles higher in the role structure inherit roles lower in the structure

If you look at the role hierarchy in the Roles page user interface, the hierarchy looks like this:

Role 4 (Sales Manager)

Role 2 (Manager)

Role 1 (Employee)

Role 3 (Sales)

Role 1 (Employee)

Figure 15. Role hierarchy as it appears in Roles page user interface

16
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

This view of the hierarchy shows that the sales manager role inherits the employee role through both
the sales role and the manager role.
If each of the four roles in our example has a corresponding responsibility, then the sales manager role
would have four responsibilities: employee (inherited), sales, manager, and sales manager. Note that
even if responsibilities are duplicated within the role structure, a user sees only one of each
responsibility name in the Oracle E-Business Suite home page.
All the privileges associated with a role, such as responsibilities, permission sets, and grants, are
inherited as part of the role.

Using Role Hierarchies to Simplify User Administration

You can use role hierarchies to group together multiple responsibilities, multiple roles, or combinations
of roles and responsibilities. Either roles or responsibilities can be assigned directly to users, and either
roles or responsibilities can be added as nodes below other roles or responsibilities. The lower-level
roles and responsibilities attached to other roles and responsibilities are then inherited by any user who
is assigned the top-level role. The following diagram shows some possible arrangements of roles and
responsibilities, with and without separate grants.

17
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

User 1 (Salesperson)

Role 1 (Sales)

Responsibility Grant 1

Menu Permission Set Data Security

Role 2 Role 3

Responsibility Grant 2 Responsibility Responsibility Responsibility

Menu Permission Set Menu Menu Menu

Figure 16. Assigning a role hierarchy to a user

Setting up role structures can simplify the administration of users. In the diagram above, Role 1 (Sales)
is assigned directly to User 1, while Role 2 and Role 3 are assigned indirectly (inherited) by assigning
Role 1; they need not be assigned directly.
Now suppose User 2 (Sales Manager) should have all the same navigation menus and roles as User 1
(Salesperson), but User 2 should have access to additional functions on the menu in Role 1 but not
authorized by Grant 1. Role 4 (Approve Orders) can be assigned to User 2 to provide additional
authorization to functions in the menu under Role 1. Note that Role 4 does not contain any
navigation components; it only provides authorization for other components in the role structure.
This can be useful for fine-tuning authorization. For example, the salesperson can see but not approve
sales orders, but the sales manager has additional authorization to approve orders.

18
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

User 2 (Sales Manager)

Role 1 (Sales) Role 4 (Approve Orders)

Responsibility Grant 1 Grant 4

Menu Permission Set Data Security Permission Set Data Security

Role 2 Role 3

Responsibility Grant 2 Responsibility Responsibility Responsibility

Menu Permission Set Menu Menu Menu

Figure 17. Assigning an additional role to a user

Best Practices for Using RBAC with Function Security

Here are some best practices for implementing RBAC at your site.

Best Practice: Optimize granularity of roles

Some Oracle E-Business Suite applications have shipped menus with the Grant check box unchecked
along with seeded roles, permissions, and permission sets. These applications are often called “RBAC-
enabled”. However, even if a particular application is not already “RBAC-enabled”, you can combine
responsibilities under roles and use the roles to set up users easily.
Decide on what business roles your users will have. If all users will have certain functions, create one
role with those functions. You can then assign that role to other more specialized roles (Sales,
Development, or Management, for example).
Do not create a separate role for each function (that is, do not create roles with one permission per
permission set). Besides being extremely tedious to set up and maintain, this fully-expanded type of
role structure can adversely affect application performance.

19
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

Best Practice: Separate navigation from authorization

In general, you should grant authorization to a function in a separate permission set instead of by
checking the Grant check box in the navigation menu. If you are using “pure” RBAC, ideally none of
the functions on the menus will have the Grant check box checked.
Separating the permissions from the navigation allows you to provide selective authorization to
different users without disturbing the navigation paths and authorization for all responsibilities that use
the same menu. The permission set could be based on the same menu that is assigned to the
responsibility as a navigation menu. You can replicate the menu multiple times, remove functions you
want to deny to each role, and use those new menus as your permission sets.

Best Practice: Use appropriate pages or forms for setup

If you are using RBAC, it is a good idea to use the Oracle User Management responsibilities to create
and manage your RBAC setup. These Oracle Application Framework-based responsibilities include
the Functions, Permissions, and other pages in the Functional Administrator, Functional Developer,
and User Management responsibilities. These pages help keep the distinctions more clear between
functions and permissions.
Similarly, if you are using traditional function security, use the Oracle Forms-based forms in the System
Administrator responsibility or Application Developer responsibility for your setup. While there will
be times when you need to cross between Oracle User Management and the System Administrator
responsibilities, such as for creating responsibilities, using the right setup forms or pages can help make
your setup process more clear.
Specifically, Oracle User Management keeps permissions and functions separate in both the Functional
Administrator and Functional Developer responsibilities, so permissions defined using the Permissions
page cannot be queried in the Functions page, and functions defined in the Functions page cannot be
queried in the Permissions page. Note that either functions or permissions can be used as a permission
when defining a permission set. Permissions defined using the Permissions page do not contain
execution information such as URLs, so they can only be used as non-executable functions
(subfunctions) or as permissions. Permissions defined in the Permissions page can be queried in the
Form Functions form in the Application Developer responsibility, where they appear with the
“Subfunction” type. Functions defined using the Functions form or page can be used in both menus
for navigation and permission sets for authorization.

Best Practice: Avoid modification of shipped objects

In general, we recommend that you do not modify Oracle E-Business Suite shipped menus or roles,
because your changes can be overwritten during a patch or upgrade. However, you can duplicate
Oracle E-Business Suite menus, modify your copies, and use the copies for your custom
responsibilities and as permission sets for grants. You should document which menus you copy so you
can make corresponding changes to your copies if the original shipped menus are changed during
application of a patch or in an upgrade. Changes you might make to your copies include unchecking

20
Function Security and Role-based Access Control (RBAC) in Oracle E-Business Suite

the Grant check box for functions in menus so that you can control authorization more finely using
grants and permission sets.

Best Practice: Use delegated administration

Oracle User Management uses seeded roles and permissions to provide specific functionality for
setting up delegated administration. With delegated administration, instead of relying on a central
administrator to manage all users, an organization can create local administrators and grant them
sufficient privileges to manage a specific subset of the organization's users and roles. This provides
organizations with a tighter, more granular level of security, and the ability to easily scale their
administrative capabilities. For example, organizations could internally designate administrators at
division or even department levels, and then delegate administration of external users to people within
those (external) organizations.
Administration Privileges--for administering users, roles, and organizations--determine the information
that delegated administrators (local administrators) can manage. Each privilege is granted separately,
and the three privileges work together to provide the complete set of abilities for the delegated
administrator.
For more information about delegated administration, see Oracle® E-Business Suite System Administrator's
Guide – Security, Release 12.1, Part No. E12843-05.

Conclusion
Because RBAC involves more objects than responsibility-based security, RBAC is slightly more
complex to set up initially. However, RBAC is also more powerful and flexible than using only
function security. Once you learn to set it up, RBAC can save a lot of time and effort in the long term
by making administration of individual users and groups of users easier.

21
Understanding Differences between Function Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
Security and Role-Based Access Control
(RBAC) in Oracle E-Business Suite This document is provided for information purposes only, and the contents hereof are subject to change without notice. This
January 2013 document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in
Author: Sara Woodhull law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any
Contributors: Steven Chan, Robert Farrington, liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This
Clara Jaeckel, Sriram Pakanathi document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our
prior written permission.
Oracle Corporation
World Headquarters
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
500 Oracle Parkway
Redwood Shores, CA 94065
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and
U.S.A.
are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are
Worldwide Inquiries: trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0113
Phone: +1.650.506.7000
Fax: +1.650.506.7200

oracle.com