Introduction

There is a wealth of documentation regarding security implementation for Fusion Applications; this series of articles is intended to collate information from various sources. The goal is to provide a high level overview of the implementation and components involved.

In EBS security is generally based on Responsibilities. Authentication was based on users in FND_USER table and authorization based on functional security defined in the menu structures for responsibilities. Responsibilities not only defined the set of functions that a user can access, but also often the data on which those functions can be performed. So the shipped responsibilities were not immediately usable and there was a very large configuration effort required before the set of responsibilities would match customer implementation.

In Fusion the security implementation is aligned across applications such that security is implemented consistently based on Role Based Access Control (RBAC) standard across applications using common components. While the concepts such as users, roles, grant etc. are shared across features and releases, there are some differences in the terminology. Refer to this document for mapping of the terms used between features and releases.

The security implementation consists of two main concepts; authentication and authorization. Authentication ensures the identity of the user based on the identity store and authorization ensures that the user only has access to resources they have been granted access to in the policy store. The concrete implementation of the identity store and the policy store are configurable and may use different technologies depending on the customer requirement.

The implementation is conceptually divided into function and data security; former controls the access to resources while the latter controls access to the data.

Users

A User is an end-user accessing a service. The user is granted access to resources using role assignments. Fusion Applications generally do not ship pre-defined users rather they are always created by the customer. There are few exceptions for example Application Identities, User information is stored in the identity store, for Fusion Applications the identity store is based on an LDAP repository. By default Oracle Internet Directory (OID) is used as the LDAP repository, however other repositories may be also configured to be used in cases where customer has different LDAP repository implemented.

Application identities

Sometimes the code needs access beyond the access rights of the current user; for example in processing related to credit cards the user should not be able to access the credit card numbers while the code needs the access for the processing. Application Identities are used to separate the access that the end users have from the access that code in the system has. This is achieved by switching the identity under which the code is running to a special application identity when elevated access is needed.

For more information refer to the Application Identities section of the Fusion Applications Security Guide.

Roles

There are two definitions used for roles; functional and technical. Former is used when conceptually describing the role hierarchies, latter is used with concrete implementation of the roles.

Functional Roles

Functionally there are four types of roles: abstract, job, duty, and data.

• Job Roles; these are roles associated with the Job of an employee. An employee with a Job can have many duties. Example: A person may be hired to be an accounts payables specialist (job role), but a person is not hired as an invoice receiver (duty role).
• Duty Roles; these are roles that are associated with a specific duty or a logical grouping of tasks. For example, in Accounts Payables, an 'Accounts Payable Specialist' (job role) can have the Invoice Reviewing and Invoice Receiving duties (duty roles).
• Abstract roles; these are roles that are associated with a user irrespective of their Job or job function. These are also roles that are not associated with a Job or Duty. Examples: Employee (Human Resources), Manager (Human Resources), Customer, Supplier etc.
• Data Roles; these are roles implemented as Job roles for a defined set of data. This role describes the job a user does within that defined set of data. The data role will inherit a job role and will be granted applicable data security privileges. For examples an Accounts Payables Specialist may be assigned the data role 'Accounts Payables Specialist - US Business Unit'.This data role would inherit the job role 'Accounts Payable Specialist' and grant access to transactions in the US Business Unit. Data roles can only be defined by customers, as they are data dependent.

For details of functional roles refer to Role Types in the Security Reference Implementation: Explained.

Technical Roles

The functional roles are technically implemented using enterprise and application roles. The enterprise roles are stored in the identity store; the application roles are stored in the policy store.

Duty roles map to application roles while the rest of functional roles map to enterprise role. The difference between application and enterprise roles is the scope; application roles are dependent on the application context while the enterprise roles are common across all applications. For example if a user has been assigned following role hierarchies:

• 'Accounts Payable Specialist' (job role == enterprise role)
• ' Invoice Receiving' (duty role == application role)
• 'Enter Invoice' (duty role == application role)
• 'Create Payment' (duty role == application role)
• 'Accounts Payable Manager ' (job role == enterprise role)
• ' Invoice Approval' (duty role == application role)
• 'Approve Invoice' (duty role == application role)
• 'Release Invoice Hold' (duty role == application role)

When the user accesses a UI for the“Invoice Approval” the roles active for the user consists of system role indicating user has authenticated, the enterprise roles assigned to the user and the application roles in the context of the application accessed:

• ‘authenticated-role’
• 'Accounts Payable Specialist' (job role == enterprise role)
• 'Accounts Payable Manager ' (job role == enterprise role)
• 'Invoice Approval' (duty role == application role)
• 'Approve Invoice' (duty role == application role)
• 'Release Invoice Hold' (duty role == application role)

