Tuesday Feb 10, 2015

Introducing Oracle Fusion Applications Security Management Role Optimization

Girish Ananatharaju, Fusion Applications Functional Architecture Principal Product Manager, hosted a Customer Connect webinar in January, 2015, announcing Applications Security Management Role Optimizer, available in Release 9 of Fusion Applications. Role Optimizer will enable security administrators and managers to more effectively control and manage Fusion Application security policies. Over time, an organization's security policies tend to grow increasingly complex due to any number of legitimate business reasons such as changes in the personnel managing the security polices or the addition of duplicate privileges for ease of administration. Role Optimizer helps address these issues by providing an optimized view of the policy store related to Fusion Applications. Role Optimizer generates suggestions to reorganize duty roles based on privilege cluster analysis done on the entire user, job/duty role and privilege data set.


Figure 1: Role Optimizer performs a cluster analysis.


Figure 2: Role Optimizer generates suggestions based on the cluster analysis.

The Role Optimizer feature is delivered as an ESS (Enterprise Scheduler Service) job in Release 9. This job generates reports containing optimized views of privilege associations from which customers can modify the job role hierarchy and associated privileges. Role Optimizer can be executed by users with IT_SECURITY_MANAGER privileges and is available as a value added service with additional subscription fees.

Check out the Customer Connect event (click here) for more information about and a demonstration of Role Optimizer. You can also review product documentation (click here) and the pending U.S. patent application (click here) for additional details on how role optimization is achieved.

Monday Jan 26, 2015

Introduction to Oracle Fusion Applications Security on Applications Customer Connect

At a recent Customer Connect web event, held in January, 2015, Mahesh Sabapathy, Fusion Applications Functional Architecture Senior Architect, presented the launch of Oracle Fusion Applications Security, new in Fusion Applications Release 9. Oracle Fusion Applications Security allows the security administrator to have a single global view of security, shape security to align with business needs and stay ahead of changes. In this presentation, participants learn how the Security Console can assist security administrators:

  • Use a single, simplified and intuitive user-interface to design and modify roles
  • Design roles using copy role and compare roles
  • Find things quickly by performing faceted search across the entire security model
  • See applications menu and task-pane entries authorized to a user or role.

Here is a sampling of some of the content presented during the event.
Figure 1: Visualization shows the Duty Roles and Privileges inherited by the Talent Worker Duty Role


Figure 2: Navigator Simulation allows security administrators to preview menu access for Users and Roles

Check out the Customer Connect event recording (click here) for additional information and a demonstration of the Security Console.

Friday Nov 21, 2014

Role Customization Best Practices

Fusion Applications Functional Architecture has recorded a Customer Connect webinar to discuss Role Customization Best Practices. This webinar covers the basics of the Fusion Applications Reference Implementation of job roles and duty roles, as well as best practices job role customizations and duty role customizations.


Figure 1: Fusion Applications Reference Implementation of Enterprise Roles and Duty Roles

In general, customers are advised to follow these best practices:
  • Always create custom job and abstract roles
  • Use seeded duty roles to grant authorizations to custom roles
  • If seeded duty roles need to be customized, there are two options:
    • Option 1 - simple; minimal risks
      • Take csv backup for reference and error recovery
      • Modify seeded function policies
      • End Date seeded data policies
      • Create custom data policies
    • Option 2 - difficult; no risks
      • Create custom duty roles

For more information on Role Customization Best Practices including links to the webinar and presentation material, visit the event page on Customer Connect (click here; user account required to access).

Friday Nov 07, 2014

Fusion Applications Security Management Directions Make the Rounds at ISACA and Oracle Open World

Nigel King, Vice President of Functional Architecture for Fusion Applications, continues to spread the word on the how Fusion Applications set the bar on security management for cloud based applications. Following up on an earlier presentation to the San Francisco chapter of ISACA on key security principles (click here), Nigel discussed Fusion Applications' comprehensive security management strategy and solution to sold out room at the 2014 SF ISACA Fall Conference, the premier education event for information technology audit, security, governance, risk and compliance professionals in Northern California.


2014 SF ISACA Fall Conference

