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.

Friday Nov 21, 2014

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.

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).

Wednesday Jul 02, 2014

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:

Role Based Access

Account and Role Provisioning Events & Workflows

Enforcement Across Tools and Transformations

Pervasive Privacy Protections

Integration with Governance Risk and Compliance

Transparent Security Policies

Complete Audit of Security Changes

Secure Across the Information Lifecycle

Co-existing with your current Security Infrastructure

Comprehensive Extensible Reference Implementation

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:

Monday Mar 24, 2014

In a recent Customer Connect webcast on "Auditing Capabilities in Oracle Applications Cloud" (presentation; replay), questions were raised on how the existing audit functions offered using the Applications Audit Framework (also known as the APPLCORE Audit Framework) can be leveraged to audit the read access or selects made on specific objects and/or entities. While the Applications Audit Framework captures the insert, update or delete operations (also known as DML operations) on Fusion Business Objects, the select and read accesses on these objects can be captured using Oracle Audit Vault.

Oracle Audit Vault is a separately licensed security product — certified for Fusion Applications — that gathers auditing information from remote databases and stores it in a single centralized warehouse database. It can help customers to comply with Sarbanes-Oxley (SOX) and other regulations, perform proactive monitoring and mitigate security risks.

Oracle Audit Vault can be of immense value for organizations when their IT policies demand tighter access control to the applications, especially in situations:

When every database change must be captured

When business objects, not addressed currently by Applications Audit Framework, need to be audited

When read access and SELECT statements need to be audited

For more information on Oracle Audit Vault and its capabilities, please review the Oracle Audit Vault Datasheet (click here).

Tuesday Dec 10, 2013

Release 7 of Fusion Applications provides the much needed functionality of auditing, leveraging the Fusion Middleware auditing capabilities. The functionality provided in this release covers the auditing of various applications business objects and the Fusion middleware components, including the below:

Fusion Applications Business Objects

Oracle SOA Suite –SOA Metadata Customizations

Pages and Business Objects Extensibility

BI Publisher – Report request, report execution, etc.

ODI, ESS, MDS, OPSS

In Release 7, the audit framework provided covers both capturing and reporting the audit events. Business objects or events to be audited can be configured using Manage Audit Policies in Fusion Applications while the reporting on these captured audit events is facilitated using Audit History UI. Users with appropriate roles will be able to configure (Manage Audit Policies with Application Administrator Job Role) and view these reports (Audit History UI with Internal Auditor Job Role).

The following Oracle University sessions provide a detailed overview of the auditing functionality available in Fusion Applications.

Tuesday Sep 03, 2013

Introduction

This article is intended for Fusion Apps customers either starting out on their implementation or who are facing Lightweight Directory Access Protocol (LDAP) reconciliation issues. The content of this article relates to Release 5 (11.1.5) and later versions of Fusion Apps.

Background

Oracle Fusion Applications rely on Oracle Identity Management Products to manage Users, Roles and Permissions. Application users are created by using the Hire Employee task within the Fusion HCM Core application. The Hire Employee task creates User(s) and Role(s) entries in the underlying identity store through Oracle Identity Manager (OIM). It may be Active Directory (AD) or Oracle's Internet Directory (OID) or any combination of those.

Although the users can be managed inside the Fusion HCM application, it is worthwhile to understand the process of synchronizing between HCM, LDAP store and Oracle User and Role entries within OIM to support environment setup & validation.

LDAP Reconciliation

User creation in Fusion Apps is a business process that spans across both Core HCM and OIM. The creation of users happens slightly differently depending on whether the person is uploaded via File Based Loader (FBL) or manually entered in the UI.

For Persons loaded via FBL, the username and the status will both show as pending until the ‘Send Pending LDAP Requests’ process is run -- regardless of the hire date. Only those requests of current date or earlier will be picked up. This ‘Send Pending LDAP requests’ will result in new users being created in OIM.

For Persons created via the Fusion HCM ‘Manage Users’ UI, if you do not have the ‘Send Pending LDAP Requests’ scheduled then you can use the ‘Copy Data to LDAP’ button. You can only create users where the hire date is the current date, not users with future hire dates.

The ‘Copy Data to LDAP’ button on the UI will not work for users that are in a pending status. It only works for users that have been created.

If you are creating users manually using the Fusion HCM "Manage Users" screen, and running into issues, you may find this MyOracle Support troubleshooting article useful (Doc ID 1459830.1).

