How to Modify Data Security in Fusion Applications
        Posted  
        
            by Elie Wazen
        on Oracle Blogs
        
        See other posts from Oracle Blogs
        
            or by Elie Wazen
        
        
        
        Published on Tue, 4 Dec 2012 19:57:39 +0000
        Indexed on 
            2012/12/04
            23:12 UTC
        
        
        Read the original article
        Hit count: 1012
        
/Security
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  |  
           
             Role: Opportunity Territory    Resource Duty   |  
        
|  
             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   |  
        
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.   |  
        
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”
 

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.

 
© Oracle Blogs or respective owner