At Oracle Open World, Nigel identified key principles of security management, discussed evolving best practices for role design and administration and demonstrated how the activities of an IT security manager are surfaced in Oracle Fusion Applications in the the new Security Console work area -- the one-stop shop for Oracle Fusion Applications security administration.


Security Console - New in Fusion Applications Release 9


Role Optimization provides the intelligence for design better roles

Look for in-depth training on Security Console and Role Optimization to be published by Oracle University in early 2015.

Wednesday Jul 02, 2014

Oracle Fusion Applications Cloud Security Takes Center Stage at ISACA

ISACA (previously known as the Information Systems Audit and Control Association) is an independent, nonprofit, global association, engages in the development, adoption and use of globally accepted, industry-leading knowledge and practices for information systems. In May 2014, Oracle co-hosted an event with the San Francisco Chapter of ISACA at the Oracle Conference Center to discuss audit and security best practices for applications and databases.

Nigel King, Vice President of Functional Architecture for Fusion Applications, delivered a presentation addressing how ten key security principles are implemented in modern cloud-based applications and demonstrated how these principles are adhered to in Fusion Applications. These principles include:
  1. Role Based Access
  2. Account and Role Provisioning Events & Workflows
  3. Enforcement Across Tools and Transformations
  4. Pervasive Privacy Protections
  5. Integration with Governance Risk and Compliance
  6. Transparent Security Policies
  7. Complete Audit of Security Changes
  8. Secure Across the Information Lifecycle
  9. Co-existing with your current Security Infrastructure
  10. Comprehensive Extensible Reference Implementation

Security in Fusion Applications
 Figure 1: Security in Fusion Applications

Paul Needham, Senior Director of Product Management for Oracle Database Security, discussed how Oracle is at the forefront of database security innovation. Among the latest Oracle Security Solution are:
  • Preventative: Transparent data encryption; Redaction of sensitive data displayed; Masking data for non-production use
  • Detective: New conditional auditing framework; Audit, report and alert in real-time; Database activity monitoring and firewall
  • Administrative: Configuration management; Discover use of privileges and roles

Oracle Database Security
Figure 2: Oracle Database Security

Check out both presentations for more information.

Wednesday Jun 12, 2013

How to customize the user experience in Fusion Apps - Part 1 Composer Security Expressions



Access to resources such as taskflows, regions, buttons, and menus in Fusion Applications is granted by entitlements stored in a policy store and managed through the Authorization Policy Manager (APM).  Users are assigned roles comprised of  a set of entitlements (Oracle makes this quite easy  by providing you with job based seeded roles) authorizing them to  access  only the data and functions neccessary to perform their jobs and no more. On a more granular level it is also possible to control the rendering of certain UI objects by controlling their display attribute at runtime using Page Composer.

An example illustrating a conditional rendering of a Button is outlined below. The condition used in this example is the Role of the authenticated user.

2 Users and 2 Roles

In this example we have two HR Specialists, we want to prevent one of these users from saving Person records.

Figure1 Roles of Louise Beckham

Figure2. Roles of Megan Davis

Customizing the Object

Using Page Composer, the Administartor creates a security condition in Expression Builder. This condition states that the "Save" field on the "Person Management" page will be displayed if and only if the session authenticated user has the PER_HUMAN_RESOURCE_SPECIALIST_VIEW_ALL_DATA role. This happnes to be a role that our user Megan Davis has but that has not been granted to user Louise Beckham.

The statement, written in Expression Language (EL), used in this example is

#{securityContext.userInRole['PER_HUMAN_RESOURCE_SPECIALIST_VIEW_ALL_DATA']}

NB: It is possible to have a include multiple roles as follows: #{securityContext.userInRole['Role 1'||'Role2']}, it is also possible to exclude a role by include a '!' at the beginning of the expression as follows: #{!securityContext.userInRole['Role 1']}


Figure3. Selecting the ADF Object that we want to customize


Figure4. Creating a dynamically calculated attribute value using Expression Builder

Different Display for Different Users