Running the above LDAP requests processing results in creation of user records in OIM and, depending on whether a OIM resource is configured with an SMTP server, email notifications are automatically sent (with user name and password) to the user if a valid work email address exists.

This process can be done only once so care should be taken not to run the process while the SMTP server is not configured - this would result in the inability to generate email notifications for new user creation. At the same time if the process is run too early and the organization is not ready to start using the system, emails will be generated to users with their credentials and could result in premature use of the system. For further information on enabling email notifications, please review the MyOracle Support article on HCM Cloud Service Definition: E-Mail Notifications (Doc ID: 1534683.1).

A copy of the email notification is also sent to the user’s manager. To prevent password notifications being sent to the users "manager", follow the instructions in this MyOracle Support article (Doc ID: 1487978.1).

From Release 5, it is possible to suppress user account creation and email notifications if so desired. Likewise, it is possible to suppress the assignment and removal of roles for all users.

Are there other LDAP Synchronization jobs to consider?

In fact the area of LDAP synchronization can be broken down into two areas:

Between Fusion HCM and OIM

Between OIM and the LDAP

Let us first take the flows between Fusion HCM and OIM:

‘Retrieve Latest LDAP Changes’ - Copies users and roles from LDAP to HCM User Management. The process requests from OIM any changes that may not have arrived because of a failure or error.

The section ‘‘Define Synchronization of Users and Roles from LDAP’ of the Oracle® Fusion Applications Common Implementation Guide explains that OIM maintains LDAP user accounts for users of Oracle Fusion Applications. Amongst other things, OIM also stores the definitions of abstract, job, and data roles and holds information about roles provisioned to users.

During an implementation, any existing information about users, roles, and roles provisioned to users must be copied from the LDAP directory to the Oracle Fusion Applications tables. Once the Oracle Fusion Applications tables are initialized with this information, it is maintained automatically.

To perform the initialization, the installation Fusion Apps super user should run the process ‘Retrieve Latest LDAP Changes’ (this is available via the ‘Run User and Roles Synchronization Process task, once an offering has been configured and a set up task list has been created). Once the ‘Retrieve Latest LDAP Changes’ process has been run, users can then be provisioned with roles through HCM. The process name appears as SyncRolesJob which was the process name for ‘Retrieve latest LDAP Changes’ in Fusion Apps 11.1.2 (and earlier versions).

‘Send Pending LDAP Requests’ – This process sends bulk requests and future-dated requests that are now active to OIM to create, suspend, and re-enable user accounts, as appropriate. It also identifies future-dated transactions and manages role provisioning and de-provisioning at the appropriate time.

For further details on how these two programs work, and when to schedule them, see ‘Synchronization of User and Role Information with Oracle Identity Management: How It Is Processed in the Oracle® Fusion Applications Coexistence for HCM Implementation Guide .

Secondly, let’s look at the reconciliation processes between OIM and LDAP. These jobs can be broken down into

a) full reconciliation processes:

LDAP User Create and Update Full Reconciliation

LDAP User Delete Full Reconciliation (Note: do NOT enable this job)

LDAP Role Create and Update Full Reconciliation

LDAP Role Hierarchy Full Reconciliation

LDAP Role Membership Full Reconciliation

LDAP Role Delete Full Reconciliation (Note: do NOT enable this job)

b) and incremental reconciliation processes:

LDAP User Create and Update Reconciliation

LDAP User Delete Reconciliation

LDAP Role Create and Update Reconciliation

LDAP Role Hierarchy Reconciliation

LDAP Role Membership Reconciliation

LDAP Role Delete Reconciliation

Fusion Applications Role Category Seeding

The incremental LDAP jobs are not enabled by default, as some prerequisite steps are needed to point these to OID. Note that the actual configuration of integration between Oracle Identity Manager and LDAP is performed while installing Oracle Identity Manager. For further information on how to configure the integration of OIM with LDAP please refer to Configuring the Integration with LDAP in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

MyOracle Support Doc ID 1377101.1 describes how to identify which jobs are currently enabled or disabled in your environment. It also reminds the reader that as part of the installation and configuration of OIM, the LDAP jobs should be run in a particular order.

The full reconciliation jobs, as opposed to the incremental jobs, put a significant load on the OIM CPU (about 40% CPU usage). Hence it is advisable to run these when the system is not being so actively used. Please reference to MyOracle Support Troubleshooting: OIM Out of Sync with LDAP (Doc ID 1467067.1) for guidance and further troubleshooting .

