Oracle R12 E-Business Suite – Role Based Access

Control and Roles Lifecycle Management

Sajid Rahim
Department of Computer Science/Software Engineering
McMaster University
Hamilton, Ontario, Canada
[email protected]

Abstract—Oracle E-Business Suite R12 is a widely used ERP RLM is essential for improved security controls for access and
solution that provides integrated view of information across Segregation of Duties (SOD) which assist with audit and
multiple functions and sources. It allows for simplified business control compliancy. Role based access control is not a one
process tools for Shared service model e.g. Centralized Operation type project as roles are dynamic and must evolve as business
where multiple operating units can be supported. Security
considerations are vital for such operations in large enterprises.
changes. Effective role management requires a continuous
R12 introduced Role Based Access Control security based on process for monitoring and managing.
ANSI RBAC standard. R12 RBAC implementation is challenged
with lack of Roles Lifecycle Management (RLM) process which The paper is motivated in proposing a Roles Lifecycle
also contributes to challenges such as Segregation of duty (SOD), Management process which can be used for effective controls
and controlling access to PII for multi-country operation for and audits for R12 EBS as a must have in order to assist with
common functional areas. The paper will propose a possible providing insights into which user has access to what.
Roles Lifecycle Management process.
II. BACKGROUND
Keywords—RBAC; Oracle; EBS; Roles Lifecycle Management;
RLM A. Roles and Definition

I. INTRODUCTION Role Based Access Control (RBAC) is as widely used

access control method which assigns users to Permissions
Businesses are continuing to implement mission critical through Roles (User-Roles relationship). Roles are based on
applications such as Oracle E-Business Suite R12 or Fusion job functions and can be derived from organization roles.
by replacing legacy and home grown systems with the aim of New roles can be derived though hierarchy though role
standardized business processes and IT infrastructure while inheritance (Role-Role relationship) or changes in permissions
providing single view on the business. Business users are (Roles-Permissions relationship). These components
granted access based on their roles as defined by Human collectively determine as a role member, what user constraints
Resources. are in terms of what access or operation that may be
performed on the data/information or transactions. In other
E-Business Suite R12 has embraced Role Based Access words, it presents an abstraction of organizational
Control (RBAC) based on RBAC ANSI standard (ANSI responsibilities as a role and its relationship to the
INCITS 359-2004) originally proposed by the US National organization which is assigned to respectful users.
Institute of Standards & Technology (NIST). RBAC provides
secure controls for access and authorization that can be used to
create and enforce segregation of duties. This co-exists with
R12’s ‘traditional’ responsibility based access control. R12
RBAC layers upon responsibility access control as Roles.
Roles provide significant security design improvement over
the Responsibilities based option by normalizing access to
functions and data through user roles rather than only users.

Since R12 RBAC layer is relatively new, there is a lack of

Roles Lifecycle Management (RLM) process. RLM is an
encompassing process by which an organization develops, Fig 1. Role Based Access Security
defines, enforces and maintains roles access control. Effective
 Roles provide significant advantages in terms of
compliance including segregation of duties, administration of
users, secure and need to purpose based access control.
Additional RBAC derivatives are now available such as
EnRBAC,Temporal RBAC.
B. Oracle RBAC Security

Traditional ‘Responsibility’ provides authorization to a user

with a list of function security, Fig2. Two types of functions
exist namely executable and non-executable. An executable
function is invoked from the menu or submenu page which is
presented upon user login. The function will invoke a
transaction, page, report or service. A non-executable function
is an abstract alias which can be used to define a submenu, a
subset of a page or form. A menu is created by grouping a set
of functions in a hierarchical structure with submenus,
prompts[5].
Fig 3. Role Based Access Control

For a single role, RBAC appears to be an over kill but a

user in general has multiple responsibilities. Hence RBAC
becomes very useful in creating a single role e.g. Sales Role
that allows multiple responsibilities such as Employees and
Sales as shown in Fig 4.

Fig 2. Function Security

A responsibility provides authorization to a menu of

functions based on a user role. A user can have one or more
responsibility. Many users can share the same responsibility.
RBAC security shares the same concepts but expands the
definition. Authorizations are made via Permissions at
function level; grant authorization is discontinued. Typical
RBAC provides access to objects in the form of permissions –
in EBS R12 this becomes access to a function. These Fig 4. Role defines multiple responsibilities
permissions are grouped together as grant permission set across
accessible functions. Roles are assigned to users based on their A Role can be tuned with selective authorization via
roles in the organization and user performs only those separate Grants and permission sets within same responsibility.
functions are defined by the required role within the For example, a sales role can be for Sales Person or Sales
organization, Fig 3. Manager; Sales Person can view the orders but Sales Manager
can view and approve the orders.
 roles proceeded by assigning and revoking of roles to users. It