Below is how each of our two users sees the same UI that has now been conditionally customized. We can see the "Save" button displayed on Morgan's UI but not on Louise's.

Figure 5 - .Louise's UI without the Save Button

Figure 6.Megan's UI with the Save Button


Wednesday Mar 27, 2013

Managing Workflow Notifications in Fusion Apps – An Example

This article illustrates an example of a system administrator viewing and taking action on SOA Human Workflow notifications generated by a composite process that underlies a Fusion Apps HCM Task. As part of the privileges granted by their enterprise role, the administrator is able for example to reassign, suspend, or withdraw the requested action in the task.

What is a Human Workflow?

Human Workflow is the component of Oracle’s SOA suite that allows humans to interact with a process. For example a manager might need to approve a purchase order or an expense report prior to the transaction (issuing a purchase order or reimbursement of expenses) being completed or perhaps to reassign a task they are unable to complete. In addition to allowing users of an application to interact with its processes, the capabilities of the Human Workflow include full task lifecycle management through the ability to reroute tasks, escalate them, and providing deadlines by which they must be completed, in addition to the presentation of tasks to the concerned user through the BPM Worklist application or other channels such as email.


The Task and its Rules

In our example we will use a Fusion HCM Transaction example to illustrate how a transaction is routed and what actions an administrator can take on that transaction.

The Table below lists Fusion Core HCM transactions that are enabled for approvals.

Seeded Approvals (Include 2 Levels of Supervisor chain)

Seeded Auto-Approved

Transfer

Manage Salary (typically configured to require approval)

Promotion

Manage Compensation (typically configured to require approval)

Change Manager

Share Information (requires approval by worker)

Change Location

Change Marital Status

Change Working Hours

Create Employment Terms

Terminate Work Relationship

Manage Employment

Hire an Employee

Manage Grades

Add a Non-worker

Manage Grade Ladders

Add a Contingent Worker

Manage Grade Rates

Add a Pending Worker

Manage Jobs

Create Work Relationship

Manage Locations

Manage Work Schedule Assignment

Manage Organizations

Manage Absence Records (1 level)

Manage Person

Manage Document Record (1 level)

Manage Positions

Submit Performance Document(1 level)


Add Goal (1 level)


Table 1.Fusion HCM Transactions


Let us start by looking at the Promotion Task and the rules associated with that task.

Figure 1 shows the composite process that handles the HCM Promotion task. This composite consists of several SOA components and includes the services and references in Figure 2.

2.tiff

Figure 1.Deployed Promotion Approvals Composite processes.

3.tiff

Figure2. Components of the Promotion Approval Composite

In Figure 3 below, the rule defined reads as follows: For the promotion process and for all cases (the condition 1=1 being always true) build the approval list based on the supervisory hierarchy and process the transaction two levels above the approver, starting with the approver’s manager and stopping with the user “douglas.mcneil” who happens to also be the CEO and the top node in the hierarchy.

Figure3. BPM Task Configuration Rules

The Administrator’s privileges

In Fusion Applications the ability to access functions across products is controlled by functional privileges granted to a user through APM (Access Provisioning Manager). The application role that allows an administrator to view all human tasks is “BPM Workflow System Admin Role”. Several of the seeded roles in the reference implementation inherit this duty. The table below shows the hierarchy for the Human Capital Management Application Administrator.

Level

Display Name

Role Name

Description

Inherited by

1

Human Capital Management Application Administrator

HRC_HUMAN_CAPITAL_

MANAGEMENT_APPLICATION_ADMINISTRATOR_JOB

Configures the Oracle Fusion Global Human Resources application and has access to all duty roles necessary to implement the Compensation, Workforce Deployment, and Workforce Development offerings.


2

BPM Workflow System Admin Role

BPMWorkflowAdmin

This role grants a user the privilege to perform administrative actions in the workflow functionality via the worklist UI. A user in this role will be able to view all tasks in the system, recover errored (incorrectly assigned) tasks, create approval groups and edit task configuration / rules DT@RT UI (both AMX functionality) This is a business administrator type role. This role is granted to SOAAdmin.

1

Table 2.Seeded Roles that provide access to all Tasks in the Worklist application