To view all OIM/LDAP reconciliation jobs directly in your system, login to OIM as follows:

Login to OIM console (as the OIM Superuser 'xelsysadmin')

Go to Advanced console

Click Search Scheduled Jobs, use wild card search LDAP*

To submit a job, simply click on, for example, LDAP Role Membership Full Reconciliation job

Click Run Now(If the Run Now button is greyed out, then click Disable first to disable scheduling and then you can click Run Now. Also remember to turn scheduling back on by clicking Enable after the job finishes).

What do these LDAP Synchronization jobs do exactly?

In general terms, these jobs ensure that HCM/OIM, and OIM and LDAP are in sync with each other. Without being synchronized, users may not be able to log into Fusion Applications because they are not in the identity store, so credentials cannot be verified. Data roles will not be visible in OIM after generating from the data role template until LDAP reconciliation has taken place.

The "LDAP Scheduled Tasks” link in the Oracle Fusion Middleware Administrator’s Guide for OIM, provides specific descriptions of each LDAP/OIM Reconciliation job. For example, the LDAP User Create and Update Reconciliation job reconciles user updates based on the change log from LDAP. The incremental reconciliation jobs make updates based on change logs. Compare these to the full reconciliation jobs, such as LDAP User Create and Update Full Reconciliation job, that reference all users under the search base (defined in the Directory Server IT resource) to do the reconciliation with the LDAP.

When and how often should I run these LDAP Synchronization jobs?

Retrieve Latest LDAP Changes process is always the first implementation task but can also be run periodically, say daily1, to keep the tables synchronized with subsequent updates to LDAP. For example, if you know that a failure has occurred between OIM and Oracle Fusion HCM, then you can run Retrieve Latest LDAP Changes to ensure that user and role information is synchronized.

It is recommended to run the Send Pending LDAP Requests process at least daily to ensure that future-dated changes are identified and processed as soon as they take effect. For example, you could schedule this process to automatically run daily.

For the LDAP/OIM reconciliation, it is generally recommended to run the full reconciliation (Job Name: LDAP Role Create and Update Full Reconciliation) periodically e.g. monthly, but run the incremental reconciliation (Job Name: LDAP Role Create and Update Reconciliation) more frequently in-between full reconciliations runs e.g. Daily or hourly.

Indeed, MyOracle Support Doc ID 1507370.1 recommends setting the incremental LDAP/OIM reconciliation jobs to run every 5 minutes or even more frequently, depending on your business needs, to avoid issues with asynchronous data from LDAP to OIM.

There are a number of articles on MyOracleSupport that provide guidance on LDAP issues. Generally speaking the cause of these issues are due to the LDAP reconciliation jobs not having been run, or not having been run in the correct order. Below are a few sample issues reported, included here as pointers for those who may be struggling to resolve an issue:

User and Role Provisioning - Troubleshooting Guide (Doc ID 1459830.1) Helpful as it walks through a number of issues and how to overcome them.

Fusion Applications - IT Security Manager Role Not Found In Oracle Identity Manager (Doc ID 1377101.1).

User Account In Pending Status In HCM Manage User Account Page After HR2HR Load (Doc ID 1571217.1). Highlights that if the creation date for a user is in the future, even after running the ‘Send Pending LDAP Requests process, the user create request only gets processed after reaching this creation date.

And Lastly…

Once you’re up and running and happily synchronizing, please do give a thought to tuning your LDAP Synchronization jobs. Review to the MyOracle Support articles on Performance Tuning Guidelines and Diagnostics Collection for Oracle Identity Manager (OIM) (Doc ID 1539554.1) and Tuning Settings For LDAP Reconciliation Between OID And OIM 11g (Doc ID 1534049.1) for more information.

Other useful links

How to Setup LDAP Sync After Install in OIM 11g (Doc ID 1272682.1) Explains how to setup Oracle Identity Manager (OIM) 11g LDAP sync feature after the product install is done. This article is applicable to OIM version 11.1.1.3 only.

How to Create New User from Oracle Identity Management (OIM)? (Doc ID 1384051.1)

Support also have numerous diagnostic tests available for analyzing where things may have gone wrong. See Fusion Applications Troubleshooting Overview Master Doc ID 109.1. For example,What Diagnostic Tests Are Available For Fusion Human Capital Management (Doc ID 1358207.1) – Steps to run the diagnostic test ‘user and role provisioning diagnostics’ and ‘user and role: user details’.