includes tracking these changes for audit purposes. The paper
will now proceed on describing how existing components of
R12 EBS can be leveraged to support a RLM process which
will be described in the next section.
In R12 EBS, user security is offered by User Management
functionality which has six built up layers as shown in Fig 7
[6]. Of interest are three core security layers starting with
Function Security that describes what a user can do, Data
Security describes what a user can see and Role Based Access
Control layer which grant access to roles that include
function/data security. Administrative Features allow for
workflow based self-service and approvals including delegated
administration of roles.

Fig 5. Function Security

Finally in R12 EBS RBAC, Roles hierarchy is comes into

effect when roles inherit permissions of roles. Users are
assigned roles once Permissions are assigned to these roles. In
Fig 5, Manager inherit Buyer’s role which inherit Inquiry Role.
Purchasing Buyer is assigned Buyer role while Purchasing
Manager is assigned Manager Role.

Fig 7. User Management Layers – Core Security

Role Based Access Control layer supports the mapping of

user access control based upon a user role in the organization.
Roles are grouping of all the responsibilities, lower level
permissions (functions), permission sets, and data security
rules that a user requires for performing a specific task. Role
Categories allow Roles are organized into groups.
The three layers are assisted using web forms which are
available via separate R12 EBS responsibilities namely User
Management Fig 8, Functional Administrator Fig 9, Functional
Developer Fig 10.

Fig 6. Roles Hierachy

Roles hierarchies further can be utilized to group together

multiple responsibilities, and multiple roles together with Fig 8. User Management – Core Security
various combinations of grants/permission sets, Fig 6.
To summarize R12 EBS RBAC provides offers better security
and greater productivity through Roles whilst reducing
Fig 9. Functional Administrator – Core Security
overhead associated with traditional responsibility access
control. Because of R12 EBS dynamic environment, it
necessitates Roles Lifecycle Management to manage roles and
associated users from inception to retirement.
Fig 10. Functional Developer – Core Security
C. Oracle R12 EBS User Management. These sets of functional competencies allow for the
creation of objects e.g. table/view which need to be secured
We note that Role Lifecycle Management is a necessary using Functional Developer. Permissions which control access
process that is required for successful maintenance of R12 EBS to functions and data, grouping of these permissions into a
RBAC. Roles Lifecycle Management describes changes to permission set, and giving grants for an action on a specified
Roles starting with the creation, modification, and deletion of
object to a grantee is managed by Functional Administrator. A or details. Starting with Role Analysis which identifies roles
grantee may be a role, group or a user. within the environment context, Role Design transforms this
definition into usable roles. Role Management focuses on
daily administration and changes to the role model while Role
Maintenance will deal with major changes in the roles due to
organizational changes, user, roles and permission
relationships.

Fig 13. Roles Lifecycle Management - Schimpf

Fig 11. User Management Security – Process Flow

Schimpf [9], also follows software development lifecycle
using Analysis, Design, Build and Maintain stages, Fig 13.
All the above shows a fairly robust set of RBAC associated Analysis defines the outcomes of the Roles Engineering
functionality which can be used to create Process. Design assumes a zero RBAC model presence and it
permission/permission sets, create object instance sets, create seeks to define it while constructing roles prototypes and
grants, and assign roles using User Management Security establishing Roles Catalogue. He moves to Build phase which
process flow, Fig 11. While there is a functional RBAC implements the Roles definitions and finally Maintenance
implementation, there is a lack of formal process by while which manages changes that the organization will undergo.
Roles can be analyzed, defined, managed and maintained in the
form of Roles Lifecycle Management. Both models do provide a semblance of order with
structure but they do not go into details of each phase or any
interdependencies. Kerns fails to identify Role Catalogue
III. ROLES LIFECYCLE MANAGEMENT which is a core component or documenting/capturing meta-
data. Schimpf’s model also fails to recognize that RBAC can
A. Present Methodologies be a standard feature within an enterprise system and focus
needs to be on deriving roles and extending them.
While RBAC is widely received and many research papers This paper seeks to derive an improvised model after
are available, very few papers describe what a lifecycle considering both of these two models which have
process will be. Both approaches described by Kerns et al.[7] commonality yet differences. Phases will be extended with
and Schimpf [8] leverage software engineering methods. additional phases and outcomes. Since a Role Model already
Additional role lifecycle such as process based and temporal exists within R12 EBS framework and the focus will be on the
roles lifecycle are unsuited for use within R12 EBS lifecycle alone that is easy to use and manage with.
frameworks and therefore not discussed.