4.tiff

Figure4. Role hierarchy assigned to the administrator for the example in this document

The HCM Transaction

At the conclusion of a performance evaluation cycle, a manager determines that an employee is a candidate for a promotion. The Manager initiates the request from the Manager Resources Dashboard. The necessary adjustments are made to the employee’s Job, and Compensation details and the transaction is submitted.

7.tiff

Figure5a. Supervisory Hierarchy: Donald Alexander reports to Douglas McNeil

8.tiff

Figure5b. Supervisory Hierarchy: Stella Marcus reports to Donald Alexander

9.tiff

Figure5c. Supervisory Hierarchy: Jaime Gregg reports to Stella Marcus

Figures 5a, 5b, 5c show three levels in the supervisory hierarchy, the transaction we will use in our example below will be submitted for employee Jamie Gregg, and will be submitted by Stella Marcus her manager. Based on the approval rules we had defined earlier this promotion request will be routed to the next two levels in the hierarchy in sequence to Donald Alexander then Douglas McNeil.

The manager selects the Promote Action from the employee’s card in the Org chart

10.tiff

Figure6. The Manager Selects the Promote Action from the Org Chart.

The Manager Completes the promotion request and reviews the details prior to submission. The approval list is built in the last step of the transaction as illustrated in Figure 7a and 7b below.

11.tiff

Figure7a. There last step in the transaction is the review of the request prior to submission

12.tiff

Figure7b. The Approval list built in the last step of the transaction prior to submission.

Initiated transactions generate an instance of the composite process discussed earlier (see Figure 8 below) , and are available to the participants and administrator. The instance also retains the status and history of the transactions during its lifecycle and after completion.

13.tiff

Figure 8. TheTask instance in the Worklist of the Manager

After submission, the manager can review the initiated task and amend it by adding attachments or comments as seen in Figure 9 below.

Figure 9. Comments and Attachments added to the request

The Notification

Based on the rules applicable to the promotion transaction we discussed earlier, the process sends a request for approval to the manager of the requestor. However let us assume that Donald Alexander the manager of Stella Marcus and the the first of the two approvers is not available to take an action on the request. Stella makes a request via the comments field to have the administrator to skip the current stage and forward the request to the next approver.

The Administrator Action

The administrator Kyle Bailey searches for transactions assigned to Donald Alexander (Figure 10) and can perform the actions listed in Figure 11 namely skip the current assignment, suspend , withdraw or reassign the request to a different user .

16.tiff

Figure 10. Administrator queries tasks assigned to Donald Alexander

17.tiff

Figure 11. Actions an administrator can take on an assigned task

After reassignment of the task by the administrator to the next approver, Douglas McNeil can now see the Task in their worklist.

19.tiff

Figure 12. Worklist of the user to whom the task was reassigned

All changes made to to a task instance remain with the task and are viewable by all users who have access to that task namely the participants in the transaction (the approvers) and the administrator. A completed task with a full history of task actions and the participants who made them is shown in Figure 13 below.

20.tiff

Figure 13.Completed Task

References

Oracle® Fusion Middleware Developer's Guide for Oracle SOA Suite11g Release 1 (11.1.1) Part Number E10224-05 -- Chapter 27


Oracle SOA Suite Components



Tuesday Dec 04, 2012

How to Modify Data Security in Fusion Applications




The reference implementation in Fusion Applications is designed with built-in data security on business objects that implement the most common business practices.  For example, the “Sales Representative” job has the following two data security rules implemented on an “Opportunity” to restrict the list of Opportunities that are visible to an Sales Representative:

  • Can view all the Opportunities where they are a member of the Opportunity Team
  • Can view all the Opportunities where they are a resource of a territory in the Opportunity territory team

While the above conditions may represent the most common access requirements of an Opportunity, some customers may have additional access constraints.
This blog post explains:

  1. How to discover the data security implemented in Fusion Applications.
  2. How to customize data security
  3. Illustrative example.

a.) How to discover seeded data security definitions