Thursday Aug 08, 2013

We often find a need to get a list of enterprise roles assigned to a Fusion Applications user, a need for a simple report. This can also be useful when there is no access to OIM screens, but only a simple read-only access is provided to the Fusion database. Below are certain simple SQL scripts that would assist in getting such a report. These scripts can be run by creating data model queries in BI Publisher if you are accessing a SaaS implementation or directly run in any SQL client if you are in an on-premise setup.

1. The SQL below can be used to get a list of roles assigned to an FA user:

Below is a sample output from the SQL and the screenshot from OIM for the same user (FA user 'FUSION' is used for this example here).

OIM Screenshot for 'FUSION' user is below:

2. Further drill-down of the individual roles can be obtained using the query below which provides the detailed listing of roles inherited by a specific user session. The result from this query would match the results you see when drilling down 'Application Implementation Consultant', 'Employee' and 'IT Security Manager' above.

The above queries, using FND_SESSIONS, will only be valid if the FA user has logged into Fusion Applications at any time (or if there is an active session of this user) and the user's login information exists in this table (not purged by any purge routines).

Thursday Apr 11, 2013

The post outlines some of the more prevalent Single Sign On (SSO) use cases Fusion customers are currently using. It also provides an outline of work necessary to enable each of these use cases & links to more detailed technical information.

Case #1: From Corporate Portal

Employees, already authenticated into your corporate portal, should be able to click on the Fusion Apps link and get access without being challenged for their username/password as shown below.

Figure #1: SSO from Corporate Portal

Software you'll need:

Most companies will already have a directory (LDAP) that they are using to store their employees identities. If you already have Single Sign On configured for any of your applications, then you probably already have a "Federation Server" inhouse.

If your federation server is:

ADFS (Active Directory Federation Server) 2.0 from Microsoft

Oracle Identity Federation 11g

... you're all set.

If it's some other Federation Server capable of issuing a SAML 2.0 token, this is subject to approved by Oracle.

Configuration / Integration Work Needed:

Creating Employees in Fusion Apps: First thing you'll need to plan is how to create your employee identities in Fusion Applications and how to assign them the appropriate roles in Fusion Applications (this is required before Single Sign On will work). For testing purposes, you can just create the users using the Fusion Applications "Manage Users" or "New Person" screens and typing them in. If you're a small company, you can continue to do this for new hires. If you're a large company, refer to the "Employee/Role data flow" page - this might reflect the flow you need. If it does not, let us know.

When creating the employee in Fusion HCM, the value that you enter as the "HCM username", should be a unique value also present in your Federation Server for that employee, as you will need to configure your Federation Server to send this value as the "Name Id" when it issues the SAML token for Fusion Applications to consume. [The "Name Id" is just a unique value that tells Fusion Apps who this user is].

Configuring your Federation Server & Fusion Applications (Cloud): Then it's simply a matter of doing some configurations in your Federation Server and for Oracle's Cloud Operations team to do some configurations in your Fusion Applications Pod. This part is done via filing a Service Request. The details of all this are available in My Oracle Support under Note 1477248.1.

Embedding URL: Finally you will embed the url into your corporate portal and your authenticated users will be able to click on the Fusion Applications link and be taken directly into Fusion Applications without being challenged again.

Case #2: From a 3rd Party Application

Employees already authenticated to a 3rd party SaaS Application should be able to click on a Fusion Applications URL and access Fusion Applications without being challenged for their username/password.

Figure #2: SSO from 3rd Party Application

Software you'll need:

If your employees are already configured for SSO into the 3rd party Cloud App, then you probably already have all the On-Premise Software needed in place (LDAP & Federation Server). Refer to Corporate Portal page.

Configuration / Integration Work Needed:

Creating Employees in Fusion Applications: Exactly the same as the "Corporate Portal" use case above.

Configuring your Federation Server & Fusion Applications (Cloud):
Exactly the same as the "Corporate Portal" use case above. Single Sign On will operate between your On-Premise Identity Provider and Fusion Applications in exactly the same manner, but your end user will experience Fusion Applications embedded within your 3rd party Cloud Application (as long as the 3rd party Cloud Application supports embedding the URL).

Embedding URL: You will embed the URL into the 3rd party Cloud Application and your authenticated users will be able to click on the Fusion Applications link & access Fusion Applications screens without being challenged again.

Case #3: Accessing Fusion HCM & Taleo