B. Proposed Methodology

Kerns et al (2002) first identified a cycle which is a natural

fit for this use but it presents some limitations which we will
attempt to extend and improve in specific context to Oracle
R12 EBS RBAC. A role lifecycle can be adopted in the form
of interative traditional waterfall. Four core components
specified as Role Identification/Analysis, Role
Fig 12. Role Lifecycle Flow – Kerns et al. Definition/Enginering, Role Management and Role
Maintenance/Governance. The flows noted allow for ease of
Fig 12 shows lifecycle consisting of four modules which movement between each stage.
are iterative in nature and without a strict sequence of events
 This phase as illustrated in involves Analyzing
Organization and System views by consolidating of
organizational structures, existing functional responsibilities,
user groups, permissions, segregation of duties; these will
represent Business Views while existing R12 EBS seeded
roles definitions represent System View. These will analyzed
by traversing the information in a bottom up and top down
information review for maximized analysis. Role concept
model, Roles Hierarchy, permission, segregation of duties
constraints, membership qualifiers and other miscellaneous
role support information will be derived. The results will be
Fig 14. Role Lifecycle Flow – Extended model
stored in Analysis Catalogue which will assist determine
An organization has separate divisions. This cyclical potential roles, permissions, and user/permission groupings.
nature allows each of these processes to be performed Analysis Catalogue will also assist with business validations
incrementally for each of these divisions or operations. Should and audit.
a challenge arise in the sequential stages whether it be a change
in business process due to regulatory requirement or gap in It is imperative to highlight that new roles are identified
requirements, the model allows to step back and fix prior stage within the organization context using human resource and
and cascade aligned corrections down to subsequent stages. functional role description, duties and permissions. Following
This iterative waterfall model presents advantages namely: recommendations are noted for deriving sustainable roles.
• Allows for earlier discovery, detection and
remediation instead of finding problems later such as • Roles need to be analyzed by functional specialists
duplicate roles, unclear regulatory requirements, with explicit knowledge of the subject organizational
changes in business organization structures, changes roles.
in regulatory requirement due to external factors; this
is critical to prevent redesiging entire organizational • Leveraging formal ontology to describe jobs, tasks and
roles. access to EBS data/functions after creating an
hierarchical structure of the organization.
• This model allows for a pilot project be completed for
one division. Lessons learned from the discovery • Adhere roles to natural structure of the organization as
process can lead to improvements in all the stages so this tends to be generally static. Changes in structure
that subsequent cycles for other divisions can be will increase role management.
easily managed and even automated.
• Hybrid analysis of identifying all permissions that exist
In summary, ontinuous life cycle is recommended as it within the organization, and clustering these by
guides towards more intelligent and efficient role design. traversing the organization structure either up or down
to identify permission clusters which will constitute a
D. 1. Role Analysis role.
• Access control can be compromised by complexity.
Role Analysis is the first core process of this particular
Higher levels of complexity can result in lower
methodology and our model provides core process details that
security as control cannot be defined. Roles must be
will support this phase as illustrated in Fig 12. defined with the permission cluster maps to natural
role e.g. permission cluster will match a user
community group.
The real value of roles is realised when they are analyzed to
be able to operate a the level based on the access requirements
for specific job functions or business processes; this assists
elimininating compliance violation and mitigating risks.

D. 2. Role Engineering

This phase will build on the results of role analysis which

has completed the organization review as well as standard roles
which are delivered by R12 EBS. Meta data from the analysis
will reside in Analysis Catalogue and used during this phase as
well as for comparative purpose during the Roles Maintenance
Fig 12. Role Analysis Process. phases.
 Roles Engineering will conceive formal roles definitions by the organization process and that which is administration of