The Security Reference Manuals explain the Function and Data Security implemented on each job role.  Security Reference Manuals are available on Oracle Enterprise Repository for Oracle Fusion Applications.
The following is a snap shot of the security documented for the “Sales Representative” Job. The two data security policies define the list of Opportunities a Sales Representative can view.

Here is a sample of data security policies on an Opportunity.

Business Object

Policy Description

Policy Store Implementation

Opportunity

A Sales Representative can view opportunity where they are a territory resource in the opportunity territory team

Role: Opportunity Territory Resource Duty
Privilege: View Opportunity (Data)
Resource: Opportunity


A Sales Representative can view opportunity where they are an opportunity sales team member with view, edit, or full access

Role: Opportunity Sales Representative Duty
Privilege: View Opportunity (Data)
Resource: Opportunity

Description of Columns


Column Name

Description

Policy Description

Explains the data filters that are implemented as a SQL Where Clause in a Data Security Grant

Policy Store Implementation

Provides the implementation details of the Data Security Grant for this policy.
In this example the Opportunities listed for a “Sales Representative” job role are derived from a combination of two grants defined on two separate duty roles at are inherited by the Sales Representative job role.

b.) How to customize data security


Requirement 1:
Opportunities should be viewed only by members of the opportunity team and not by all the members of all the territories on the opportunity.

Solution:
Remove the role “Opportunity Territory Resource Duty” from the hierarchy of the “Sales Representative” job role.
Best Practice:
Do not modify the seeded role hierarchy.
Create a custom “Sales Representative” job role and build the role hierarchy with the seeded duty roles.

Requirement 2:
Opportunities must be more restrictive based on a custom attribute that identifies if a Opportunity is confidential or not.
Confidential Opportunities must be visible only the owner of the Opportunity.

Solution:
Modify the (2) data security policy in the above example as follows:
A Sales Representative can view opportunity where they are a territory resource in the opportunity territory team and the opportunity is not confidential.
Implementation of this policy is more invasive. The seeded SQL where clause of the data security grant on “Opportunity Territory Resource Duty” has to be modified and the condition that checks for the confidential flag must be added.
Best Practice:
Do not modify the seeded grant.
Create a new grant with the modified condition.
End Date the seeded grant.


c.) Illustrative Example (Implementing Requirement 2)


A data security policy contains the following components:

  • Role
  • Object
  • Instance Set
  • Action

Of the above four components, the Role and Instance Set are the only components that are customizable. Object and Actions for that object are seed data and cannot be modified.
To customize a seeded policy, “A Sales Representative can view opportunity where they are a territory resource in the opportunity territory team”,

  1. Find the seeded policy
  2. Identify the Role, Object, Instance Set and Action components of the policy
  3. Create a new custom instance set based on the seeded instance set.
  4. End Date the seeded policies
  5. Create a new data security policy with custom instance set

c-1: Find the seeded policy


Step 1:
1. Find the Role
2. Open
3. Find Policies


dif1.jpg


Step 2:

  1. Click on the Data Security Tab
  2. Sort by “Resource Name”
  3. Find all the policies with the “Condition” as “where they are a territory resource in the opportunity territory team

dif2.jpg

In this example, we can see there are 5 policies for “Opportunity Territory Resource Duty” on Opportunity object.


Step 3:

Now that we know the policy details, we need to create new instance set with the custom condition.
All instance sets are linked to the object.

  1. Find the object using global search option. Open it and click on “condition” tab
  2. Sort by Display name
  3. Find the Instance set
  4. Edit the instance set and copy the “SQL Predicate” to a notepad.
  5. Create a new instance set with the modified SQL Predicate from above by clicking on the icon as shown below.

dif2.jpg

Step 4:


End date the seeded data security policies on the duty role and create new policies with your custom instance set.

  1. Repeat the navigation in step
  2. Edit each of the 5 policies and end date them

dif2.jpg

3. Create new custom policies with the same information as the seeded policies in the “General Information”, “Roles” and “Action” tabs.

4. In the “Rules” tab, please pick the new instance set that was created in Step 3.

dif2.jpg


Friday Sep 07, 2012

How to Secure a Data Role by Multiple Business Units