Employees authenticated against Fusion Apps via SSO, should be able to access Taleo without being challenged for their username/password.

Figure #3: Accessing Fusion HCM & Taleo

If you wish to Single Sign On into Fusion HCM, you will need to configure that as outlined in the "Corporate Portal" use case above.

Then you follow the configuration steps to get Taleo SSO working with your On-Premise IdP. This includes a step of ensuring that the employees that need to access Taleo are already created in Taleo.

Now once your users are logged into Fusion HCM, they can bring up an additional tab for Taleo and will be automatically logged into Taleo.

Case #4: Access from Home

All the use cases above should also work when the employee logs in from home (outside work network).

Figure #4: Access from Home

Case #5: SSO plus Non-SSO

Some of your employees (contractors etc) or partners are not present in your LDAP and need to be authenticated by Fusion Applications. All the others need to be authenticated via SSO. NOTE: This is supported as of Release 7 only.

Figure #5: SSO plus Non-SSO

As of Release 7, when you click on the Fusion Applications URL, you will be able to choose between SSO authentication and authentication via Fusion Applications. Contractors and Partners can choose to authenticate via Fusion Applications and employees via SSO.

The SSO setup & configuration remains the same as in the "Corporate Portal" use case above.

Tuesday Dec 04, 2012

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:

How to discover the data security implemented in Fusion Applications.

How to customize data security

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

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”,

Find the seeded policy

Identify the Role, Object, Instance Set and Action components of the policy

Create a new custom instance set based on the seeded instance set.

End Date the seeded policies

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

Step 2:

Click on the Data Security Tab

Sort by “Resource Name”

Find all the policies with the “Condition” as “where they are a territory resource in the opportunity territory team”

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.

Find the object using global search option. Open it and click on “condition” tab

Sort by Display name

Find the Instance set

Edit the instance set and copy the “SQL Predicate” to a notepad.

Create a new instance set with the modified SQL Predicate from above by clicking on the icon as shown below.

Step 4:

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

Repeat the navigation in step

Edit each of the 5 policies and end date them

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.

Tuesday Nov 13, 2012

In this post we describe the process of modifying and extending a Tasklist available in the Regional Area of a Fusion Applications UI Shell. This is particularly useful to Customers who would like to expose Setup Tasks (generally available in the Fusion Setup Manager application) in the various functional pillars workareas. Oracle Composer, the tool used to implement such extensions allows changes to be made at runtime. The example provided in this document is for an Oracle Fusion Financials page.

Let us examine the case of a customer role who requires access to both, a workarea and its associated functional tasks, and to an FSM (setup) task. Both of these tasks represent ADF Taskflows but each is accessible from a different page. We will show how an FSM task is added to a Functional tasklist and made accessible to a user from within a single workarea, eliminating the need to navigate between the FSM application and the Functional workarea where transactions are conducted. In general, tasks in Fusion Applications are grouped in two ways:

Setup tasks are grouped in tasklists available to implementers in the Functional Setup Manager (FSM). These Tasks are accessed by implementation users and in general do not represent daily operational tasks that fit into a functional business process and were consequently included in the FSM application. For these tasks, the primary organizing principle is precedence between tasks. If task "Manage Suppliers" has prerequisites, those tasks must precede it in a tasklist. Task Lists are organized to efficiently implement an offering.

Tasks frequently performed as part of business process flows are made available as links in the tasklist of their corresponding menu workarea. The primary organizing principle in the menu and task pane entries is to group tasks that are generally accessed together.

Customizing a tasklist thus becomes required for business scenarios where a task packaged under FSM as a setup task, is for a particular customer a regular maintenance task that is accessed for record updates or creation as part of normal operational activities and where the frequency of this access merits the inclusion of that task in the related operational tasklist

A user with the role of maintaining Journals in General Ledger is also responsible for maintaining Chart of Accounts Mappings. In the Fusion Financials Product Family, Manage Journals is a task available from within the Journals Menu whereas Chart of Accounts Mapping is available via FSM under the Define Chart of Accounts tasklist

Figure 1. The Manage Chart of Accounts Mapping Task in FSM

Figure 2. The Manage Journals Task in the Task Pane of the Journals Workarea

Our goal is to simplify cross task navigation and allow the user to access both tasks from a single tasklist on a single page without having to navigate to FSM for the Mapping task and to the Journals workarea for the Manage task. To accomplish that, we use Oracle Composer to customize the Journals tasklist by adding to it the Mapping task.