which will be prototyped and verified in an iterative manner the roles themselves. The later in the case of R12 EBS will
until business needs are met in the respective sub-processes. require the three functional roles e.g. Functional administrator,
Once confirmed, these roles will then be catalogued as formal Functional Developer and User Management be made
Role Concept Models which will be utilized as input to available for a group of administrators.
Management phase. This phase is supported by the following
processes namely Design Roles, Prototype Roles, Verify Roles Following guidelines are noted during the Role
leading to Design Signoff that sees the roles now saved in Role Engineering process:
Concept Model.
• Creation of a catalogue which maps each organization
structure and functional role to an R12 EBS Role.
Examine delivered R12 EBS Roles as re-engineering
candidates as excellent source templates. The
catalogue will capture Segregation of Duties (SOD)
rules or dependencies for conflicting stored Roles.
• Multi-Organization Access Control (MOAC) simplies
security by allowing a single role to be used across
various organization divisions.
• Create Permission and Permission Sets as needed User
to Role association using Functional Administrator.
• Consideration for automated tools such as Desktop
Administrator where roles can be engineered and
business rules for roles including SOD are captured
and conflict exceptions can be reported on.
• Identify metrics for measuring role quality e.g. is the
role simplifying the access, is it well understood, how
many people will use it, role constraints, future role
expansion, compliancy violations etc and quantify
these.
This is the most critical phase in this process and it is
essential for functional specialists and Oracle R12 EBS Roles
Fig 12. Role Engineering Processes.
administrators to perform Conference Room Pilot (CRP)
Design Roles process will work in an iterative matter with cycles to validate and confirm the roles correctly meet the
the subsequent processes to refine the design. This may business requirements. This aligns to Oracle EBS security
involve further qualifying rules for Roles concept models, model which recommends business owners review and
further identification of new Role concept models including approve Roles based on business needs, organization structure
combining and splitting new Role concept models and and user roles; this can also serve as a certification process.
grouping Roles by Business Activities, Permission Selection
and User selection. Transient Roles concept models will be
prototyped and verified. D. 3.Role Management

Verify Roles process will be conducted jointly with Role Management will comprise of two processes which
business user; it will review Roles derived, memberships, work closely hand in hand; Role Deployment and Role
permissions and user groups are valid; any changes will be Administration, Fig 13. Starting with Role Deployment that
iterated back with Design Role process, prototyped and will focus on the implementing/deploying the Roles into
reviewed thereafter until accepted by Design Signoff process Production R12 EPS Production/Test Environment as defined
which will catalogue an affirmative Role Concept Model that and signed off in Roles Concept Models from Roles
is tuned and tagged with Permission selections and candidate Engineering phase. These implemented roles are stored within
user selection lists. Analysis Catalogue will be updated by the application metadata and noted as Roles Catalogue. Once
these findings. This collaboration is vital as it establishes a deployed, administering changes to deployed roles within the
common language and introduces the data model to business context of Roles Catalogue and Roles Concept Model as well
users. as user administration becomes the domain of Role
Administration process.
During the Design Role imperative to recognise that two
main categories of roles are present. Roles that are conferred
 As noted before Role Administration focus will be on
designed roles that were catalogued from the design phase and
deployed. Some of the activities will be:

• Organizational changes that impact existing definition

of a role.
• Creation or deletion of user or permissions.
• Modifications including joining/removal of
relationships between:
o User/User groups – Role/Roles
o Role/Roles – Permission/Permission Sets
• Roles changes which include:
o Splitting a role into multiple roles due to
Segregation of Duties etc.
o Merging multiple roles into single role

Fig 13. Role Management sub-processes. Role Administration itself as defined can be well
supported by period role check which can be partially
Role Deployment, illustrated in Fig 14, is the
automated; business changes affecting role definition can be
implementation of the Role Concept Model into role templates
preprocessed in order to identify the change which will affect
that are created as custom Roles with additional permissions
the catalogued roles.
and security rules using a custom Wizard application which
can be integrated with R12 EBS application; this new data is
The above activities are all within the given constraint of
identified as Roles Catalogue. Users and user groups are
an existing designed role. Any change related to an existing
assigned the appropriate roles from this Roles Catalogue.
catalogued role will be handled in this area. This work is
Metadata is ready for transfer and deployment using standard
solely the domain of designated Roles administrators with
Oracle EBS fndload utility first to R12 EBS Test Environment
Functional Administrator role.
for validation prior to repeating the process to R12 EBS
Production Environment.
D. 4. Roles Maintenance

Roles Maintenance focuses on major changes to roles that

have been catalogued for organizational use from prior stages.
These changes originate from organization structure to role
mapping, changes in user-roles and role-permission
relationships.
Roles are never static and are bound to be subjected to re-
engineering as organization structures or even organization will
undergo change in the form or mergers, acquisitions or process
re-engineering. Effective maintenance requires continuous
monitoring and managing the maintenance to ensure
effectiveness.
A Role Manager is required to adapt and revise the roles for
the newer environment. It is logical for a method to be created
which firstly considers the roles stored in the Role Catalogue
and associated permissions to forth coming changes that will
necessitate defining new role, modify an existing role and
removal/archiving of obsolete/unused roles. This detection
mechanism can be considered as an iterative process which is
carried out on a periodic basis or triggered due to a business
event in a proactive manner at the time of business process
change. In other words events that cause changes in
organizational relationships require role memberships to be re-
Fig 14. Role Deployment process. evaluated such that user access and privileges are in line with
business policies; in doing do, the processes will feed back to
Role Analysis and Engineering processes.
 IV. CONCLUSION AND FUTURE WORK