In this post we will see how a Role can be data secured by multiple Business Units (BUs).  Separate Data Roles are generally created for each BU if a corresponding data template generates roles on the basis of the BU dimension. The advantage of creating a policy with a rule that includes multiple BUs is that while mapping these roles in HCM Role Provisioning Rules, fewer number of entires need to be made. This could facilitate maintenance for enterprises with a large number of Business Units.

Note: The example below applies as well if the securing entity is Inventory Organization.

Let us take for example the case of a user provisioned with the "Accounts Payable Manager - Vision Operations" Data Role in Fusion Applications. This user will be able to access Invoices in Vision Operations but will not be able to see Invoices in Vision Germany.

dif1.jpg

Figure 1. A User with a Data Role restricting them to Data from BU: Vision Operations


With the role granted above, this is what the user will see when they attempt to select Business Units while searching for AP Invoices.

dif2.jpg

Figure 2.The List Of Values of Business Units is limited to single one. This is the effect of the Data Role granted to that user as can be seen in Figure 1

In order to create a data role that secures by multiple BUs,  we need to start by creating a condition that groups those Business Units we want to include in that data role.

This is accomplished by creating a new condition against the BU View .  That Condition will later be used to create a data policy for our newly created Role. 

The BU View is a Database resource and  is accessed from APM as seen in the search below

dif2.jpg

Figure 3.Viewing a Database Resource in APM

The next step is create a new condition,  in which we define a sql predicate that includes 2 BUs ( The ids below refer to Vision Operations and Vision Germany). 

At this point we have simply created a standalone condition.  We have not used this condition yet, and security is therefore not affected.

dif2.jpg

Figure 4. Custom Role that inherits the Purchase Order Overview Duty

We are now ready to create our Data Policy.  in APM, we search for our newly Created Role and Navigate to “Find Global Policies”.  we query the Role we want to secure and navigate to view its global policies.

dif2.jpg

Figure 5. The Job Role we plan on securing

We can see that the role was not defined with a Data Policy . So will create one that uses the condition we created earlier.  


dif2.jpg

Figure 6. Creating a New Data Policy

In the General Information tab, we have to specify the DB Resource that the Security Policy applies to:  In our case this is the BU View

dif2.jpg

Figure 7. Data Policy Definition - Selection of the DB Resource we will secure by

In the Rules Tab, we  make the rule applicable to multiple values of the DB Resource we selected in the previous tab. 

This is where we associate the condition we created against the BU view to this data policy by entering the Condition name in the Condition field

dif2.jpg

Figure 8. Data Policy Rule

The last step of Defining the Data Policy, consists of  explicitly selecting  the Actions that are goverened by this Data Policy.  In this case for example we select the Actions displayed below in the right pane. Once the record is saved , we are ready to use our newly secured Data Role.


dif2.jpg

Figure 9. Data Policy Actions

We can now see a new Data Policy associated with our Role. 

dif2.jpg

Figure 10. Role is now secured by a Data Policy

We now Assign that new Role to the User.  Of course this does not have to be done in OIM and can be done using a Provisioning Rule in HCM.

dif2.jpg

Figure 11. Role assigned to the User who previously was granted the Vision Ops secured role.

Once that user accesses the Invoices Workarea this is what they see:

In the image below the LOV of Business Unit returns the two values defined in our data policy namely: Vision Operations and Vision Germany

dif2.jpg

Figure 12. The List Of Values of Business Units now includes the two we included in our data policy. This is the effect of the data role granted to that user as can be seen in Figure 11


Tuesday Aug 07, 2012

How to Create a View Only Role in Fusion Applications

Fusion Applications are packaged with a seeded Role Based Access Control reference implementation consisting of over 180 Roles that represent a wide variety of enterprise business job functions. In certain cases, customers have within their organizations auditor roles that assume oversight responsibilities over transactional systems and require View Only access to various system transactions. This POST aims to show an example of how such a Role can be defined.

We will use the Procurement Applications as an example of how View Only Roles are defined in Fusion Applications.  It should be noted that the ability to do the same type of setup in other product families depends on the availability within those products of duties similar to the ones we will use in this example to model of our View Only Role.

