Showing posts with label Oracle Fusion. Show all posts
Showing posts with label Oracle Fusion. Show all posts

Wednesday, September 27, 2017

Oracle Fusion Roles Concepts in Fusion Applications

Introduction to Fusion Applications Roles Concepts

Fusion Applications Security is designed based on Role-Based Access Control (RBAC). It is an approach to restricting access to authorized users. In general, RBAC is defined based on the primary rules as per this wiki page.
RBAC normalizes access to functions and data through user roles rather than only users. User access is based on the definition of the roles provisioned to the user. RBAC secures access in a “Who can do what on which functions or sets of data under what conditions” approach. The “who” is the user.
The roles are defined at functional and technical levels. The functional level is the business definition that is used by business users and the technical level is the implementation of roles using Oracle Technology. This post will quickly review the definition of “Functional Roles” and provide introductory internals on the technical implementation of these “Roles” within Fusion Applications.

Architecture of Functional Roles


At a high level, RBAC is based on the following concepts:

·         Role assignment: A subject can exercise permission only if the subject has selected or been assigned a role.
·         Role authorization: A subject’s active role must be authorized for the subject. With rule 1 above, this rule ensures that users can take on only roles for which they are authorized.
·         Permission authorization: A subject can exercise a permission only if the permission is authorized for the subject’s active role. With rules 1 and 2, this rule ensures that users can exercise only permissions for which they are authorized.
In Fusion Applications, the RBAC implementation is based on abstract, job, duty, and data roles that work together to control access to functions and data. The definitions of these functional roles are as follows:

Abstract Role:

This role categorizes the roles for reference implementation. It inherits duty role but does not contain security policies. For example: Employee, Manager, etc.

Job Role:

This role defines a specific job an employee is responsible for. An employee may have many job roles. It may require the data role to control the actions of the respective objects. For example: Benefits Manager, Accounts Receivable Specialist, etc.

Data Role:

This role defines access to the data within a specific duty. Who can do what on which set of data? The possible actions are read, update, delete, and manage. Only duty roles hold explicit entitlement to the data. These entitlements control the privileges such as in a user interface that can see specific screens, buttons, data columns, and other artifacts.

Duty Role:

This role defines a set of tasks. It is the most granular form of a role. The job and abstract roles inherit duty roles. The data security policies are specified to duty roles to control actions on all respective objects.
This is a diagram from the “Oracle Fusion Applications Security Guide” that shows the relationships between these roles:



Note: The duty role in above diagram is the granular form of a role where security policies are attached. They are implemented as application roles in APM and scoped to individual Oracle Fusion Applications.


Please provide your valuable feedback ............

Oracle Fusion Role-Based Access Control and Function & Data Security

Role-Based Access Control

Access to system resources is granted to users through the roles assigned to them, not to the users directly. Roles provide access to functions and data.

The Oracle Fusion Applications security approach includes abstract, job, duty, and data roles. Abstract roles group users without respect to specific jobs, such as all employees or all managers. Job roles group users in adherence to the principle of least privilege by granting access only in support of the duties likely to be performed, such as the job of Accounts Payable Manager. Duty roles define the duties of a job as entitlement to perform a particular action, such as processing payables invoices. Data roles group users who have functional access through a particular job role with access to a particular dimension of data, such as invoices relevant only to their business unit, or based on Human Capital Management (HCM) security profiles, such as employees who work in departments in a particular country, line of business, or division.

Abstract, job, and data roles are implemented as enterprise roles in Oracle Fusion Middleware so they can be shared across the enterprise. Duty roles are implemented as application roles in Oracle Fusion Middleware so they can be defined within applications.

Function and Data Security

Functions and data are inaccessible to users unless they are provisioned with the roles necessary to gain access. Function security provides users with access to pages in application users interfaces and actions that can be performed there. Data security allows users to see data in those pages. Some data is not secured, in which case access to a user interface page gives unrestricted access to the data that is accessible from that page. For example, some setup data such as Receivables Receipt Method and Payment Method is not secured, and some transaction data such as Receivables Customer Profile is not secured. Archive data such as Receivables Archive is also not secured.

Enterprise roles inherit application roles that provide the enterprise roles with access to application functions and data. Roles are grouped hierarchically to reflect lines of authority and responsibility. The figure shows user access to functions and data determined by roles arranged in hierarchies and provisioned to the user.


Duty roles carry entitlement to actions on functions and data. An example of a duty role is the Payables Invoice Processing Duty. Job and abstract roles inherit duty roles that determine the access to functions appropriate to the job. For example, the job role Accounts Payable Manager inherits the Payables Invoice Processing Duty.

Data security policies may grant actions on data to enterprise or duty roles. The condition of a data security policy determines if the access is explicit, such as all invoices of a particular business unit, or implicit, such as all invoices in the business unit to which a user is assigned. Job and abstract roles inheriting duty roles for which data security policies are defined grant implicit data access.

Data roles inherit abstract or job roles or both, and are granted explicit access to data. For example, a job role might give view access to the functions needed to access invoices, but a data role that inherits the job role gives view access to the invoices data within a business unit, such as the data role Accounts Payable Manager - US which inherits the job role Accounts Payable Manager for performing accounts payable duties against the US business unit.

Authorization Policy Manager (APM) is available in Oracle Fusion Applications through integration with Oracle Identity Management (OIM). Authorization policy management involves managing duty roles, data role templates, and data security policies, as well as previewing data roles generated based on data role templates.



Please provide your valuable feedback ............

Oracle Fusion Differences in Security Terminology: Explained


In some cases, terminology used within and outside of Oracle Fusion Applications differs based on vantage point. For example, Oracle Fusion Middleware and Oracle Application Access Control Governor provide a foundation that is integrated with, but external to, the Oracle Fusion Application suite.
The table shows how Oracle Fusion Applications, Oracle Fusion Middleware, Oracle Application Access Control Governor, and some possibly coexistent applications refer to various equivalent elements of security.
_________________________________________________________________________________
Note: Oracle Authorization Policy Manager and Oracle Identity Management are in Oracle Fusion Middleware, and Oracle Application Access Controls Governor is in Governance, Risk, and Compliance Controls.
_________________________________________________________________________________


The equivalencies are true in general and based on the functional meaning of the terms. In the table, an empty cell indicates that no equivalent term exists.


Please provide your valuable feedback ............

Wednesday, September 06, 2017

Oracle Fusion Define a Reference Set

Define a Reference Set


Use the implementation project and reference data set to control and manage the setup tasks involved in defining Financials.
Ø  Open the implementation project.
Ø  Select the Financials offering for the implementation project.
Ø  Save and open the implementation project.
Ø  Drill down to the Manage Reference Data Sets page.
Ø  Create a new reference data set


   


Ø  Common: Used globally across the organization as a common set. Add the Common Set to the global Receivables Payment Terms, Net 30 or Net 60, to be used in all business units.
Ø  Shared: Used by a few business units, US: Health and USA 2, that work with similar data and therefore share the sets. Add the Shared Set to Receivables Payment Terms, Net 15 or Net 20, that are defined by country or region where a few business units belonging to that country or region use it.
Ø  Enterprise specific: Unique to that business unit and not shared by any other business unit within that organization. Add the Enterprise Set to the Receivables Payment Term, Prepayment, defined by line of business and used only by that line of business irrespective of the country or region where it operates.




Please provide your valuable feedback ............