The first step in our process is to identify the underlying taskflow for the Manage Chart of Accounts Mappings task. We select to Setup and Maintenance from the Navigator to launch the FSM Application, and we query the task from Manage Tasklists and Tasks

A user with Administration privileges can start the run time customization directly from the Administration Menu of the Global Area. This customization is done at the Site level and once implemented becomes available to all users with access to the Journals Workarea.

Figure 4. Customization Menu

The Oracle Composer Window is displayed in the same browser and the Hierarchy of the page component is displayed and available for modification.

Figure 5. Oracle Composer

In the composer Window select the PanelFormLayout node and click on the Edit Button. Note that the selected component is simultaneously highlighted in the lower pane in the browser.
In the Properties popup window, select the Tasks List and Task Properties Tab, where the user finds the hierarchy of the Tasklist and is able to Edit nodes or create new ones.

In the Edit Window the user will now create a child node at the desired level in the hierarchy by selecting the immediate parent node and clicking on the insert node button.
This process requires four values to be set as described in Table 1 below.

Parameter

Value

How to Determine the Value

Focus View Id

/JournalEntryPage

This is the Focus View ID of the UI Shell where the Tasklist we want to customize is. A simple way to determine this value is to copy it from any of the Standard tasks on the Tasklist

Label

COA Mapping

This is the Display name of the Task as it will appear in the Tasklist

Task Type

dynamicMain

If the value is dynamicMain, the page contains a new link in the Regional Area. When you click the link, a new tab with the loaded task opens

Taskflowid

/WEB-INF/oracle/apps/financials/generalLedger/sharedSetup/

coaMappings/ui/flow/

CoaMappingsMainAreaFlow.xml#CoaMappingsMainAreaFlow

This is the Taskflow path we retrieved from the Task Definition in FSM earlier in the process

Table 1. Parameters and Values for the Task to be added to the customized Tasklist

Once the FSM task is added and its parameters defined, the user saves the record, closes the Composer making the new task immediately available to users with access to the Journals workarea (Refer to Figure 8 below).

Figure 8. The COA Mapping Task is now visible and can be invoked from the Journals Workarea

If a Task Flow is part of a product that is deployed on the same app server as the Tasklist workarea then that task flow can be added to a customized tasklist in that workarea. Otherwise that task flow can be invoked from its parent product’s workarea tasklist by selecting that workarea from the Navigator menu.
For Example
The following Taskflows belong respectively to the Subledger Accounting, and to the General Ledger Products.
/WEB-INF/oracle/apps/financials/subledgerAccounting/accountingMethodSetup/mappingSets/ui/flow/MappingSetFlow.xml#MappingSetFlow
/WEB-INF/oracle/apps/financials/generalLedger/sharedSetup/coaMappings/ui/flow/CoaMappingsMainAreaFlow.xml#CoaMappingsMainAreaFlow
Since both the Subledger Accounting and General Ledger products are part of the LedgerApp J2EE Applicaton and are both deployed on the General Ledger Cluster Server (Figure 8 below), the user can add both of the above taskflows to the tasklist in the /JournalEntryPage FocusVIewID Workarea.
Note: both FSM Taskflows and Functional Taskflows can be added to the Tasklists as described in this document

Figure 8. The Topology of the Fusion Financials Product Family. Note that SubLedger Accounting and General Ledger are both deployed on the Ledger App

In this document we have shown how an administrative user can edit the Tasklist in the Regional Area of a Fusion Apps page using Oracle Composer. This is useful for cases where tasks packaged in different workareas are frequently accessed by the same user. By making these tasks available from the same page, we minimize the number of steps in the navigation the user has to do to perform their transactions and queries in Fusion Apps. The example explained above showed that tasks classified as Setup tasks, meaning made accessible to implementation users from the FSM module can be added to the workarea of their respective Fusion application. This eliminates the need to navigate to FSM to access tasks that are both setup and regular maintenance tasks.

Friday Sep 07, 2012

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.

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.

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

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.

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.

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.

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

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

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.

Figure 9. Data Policy Actions

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

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.

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

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

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.

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.

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.

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

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

Figure 3. Available Actions on a Purchasing Document for a User Provisioned with the Buyer 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.

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.

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

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.

Figure 7. Navigator Menu Items for the Auditor user

Figure 8. No Create Document capability for the Auditor user

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:

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.

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.

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

Wednesday Jul 25, 2012

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.

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.