Procurement Agents in Fusion Applications are primarily responsible for the generation and management of purchasing documents such as purchase orders and purchasing agreements. Depending on their roles they could also be responsible for the management of the RFx process and the awarding of supply contracts.

 Fusion Procurement provides the following Agent RBAC seeded roles

Seeded Role

Description

Buyer

Procurement professional responsible for transactional aspects of the procurement processes.

Category Manager

Procurement professional responsible for identifying savings opportunities, determining negotiation strategies, creating request for quote, request for information, request for proposal, or auction events on behalf of their organization and awarding future business typically in the form of contracts or purchase orders to suppliers.

Procurement Manager

Procurement professional responsible managing a group of buyers in an organization.

Procurement Application Administrator

Responsible for technical aspects of keeping procurement applications systems available as well as configuring the applications to meet the needs of the business.

Procurement Catalog Administrator

Manages agreements and catalog content including catalogs, category hierarchy, content zones, information templates, map sets, public shopping lists, and smart forms.

Procurement Contract Administrator

Procurement professional responsible for creating, managing, and administering procurement contracts.

In addition to the Agent Roles listed above, Fusion Procurement provides:

  • Requester Roles provisioned to Employees and Contingent Workers to create requisitions for themselves or for others.
  • External Supplier Roles provisioned to Supplier Users.

The main Purchasing Duties and their corresponding Privileges are listed below.  The highlighted entries represent the seeded View Only Duty and Privileges.  In order to create a View Only Role we will need to have our custom Role inherit this Duty to the exclusion of other Duties which provide broader access to Purchasing Functionality.

DUTIES

PRIVILEGES

Purchase Order Administration Duty

Communicate Purchase Order and Purchase Agreement


Generate Purchase Order


Import Purchase Order


Purge Purchasing Document Open Interface


Reassign Purchasing Document


Retroactively Price Purchase Order

Purchase Order Changes Duty

Change Purchase Order


Communicate Purchase Order and Purchase Agreement

Purchase Order Control Duty

Acknowledge Purchase Order


Cancel Purchase Order


Change Purchase Order Line Negotiated Flag


Change Supplier Site


Close Purchase Order


Finally Close Purchase Order


Freeze Purchase Order


Hold Purchase Order

Purchase Order Creation Duty

Cancel Purchase Order


Create Purchase Order


Create Purchase Order from Requisitions


Create Purchase Order Line from Catalog

Purchase Order Creation from Requisition Lines Only Duty

Cancel Purchase Order


Create Purchase Order from Requisitions

Purchase Order Overview Duty

Search Purchase Order


View Purchase Order


View Purchasing Workarea

Purchase Order Viewing Duty

View Purchase Order


Case Study

Introduction

This example illustrates the process of creating a View Only Role for a procurement auditor.

Before we outline the setup steps, let us examine the Menu entries available in the Fusion Navigator to a user with the Buyer Role.

dif1.jpg

Figure 1. Menu Items of a User Provisioned with the Buyer Role


The figure above traces the Menu Items available to the Buyer Role to the Privileges contained in their assigned Duties.  The Buyer however has several additional Duties that provide access to multiple tasks as seen in the Figure 2 illustrating the Purchasing Workarea‘s Tasklist in the left pane of the page.
Of note also is the list of Actions that the Buyer can take on a Purchasing Document, notably the creation of a Document as seen in Figure 2 and the Editing Actions seen in Figure 3

dif2.jpg

Figure 2. Tasklist and Actions in the Purchasing Workarea for a User Provisioned with the Buyer Role

dif2.jpg

Figure 3. Available Actions on a Purchasing Document for a  User Provisioned with the Buyer Role

The View Only Role

We will now proceed to create a custom View Only Role that inherits the Purchase Order Overview Duty and provision that Role which we will name ECW Purchasing Only Role to a user who serves as the auditor in the enterprise.
Figure 4 shows the Custom Role in the Authorization Policy Manager Dashboard.

dif2.jpg

Figure 4. Custom Role that inherits the Purchase Order Overview Duty