R12 EBS RBAC offers very powerful and flexible access
control security than traditional responsibility. Even though
RBAC security is more involved in setup; it offers easier
administration and audit of users once a formal Roles Lifecycle
Management approach is adopted as part of system
administration. Roles Lifecycle Management requires strong
business and technical processes, effective reviews and tight
enforcement and integration across analysis, engineering,
management and maintenance phases.
This paper represents a first detailed attempt at dissecting
what a roles lifecycle management will entail to assist with
Oracle R12 EBS and Fusion Financial Enterprise Planning
Software; we have shown four tightly coupled processes that
Fig 14. Role Maintenance process interaction are integrated into a single comprehensive lifecycle each
reflecting specific sub processes and outcomes. This work can
be moved forward with more focus on Role Maintenance stage
We can define this concept as shown in Fig 14. Role specifically in relation to metrics, identification and managing
Deviation Identification upon initiation either on a periodic role changes.
basis or upon event will consider the changes in the form of
meta-data against existing users and Roles that are presently
deployed. It is responsible for identifying the deviations from ACKNOWLEDGMENT
present setup including, conflicts or gaps or additional Special thanks for Dr Reza Samavir for his continued
analytical information that can be studied by the respective support and assistance with various discussions and thoughts
Role administrators and business functional leads; this work towards focusing this particular research area.
may also involve traversing and reviewing the organizational
structure change either bottoms-up or top down to validate
these proposed changes. This process will work hand in hand REFERENCES
with Roles Analysis process to ensure analysis is retained and
updated in Analysis Catalogue.
[1] D.F. Ferraiolo, D.R. Kuhn, R. Chandramouli, Role Based Access
Role Re-Definition will then be used to formalize the Control(book), Artech House, 2003, 2nd Edition, 2007.
change in terms of approval, permissions, segregation of [2] R. S. Sandhu, E.J. Coyne, H.L. Feinstein, C.E. Youman (1996), "Role-
duties. It works closely with Roles Engineering which Based Access Control Models", IEEE Computer 29(2): 38-47, IEEE
Press, 1996.- proposed a framework for RBAC models
leverages defined techniques to manage exceptions, review
[3] D.R. Kuhn, E.J. Coyne, T.R. Weil, "Adding Attributes to Role Based
changes to existing roles and or creating new roles, prototyping Access Control", IEEE Computer, vol. 43, no. 6 (June, 2010), pp. 79-81
and performing validations with business partners until signoff
[4] D.F. Ferraiolo, R. Kuhn, R. Sandhu (2007), "RBAC Standard Rationale:
is achieved. Roles Concept Model is then updated with these comments on a Critique of the ANSI Standard on Role Based Access
changes. Update Roles process will formally implement the Control", IEEE Security & Privacy, vol. 5, no. 6 (Nov/Dec 2007), pp.
change in Roles Catalogue and user information via Roles 51-53 - explains decisions made in developing RBAC standard.
Management process. Any anomalies such as out of role [5] Function Security and Role-Based Access Control (RBAC) in Oracle E-
exceptions, rights violations, duplicates found will require Business Suite (Doc ID 1537100.1)
iteration back to prior step. [6] System Administrator’s Guide – Security. Release 12.1. Part No.
E12843-05.
Potential exists for employing a form of rule based [7] Kerns A., Kuhlmann, M., Schaad, A., Moffett, J.D.: “Observerations on
automated analysis to identify deviation which then feeds the role lifecycle in context of enterprise security management."
information over to Roles Analysis process in a cyclical Proceedings of seventh ACM symposium on Access control models and
manner. Similarly rules can be written for roles defined in technologies (SACMAT), pp 43-41 Monterey, California (2002).
Roles Concept Model and Roles Catalogue to aid in the overall [8] Fuchs, L. and Pernul, G.: Supporting compliant and secure user handling
– a structured approach for in-house identity management. Proc. of the
roles maintenance process becoming far simpler, efficient and 2nd International Conference on Availability, Reliability and Security
streamlined while providing increased business agility. (ARES'07),Vienna,Austria(2007).
[9] Schimpf, G.: Role-Engineering Critical Success Factors for Enterprise
Security Administration. Position Paper for the 16th Annual Computer
Security Application Conference, New Orleans, USA (2000)