Notice that the duty roles of 'Accounts Payable Specialist' are not included. This set of principals (user and role definitions) is then used when the system determines where user is authorized to access a resource.

Role Based Access Control (RBAC)

RBAC restricts access based on the role of the user within the organization rather than the user’s individual identity. RBAC defines “Who can do What on Which set of data”. While RBAC implementation has been available since 11i as an application specific implementation, few products adopted the concept completely. In Fusion the security based on RBAC is consistently adopted across all applications.

Role hierarchies are a natural means of structuring roles to reflect an organization’s lines of authority and responsibility. (RBAC ANSI standard ANSI INCITS 359-2004).Fusion Applications provides a reference implementation of the role hierarchy; the reference implementation defines how Fusion Applications expects the customer to use the applications and structure the roles. The customer may choose not to adopt the reference implementation; however in such case there is a significant implementation task of constructing the role hierarchy from scratch to match the customer requirements.The concrete details of the reference implementation can be found in the Security Reference Manuals (SRMs) for each offering..

For more information on the concept of reference implementation see Security Reference Implementation.

For more information on RBAC refer t to the Role-Based Access Control section Fusion Applications Security Guide.

Authentication

Fusion applications run within a container in the Oracle WebLogic Server (WLS). This container handles authentication automatically for the application running in it by intercepting all requests to the application and ensuring that users are properly authenticated and the security context is propagated, as appropriate, before the request can proceed forward.

The security context of the user is contained on a Security Subject. When an end-user first accesses an unprotected resource, the system creates a subject and populates it with the anonymous user and the anonymous role. When a protected resource is accessed authentication occurs, the anonymous objects are replaced with the authenticated user and role. Also the enterprise roles common to all applications and the application role specific to the application being accessed are added to the Subject.

For more information refer to Fusion Middleware Application Security Guide section Understanding Users and Roles.

Authorization

Authorization ensures that the user only has access to resources they have been granted access to. Authorization checks are divided into function and data security; former controls the access to resources while the latter controls access to the data.

The authorization checks may be implicitly enforced by the system or explicitly implemented by a developer declaratively or programmatically.

For more information refer to Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework - Enabling ADF Security in a Fusion Web Application

Function security

Function security in EBS was based on functions defined on menu structures, which were assigned to responsibilities. RBAC separates security from the navigation, such that they can be modified independently of each other.

Conceptually Fusion Application function security implementation is simple; at the core of the system is a grant. Grant provides a role (or user) access for permission set (or individual resource). The permission set is a grouping of related permissions required to complete a task. E.g. resources to access a page and all related taskflows may be grouped together into a permission set such that they can be granted together instead of granting each separately.

The security policies (resources, permissions sets, grants, application roles) are contained in the policy store and security policies can be changed without any code change.

Bounded taskflows are secure by default; the system will always check that the user has been granted access to the taskflow being accessed. Also top-level pages in an unbounded taskflow are secure by default. Additionally developers can opt-in for explicit authorization checks declaratively or by calling authorization APIs

For more information refer to Fusion Applications Security Guide - Function Security.

Data Security

Data security implementation in EBS varied between products. RBAC based data security was available; however it was not widely adopted by the application teams.In Fusion Data Security is a recommended way for enforcing data security for Fusion products. Fusion Data Security is similar to the FND Grants model in EBS, the key difference is the integration with Oracle Java Platform Security (OPSS) for the users and roles.

The goal of Fusion Data Security data security is to ensure only authorized user can perform actions on secured data.Data security defines "Who can do what on which set of data".

Conceptually data security implementation is simple; at the core of the system is a grant. Grant provides a role (or user) access for privilege on a given set of data:

The security definitions consist of: 

• Business object identifying the table to be secured
• ·Instance set(s) identifying the data to be secured
• ·Privileges for the secured object identifying the allowable actions on the data

Data security is not enforced automatically, rather data security needs to be implemented either declaratively (EO / VO) or programmatically on each secured object.

For more information refer toFusion Applications Security Guide - Data Security

Summary

In this article we covered some basic concepts of security in Fusion Applications. This provides a high level understanding that will serve as starting point for future articles where we will dive deeper to the specific features.

References

• Fusion Applications Security Guide
• Fusion Applications Administrator's Guide - Securing Oracle Fusion Applications
• Fusion Middleware Application Security Guide
• Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework - Enabling ADF Security in a Fusion Web Application
• Fusion Applications Developer's Guide - Implementing Oracle Fusion Data Security
• Fusion Applications Security Guide - Function Security
• Fusion Applications Security Guide - Data Security