Once the Role is created and the hierarchy mapped, our next step is to assign that Role to a user through the HCM Manage Users task.

Figure 5 below shows the provisioned role in the Oracle Identity Manager dashboard. 

dif2.jpg

Figure 5. Assigned View Only Role visible in OIM

To allow access to purchasing documents, we need to define the user as a purchasing agent and determine that user’s access to procurement business units and within these business units to determine the level of access the user will have to purchasing documents

dif2.jpg

Figure 6. Agent Setup

The auditor user is now ready to use the system to view purchase orders. As we can see in the following three figures, the user has the Purchasing Menu item in their Fusion Navigator but are not able to either create or edit any of the purchasing document they can view.

dif2.jpg

Figure 7. Navigator Menu Items for the Auditor user

dif2.jpg

Figure 8. No Create Document capability for the Auditor user

dif2.jpg

Figure 9. No Edit  Document capability for the Auditor user

Additional Considerations

The Manage Orders task in the Purchasing workarea points to the following taskflow:


/WEB-INF/oracle/apps/prc/po/manageDocument/publicUi/searchDocument/flow/PurchaseOrderSearchMainFlow.xml#PurchaseOrderSearchMainFlow


This taskflow is one of the resources available in the Search Purchase Order Privilege itself included in the Purchase Order Overview Duty  we have assigned to our custom role and which is also in the hierarchy of the Buyer Role.  This explains the availability of the Manage Orders Entry for both users referenced in this document.

dif2.jpg

Figure 10. Search Purchase Orders Privilege

On the other hand, creating purchase orders is available to the Buyer role but not to our custom role.  Of the two roles outlined in this case study section of this document, only the Buyer role has in its hierarchy the Purchase Order Creation Duty. This explains why the user with the Buyer role can create orders but the user with our custom role cannot.

dif2.jpg

Figure 11.  Create Purchase Order Privilege

Conclusion

In this document we have shown how to create a view only role for an auditor of purchasing documents. We were able to do so without the creation of new privileges or the manipulation of resources but simply by creating a custom role and assigning to it an existing view only duty. In the reference implementation, the view only duty we used is available to many roles within and outside of Procurement; however these roles have other duties that might not be relevant to a procurement auditor.

Your feedback is welcome

We are very interested in hearing about your experiences with this new tool.  Please post your comments below


Resources
  • “Roles, Duties & Privileges” My Oracle Support  (Note 1460486.1)

  • “Menu to privilege mapping” My Oracle Support (Note 1459828.1)

Wednesday Jul 25, 2012

Tools that help you design Roles in Fusion Applications

Role Based Access Control (RBAC) is the basis for Fusion Applications security.  Fusion Applications include a reference implementation of RBAC consisting of  over 180 Job Roles across its product families. In turn, each of these Job Roles is composed of  a collection of role centered privileges known as Duties that grant access to Applications functionality.  Fusion Applications customers can start by evaluating these predefined Job Roles and mapping them to roles in use in their enterprise.

In cases where a direct one to one mapping is not possible, customers can create their own custom roles and either aggregate a set of Job Roles ( in cases where Job Roles are too restrictive in the Duties they provide) or add a select subset of Duties from a Job Role (in cases where a Job Role grants more access than is required in the enterprise).

The Functional  Architecture  team released two documents to assist customers in modeling their enterprise roles. The first document provides a comprehensive map of the content and relationships in the reference implementation, and the second is intended to help customers who are assessing the needed menu items for their roles, understand the underlying privileges that make these menu items available in the Fusion Applications Navigator  . Both documents are in a Excel format at the request of customers who have indicated their preference for a filterable spreadsheet format.

Excel spreadsheet format of "Roles, Duties & Privileges" available via MOS Note 1460486.1

View of Event

Menu to privilege mapping currently available as a spreadsheet via MOS Note 1459828.1

View of Event

About

This blog shares with the broader Fusion Applications community instructional material in the areas of Enterprise Structures, Extensibility, Integration and Security with the a focus on implementation. This blog is updated by the Fusion Applications Functional Architecture organization.

Search

Archives
« July 2015
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
       
Today