Oracle Sales Cloud Securing Oracle Sales Cloud. Release 10

Transcription

1 Oracle Sales Cloud Securing Release 10

2 Oracle Sales Cloud Securing Part Number E Copyright , Oracle and/or its affiliates. All rights reserved. Authors: Shannon Connaire, Scott Dunn, David Christie, Suzanne Kinkead, Jiri Weiss This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/ or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government. This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications. Oracle and Java are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. This software or hardware and documentation may provide access to or information on content, products and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services. For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at ctx=acc&id=docacc Oracle customers have access to electronic support through My Oracle Support. For information, visit ctx=acc&id=info or visit if you are hearing impaired.

3 Securing Contents Preface 1 i Introduction to Security Securing : Overview Authentication and Identity Management Authentication and Identity Management Predefined Sales Roles Role Types Security Policies Security Customization: Points to Consider Reviewing Predefined Roles How Users Gain Access to Opportunities How Users Gain Access to Leads Multiple Business Units and Data Access Data Sharing Mechanisms and Visibility Overview About Role Hierarchies and Inheritance Authorization with Role-Based Access Control Role-Based Access Control About Users 21 About Creating Users for About Provisioning Enterprise Roles to Users Creating Setup Users for... 27

4 Securing 6 Getting Ready to Create Application Users What You Must Do Before Creating Application Users Creating a Resource Organization Designating a Resource Organization as the Top of the Sales Hierarchy Creating Additional Resource Roles Creating Rules to Automatically Provision Job Roles to Sales Users Automatic and Manual Role Provisioning Provisioning Roles for Customization Testing FAQs for Preparing for Application Users Creating Application Users 49 User Setup Options Setting Up Notifications for New Users Oracle Applications Cloud Password Policy Setting the Default User Name Format Creating Application Users for Managing Application Users Resetting User Passwords Changing User Resource Roles When Job Assignments Change Terminating User Accounts Inactive Users Report Reference FAQs for Terminating Users Using the Security Console 63 Security Tools and Interfaces: How They Work Together Setting Up the Security Console Security Console Visualizations Simulating Navigator Menus in the Security Console Security Console Analytics FAQs for Using the Security Console Reviewing Roles and Role Assignments 71 Reviewing Roles and Role Assignments on the Security Console Reviewing Job and Abstract Roles on the Security Console Comparing Roles User and Role Access Audit Report Reference... 73

5 Securing 11 Certificate Management Managing Certificates Generating Certificates Generating a Signing Request Importing and Exporting X.509 Certificates Importing and Exporting PGP Certificates Deleting Certificates Customizing Security Overview Copying Job or Abstract Roles Using the Security Console Copying Sales Roles: Points to Consider Creating a Job or Abstract Role in Oracle Identity Manager Running Retrieve Latest LDAP Changes Copying and Editing Duty Roles Using the Security Console Managing Data Security Policies on the Security Console Creating Custom Duty Roles in Authorization Policy Manager Role Optimization Synchronizing with Oracle Identity Management 101 Synchronization of User and Role Information with Oracle Identity Management Scheduling the LDAP Daily Processes About Sending Pending LDAP Requests About Retrieving Latest LDAP Changes Security and Reporting Security for Sales Cloud Analytics and Reports Delivered Roles for Sales Cloud Analytics and Reports Business Intelligence Roles Customizing Security for Oracle Transactional Business Intelligence Viewing Reporting Roles How can I customize Oracle Transactional Business Intelligence duty roles?

6 Securing 15 Implementing Federated Single Sign-On Overview About Federated Single Sign-On Implementing Federated Single Sign-On Uploading User Data from an LDAP Directory into Synchronizing User Data when Users are First Provisioned in Sales Cloud Advanced Data Security Advanced Data Security

7 Securing Preface Preface This Preface introduces information sources available to help you use Oracle Applications. Oracle Applications Help Use the help icon to access Oracle Applications Help in the application. Note If you don't see any help icons on your page, click the Show Help button in the global area. Not all pages have help icons. You can also access Oracle Applications Help at Oracle Applications Guides To find other guides for Oracle Applications, go to: Oracle Applications Help, and select Documentation Library from the Navigator menu. Oracle Help Center at Other Information Sources My Oracle Support Oracle customers have access to electronic support through My Oracle Support. For information, visit or visit if you are hearing impaired. (if you are hearing impaired). Oracle Enterprise Repository for Oracle Fusion Applications Oracle Enterprise Repository for Oracle Fusion Applications ( provides details on assets (such as services, integration tables, and composites) to help you manage the lifecycle of your software. Documentation Accessibility For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at i

8 Securing Preface Comments and Suggestions Please give us feedback about Oracle Applications Help and guides! Send to: Click your user name in the global area of Oracle Applications Help, and select Send Feedback to Oracle. ii

9 Chapter 1 Securing 1 Introduction to Security Introduction to Security Securing : Overview is secure as delivered. This guide describes how to enable user access to functions and data. Some of the tasks described in this guide are performed only or mainly during implementation of Oracle Sales Cloud. Most, however, can be performed at any time and as new requirements emerge. This topic summarizes the scope of this guide and identifies the contents of each chapter. Guide Structure This table describes the contents of each chapter in the guide. Chapter Contents Authentication and Identity Management Introduces authentication and identity management in Authorization with Role-Based Access Control A brief overview of how role-based access control (RBAC) is implemented in. Data Sharing Mechanisms and Visibility How users gain visibility to object data. About Users Getting Ready to Create Application Users Creating Application Users Managing Application Users How to create and manage Sales Cloud setup users and application users, and how to provision users with roles to provide them with access to Sales Cloud functions and data. Using the Security Console Introduces the tools used to manage the roles, privileges, and policies of the RBAC model. How to set up, manage, and use the Security Console. Reviewing Roles and Role Assignments How to review roles and identify the users who have them on the Security Console. Certificate Management How to generate, import, export, and delete PGP and X.509 certificates on the Security Console. 1

10 Chapter 1 Securing Introduction to Security Chapter Contents Customizing Security How to configure Sales Cloud security policies, how to copy predefined roles to create new roles, and how to create new roles from scratch. Synchronizing with Oracle Identity Management The role of the LDAP daily processes and how to schedule them. Security and Reporting How to enable users to run Oracle Transactional Business Intelligence and Business Intelligence Publisher reports. Implementing Federated Single Sign-On How to implement federated Single Sign-On. Advanced Data Security An introduction to these optional cloud services: Database Vault Transparent Data Encryption During implementation, you can perform security-related tasks: From a functional area task list By selecting Setup and Maintenance on the home page and searching for the task on the All Tasks tab of the Setup and Maintenance work area Once the implementation is complete, you can perform most security-related tasks from the Setup and Maintenance work area or the Security Console. 2

11 Securing 2 Chapter 2 Authentication and Identity Management Authentication and Identity Management Authentication and Identity Management This chapter describes the authentication and identity management services provided by Oracle for Cloud Applications. Standard Authentication for Cloud Applications Authentication, the process of verifying that a user is who they claim to be, is applied to all users, automated agents, or Web services that access an Oracle Cloud application. User credentials are checked at login and access is then granted or denied. In the standard method of authentication provided for Oracle Cloud environments, authentication providers validate user and system access based on a user name-password combination. Authentication providers also make user identity information available to other Cloud components when needed. Identity Store The Oracle Cloud authentication providers access the identity store, which is a logical repository of enterprise user and group identity data. Oracle Identity Management, a component of Oracle Fusion Middleware, is the Lightweight Directory Access Protocol (LDAP) identity store used by default for Oracle Cloud Applications. Oracle Identity Management (OIM) stores the definitions of the following: LDAP user accounts Information about roles provisioned to users Job and abstract roles, which are shared across all applications In general, changes you make to user accounts, or to job or abstract role information, are automatically synchronized between and OIM. However, you must also run the processes Send Pending LDAP Requests and Retrieve Latest LDAP Changes on a daily basis to manage information exchange between your application and Oracle Identity Manager. For information, see the chapter Synchronizing with Oracle Identity Management. Single Sign-On Authentication Single Sign-On authentication, which enables users to sign in once but access multiple applications, is optionally available for user authentication. If your enterprise has moved from a traditional on-premises environment to an Oracle Cloud implementation, you might want to use your existing identity management solution for authenticating your employees in, and might also want to provide a Single Sign-On experience. Implementing federated Single Sign-On allows you to provide users with Single Sign-On access to applications and systems located across organizational boundaries. For additional information, see the chapter Implementing Federated Single Sign-On. Note Single Sign-On authentication is available on all platforms used to access the Sales Cloud application, including Oracle Mobile platforms, and is also available for Web services. 3

12 Securing Chapter 2 Authentication and Identity Management 4

13 Securing 3 Chapter 3 Authorization with Role-Based Access Control Authorization with Role-Based Access Control Role-Based Access Control When you receive your Oracle Cloud application, access to its functionality and data is secured using the industry-standard framework for authorization, role-based access control (RBAC). You must implement the RBAC controls provided by Oracle Sales Cloud so that users have appropriate access to data and functions. In a RBAC model, users are assigned roles, and roles are assigned access privileges to protected system resources. The relationship between users, roles, and privileges is shown in the following figure. In, users gain access to application data and functions when you assign them roles, which correspond to the job functions in your organization. Users can have any number of different roles concurrently, and this combination of roles determines the user's level of access to protected system resources. For example, a user might be assigned the Sales Manager role, the Sales Analyst role, and the Employee role. In this case, the user has the following access: As an employee, the user can access employee functions and data. As a sales manager, the user can access sales manager functions and data. As a sales analyst, the user can access sales analysis functions and data. When the user logs into and is successfully authenticated, a user session is established and all the roles assigned to the user are loaded into the session repository. determines the set of privileges to system resources that are provided by the roles, then grants the user the most permissive level of access. You can assign roles to a user manually, when you create the user, or automatically, by creating role provisioning rules. Related Topics Provisioning Enterprise Roles to Users: Explained Predefined Sales Roles Many job and abstract roles are predefined in. The following are the main predefined Sales job roles: Business Practices Director Channel Account Manager 5

14 Securing Chapter 3 Authorization with Role-Based Access Control Channel Administrator Channel Operations Manager Channel Partner Manager Channel Partner Portal Administrator Channel Sales Director Channel Sales Manager Corporate Marketing Manager Customer Contract Administrator Customer Contract Manager Customer Data Steward Customer Relationship Management Application Administrator Customer Relationship Management Integration Specialist Data Steward Manager Enterprise Contract Administrator Enterprise Contract Manager Marketing Analyst Marketing Manager Marketing Operations Manager Marketing VP Master Data Management Application Administrator Master Data Management Integration Specialist Partner Administrator Partner Sales Manager Partner Sales Representative Sales Administrator Sales Analyst Sales Catalog Administrator Sales Lead Qualifier Sales Manager Sales Representative 6

15 Securing Chapter 3 Authorization with Role-Based Access Control Sales VP Supplier Contract Administrator Supplier Contract Manager These predefined roles are part of the security reference implementation. The security reference implementation is a predefined set of security definitions that you can use as supplied. You must also assign the following abstract roles to all users who are employees so they can carry out their work: Employee Resource Role Types This topic describes the roles provided by and explains how they work together to provide users with permissions to application resources. provides the following types of roles: Enterprise roles Job roles Abstract roles Application roles Application job roles Application abstract roles Duty roles Authenticated role Note Abstract roles and job roles are also called enterprise roles or external roles because they are created in the identity store (Oracle Identity Management) and are not specific to an application pillar. Application roles are created in the policy store and are specific to each Oracle application pillar. Oracle Entitlements Server Authorization Policy Manager is used to manage the policy store for Oracle Cloud Applications. The permissions each role provides are described in security reference manuals available on Job Roles Job roles represent the job functions in your organization. Sales Representative and Sales Manager are examples of predefined job roles. You can also create custom job roles. 7

16 Securing Chapter 3 Authorization with Role-Based Access Control Job roles provide users with the permissions they need to perform activities specific to their jobs. For example, providing a user with the Sales Manager job role permits the user to manage salespersons within the organization, follow up on leads, generate revenue within a territory, build a pipeline, manage territory forecasts, and assist salespeople in closing deals. You can assign job roles directly to users. You can also create custom job roles. Abstract Roles Abstract roles represent a worker's functions in the enterprise independently of the job they do. The following are examples of abstract roles used in Oracle Sales: Employee Resource Abstract roles permit users to perform functions that span across the different jobs in the enterprise. For example, users who are employees must be provisioned with the Employee abstract role, so they can update their employee profiles and pictures. For, you must also provision users with the Resource abstract role, so they can work on leads, opportunities, and other sales tasks. You can assign abstract roles directly to users. You can also create custom abstract roles. Application Job Roles and Application Abstract Roles Each enterprise job and abstract role inherits a corresponding application role of the same name. For example, the Sales Administrator job role is associated with the Sales Administrator application job role. The application job role or application abstract role provides many functional and data privileges to the related job or abstract role, and is the top-level application role in the hierarchy of duty roles assigned to a job or abstract role. You can't assign application job roles or application abstract roles directly to users. Duty Roles Job and abstract roles permit users to carry out actions by virtue of the duty roles they include. Each predefined duty role consists of a logical grouping of privileges that represents the individual duties that users perform as part of their job. Duty roles are composed of security policies which grant access to work areas, dashboards, task flows, application pages, reports, batch programs, and so on. Job roles and abstract roles inherit duty roles through their corresponding application job or application abstract roles. For example, the Sales Manager job role inherits the Sales Manager application job role which includes the Sales Lead Follow Up duty and the Sales Forecasting Management duty. The Sales Lead Follow Up duty makes it possible for managers to work with leads. The Sales Forecasting Management duty enables the management of sales forecasts. Duty roles can also inherit other duty roles. They're part of the security reference implementation, and are the building blocks of custom job and abstract roles. You can also create custom duty roles. You can't assign duty roles directly to users. Authenticated Role The authenticated role is an application role. In Oracle Cloud Applications, the authenticated role is granted by default to any authenticated user through the ALL_USERS enterprise role. About Role Hierarchies and Inheritance This topic describes how users inherit roles and privileges and introduces the role hierarchy. 8

17 Securing Chapter 3 Authorization with Role-Based Access Control In, each role can be linked to other roles in a parent-child format to form a hierarchy of roles. As illustrated in the following figure, users are assigned job and abstract roles, which inherit application roles of the same name. The toplevel application roles in turn inherit duty roles and their associated privileges. Role hierarchies allow privileges to be grouped to represent a feature set in, which simplifies feature management. Role hierarchies also provide privilege granularity and facilitate role reuse. For example, each role hierarchy beneath the Application Job Role represents a feature that is available through the job role to the user. Roles at lower levels of the hierarchy represent functionality that the feature requires. If this functionality is required by other features, the role that provides the functionality can be shared across roles. Note Having many levels in a role hierarchy is not recommended. Deep role hierarchies are difficult to manage, and modification of the privileges in roles that are heavily reused can cause undesired behavior in other features. Role Inheritance Rules In, roles can be inherited according to the following rules. External roles (job and abstract roles) can inherit privileges from subordinate external roles. External roles can inherit privileges from subordinate application roles. Application roles can inherit privileges from subordinate application roles. Application roles cannot inherit privileges from external roles. Circular references between roles are not allowed. 9

18 Securing Chapter 3 Authorization with Role-Based Access Control Role Inheritance Example This example shows how roles and privileges are inherited for a user, Tom Green, assigned the Sales Manager job role. The following figure shows a few representative duty roles. In this example, an employee sales manager, Tom Green, is provisioned with the roles needed to do the job: the Sales Manager job role, and the Employee and Resource abstract roles. Each job and abstract role has an equivalent application role with the same role name. Roles are inherited as follows: The Sales Manager job role inherits an application job role of the same name: the Sales Manager application job role. The Sales Manager application job role inherits duty roles including the Sales Party Management duty role and the Opportunity Sales Manager duty role. The duty roles can be associated with functional security policies and data security policies. For example, the inherited Opportunity Sales Manager duty has functional security policies that specify which application pages and functions sales managers can access for deleting, assigning, closing, creating, and viewing an opportunity. The View Opportunity policy, for example, permits sales managers to view all UIs, Web services, and task flows related to opportunities. 10

19 Securing Chapter 3 Authorization with Role-Based Access Control Security Policies Duty roles are associated with two types of security policies: functional security policies and data security policies. Security policies define the privileges provided by the duty role to access specific application resources. This topic describes both types of security policy. Note The privileges provided by each duty role are described in the security reference manuals available on docs.oracle.com. Functional Policies Functional policies permit an individual who is assigned a duty role to access different user interface elements, Web services, tasks flows, and other functions. For example, a sales manager who has the Delete Opportunity functional policy will be able to view and click the Delete button. Removing that policy removes the button from view. A functional policy is made up of the following: A duty role name. The name of the duty where the policy applies, for example, Opportunity Sales Manager. A functional privilege that specifies the application features that are being secured, for example, View Opportunity. In the security reference manuals, functional privileges are listed in the Privileges section. Data Security Policies Data security policies specify the duty roles that can perform a specified action on an object, and the conditions under which the action can be carried out. A data security policy is composed of: A duty role name. The name of the duty where the policy applies. For example, Opportunity Sales Manager. A data privilege that defines the action being performed. For example, View Opportunity. The condition that must be met for access to be granted. For example, sales managers can view opportunities provided they are in the management chain or are members of the sales team on the opportunity. If the View All condition is specified, the duty role provides access to all data of the relevant type. Each data security policy represents an underlying SQL query. The application evaluates the query at run time, and permits access to data that meets the condition. Data privileges are listed in the Data Security Policies section of the security reference manuals. Policy Store The policy store is the repository of duty roles and other application-specific roles for Oracle Cloud Applications. The policy store is also where the security policies defined for each duty role are stored. Oracle Entitlements Server Authorization Policy Manager is a tool for managing the policy store for Oracle Cloud Applications. Security Customization: Points to Consider If the predefined security reference implementation doesn't fully represent your enterprise, then you can make changes. 11

20 Securing Chapter 3 Authorization with Role-Based Access Control For example, the predefined Sales Representative job role includes sales forecasting privileges. If some business groups in your organization have the sales managers do forecasting, not the sales representatives, then you can create a custom Sales Representative role without those privileges. During implementation, you evaluate the predefined roles and decide whether changes are needed. Important Never edit the predefined roles. During each upgrade, predefined roles are updated to the specifications for that release and any customizations are overwritten. Therefore, you must either copy the predefined roles and edit the copies or create custom roles from scratch. You can perform both tasks on the Security Console. You can identify predefined application roles easily by their role codes, which all have the prefix ORA_. For example, the role code of the Sales Representative application job role is ORA_ZBS_SALES_REPRESENTATIVE_JOB. All predefined roles are granted many function security privileges and data security policies. They also inherit duty roles. To make minor changes to a role, copying the predefined role and editing the copy is the more efficient approach. Creating roles from scratch is most successful when the role has very few privileges and you can identify them easily. Missing Enterprise Jobs If jobs exist in your enterprise that aren't represented in the security reference implementation, then you create custom job roles. Add duty roles to custom job roles, as appropriate. Predefined Roles with Different Privileges If the privileges for a predefined job role don't match the corresponding job in your enterprise, then you create a custom version of the role. If you copy the predefined role, then you can edit the copy to add or remove duty roles, function security privileges, and data security policies, as appropriate. Predefined Roles with Missing Privileges If the privileges for a job aren't defined in the security reference implementation, then you create custom duty roles. The typical implementation doesn't use custom duty roles. Reviewing Predefined Roles This topic describes the ways in which you can access information about predefined roles. This information can help you to identify which users need each role and whether to make any changes before provisioning roles. The Security Console On the Security Console, you can : Review the role hierarchy of any job, abstract, or duty role. Identify the function security privileges and data security policies granted to a role. Compare roles to identify differences. Reports You can run the User and Role Access Audit Report to produce an XML-format report of the function security privileges and data security policies for a specified role or all roles. 12

21 Securing Chapter 3 Authorization with Role-Based Access Control The Security Reference Manuals Two manuals describe the security reference implementation for users: The Oracle Applications Cloud Security Reference for Common Features includes descriptions of all predefined security data that's common to Oracle Fusion Applications. The Security Reference includes descriptions of all predefined security data for Oracle Sales Cloud. Both manuals contain a section for each predefined job and abstract role. For each role, you can review its: Duty roles Role hierarchy Function security privileges Data security policies You can access the security reference manuals on cloud.oracle.com. From the menu select Resources - Documentation Applications. Select Sales Cloud, then Books. 13

22 Securing Chapter 3 Authorization with Role-Based Access Control 14

23 Securing 4 Chapter 4 Data Sharing Mechanisms and Visibility Data Sharing Mechanisms and Visibility Overview The conditions specified in data security policies control visibility to record-level data associated with a schema object, such as an opportunity. Conditions can use the following components as mechanisms for sharing data, provided that the sharing mechanism is applicable for the object: Team Partner team Territory Resource hierarchy Business unit For example, for the Opportunity object, data can be shared through team membership, through the resource hierarchy, or through territory membership. This chapter describes how users gain visibility to various objects in. How Users Gain Access to Opportunities This topic explains how the security reference implementation provided by Oracle determines who can access what opportunity information in your sales organization. Whether or not you can access a particular opportunity depends on your membership in the resource and territory hierarchies. You can access an opportunity if: You create the opportunity. You are on the opportunity sales team. The opportunity owner or sales team member is your direct or indirect report in the resource hierarchy. You are the owner or are a member of the territory assigned to the opportunity. You are the owner or member of an ancestor territory of the territory assigned to the opportunity. You are assigned to a territory for the account associated with the opportunity. You are assigned to a territory that is an ancestor of the territory for the account associated with the opportunity. Salespeople can see all opportunities related to their accounts. However, access differs between territory members and opportunity members: An opportunity owner gets full access to the opportunity, which includes the ability to edit as well as add and remove team members. Owners and members of territories or of ancestor territories assigned to the account of the opportunity get read-only access to the opportunity and are not added to the opportunity sales team. Owners and members of territories assigned to the opportunity product lines are added as a distinct list of territories to the opportunity sales team. Owners and members of these territories get full access to the opportunity. Depending on a profile option, either only the owner or all the members of the territory are added as resources to the opportunity sales team. Regardless of the access level for these members as a resource on the opportunity team, they always have full access. 15

24 Securing Chapter 4 Data Sharing Mechanisms and Visibility Owners and members of ancestor territories of the territory assigned to the opportunity do not get added to the opportunity sales team but they always get full access. The following figure illustrates some of the different ways you can gain access to an opportunity: Named agents in the diagram (A, B, and C) can access the opportunity. Unnamed agents (highlighted in yellow) cannot access the opportunity. Sales managers can access the opportunity because a salesperson in their management chain has access. This figure shows who in a sales hierarchy can access an opportunity. Agent A can access the opportunity because she created it. When you create an opportunity, you are the initial owner. 16

25 Securing Chapter 4 Data Sharing Mechanisms and Visibility Agent B can access the opportunity because he is on the sales team. Agent C can access the opportunity because he is the owner of the NW territory. Sales managers who are higher up in the management chain can also see the opportunity because access is provided through the resource hierarchy. Agent C's manager can access the opportunity information, but agent C's colleagues cannot. Note Access using accounts is not shown in this figure. Special Access Some access is not affected by the management hierarchy and membership in sales teams or territories. This special access includes: Administrators: Administrators get access to opportunities and other objects. This access is based on their privileges, regardless of where the administrators are in the management hierarchy. Administrators do not have to be on the sales team or members of territories. Deal Protection: Salespeople assigned to an opportunity retain the sales credit on an opportunity even if they are moved to another opportunity. How Users Gain Access to Leads This topic explains how the security reference implementation provided by determines who can access lead information in your sales organization. Qualified leads are assigned to a sales team based on sales territories. Unqualified leads are assigned to individual lead qualifiers either manually or based on rules defined in the assignment manager engine. Whether or not you can access a particular lead depends on your membership in the resource and territory hierarchies. You can access a lead if: You are the lead owner. The lead owner is your direct or indirect report in the resource hierarchy. You are a member of the lead sales team. Resources in the management hierarchy of a newly added lead sales team member have the same level of access to the sales leads as the team member. You are the owner of the territory the lead is assigned to or of ancestor territories. You are a member of the sales territories assigned to the lead. Note Only the lead owner, or resources in the management chain of the lead owner, can change the lead owner. Multiple Business Units and Data Access This topic describes how implementing multiple business unit functionality affects access to object transactional data. 17

26 Chapter 4 Securing Data Sharing Mechanisms and Visibility A business unit (BU) is a unit of an enterprise that performs one or more business functions, such as Sales or Marketing. In, a BU primarily provides a means of separating or sharing setup data and controlling transactional data access within an enterprise. By default, an enterprise structure is created as a single business unit to which all users belong. However, you can create additional BUs if required. Users are associated with a business unit through their resource organization membership. Resource organizations are mapped to one or more BUs. When a Sales Cloud user is created, the user is assigned to a resource organization, and thereby gains access to each BU that is mapped to the resource organization. For example, a user can access relevant transactional data associated with their primary BU, but might also have access to relevant transactional data in other BUs through their resource organization. Note When you create a user in, you specify a business unit for the user. However, only the BUs associated with the user's resource organization are relevant in determining the BUs a user can access. If a BU is not specified for a resource organization, the default business unit is used. Within, the opportunity and lead business objects support the use of multiple business units (MBUs). When you create an object that supports multiple business units, such as an opportunity, you specify the BU to associate with the object. Object Access in a Single Business Unit Environment (Default) In this type of implementation, all users can access master data, such as product or account information, by default. In addition, access to transactional data for objects such as opportunities, contracts or leads, is determined as follows: Sales administrators can access transactional data for all objects. Sales users gain access to transactional data for an object through one of the following methods: They have been granted full access to the object Through territory or team membership Through the resource management hierarchy Full access to an object is provided through data security policies that include a condition of All Values. The following table provides additional information about other methods of object access. Type of Object Access Description Territory membership You gain access to an object if: You are the owner or member of the territory that is assigned to the object. You are the owner or member of an ancestor territory of the territory assigned to the object. Your direct or indirect report in the resource hierarchy is the owner or a member of the territory assigned to the object. Your direct or indirect report in the resource hierarchy is the owner or member of an 18

27 Chapter 4 Securing Type of Object Access Data Sharing Mechanisms and Visibility Description ancestor territory of the territory assigned to the object. Team membership You gain access to an object if: You are a member of the sales team assigned to the object. Your direct or indirect report in the resource hierarchy is a member of the sales team assigned to the object. You are a member of the partner team assigned to the object. Object Access in a Multiple Business Unit Environment In a multiple business unit environment, access to objects and data is influenced by the business unit the user belongs to. In this type of implementation, access to transactional data for objects, such as opportunities or leads, is determined as follows: Sales administrators can access transactional data for all objects that are associated with the business unit or units to which the administrators are assigned. Sales users access to transactional data for an object is the same in multiple BU environments and single BU environments. That is, sales users can access object data across BU boundaries provided that they have valid access to the object by means of territory or team membership, through the resource hierarchy, or by being granted full access to the object. Business unit assignment can, however, indirectly impact a user's access to object transactional data. In a multiple BU environment, BUs are available as territory dimensions and can be included as part of the territory coverage definition for the assignment of transactions. A sales user gains access to object data through territory membership. If BU is specified as a territory dimension, then the user's access to data is limited to objects which, when they were created, were assigned to the same BU that is assigned to the user's territory team. 19

28 Securing Chapter 4 Data Sharing Mechanisms and Visibility 20

29 Chapter 5 Securing 5 About Users About Users About Creating Users for This topic provides information about creating users in. Review this information before you create setup and application users. User Types When you sign up with, you receive the user name and password for one initial user. The initial user is provisioned with the following job roles: Application Implementation Consultant IT Security Manager Application Diagnostic Administrator These roles provide the initial user with the privileges necessary to perform many implementation tasks, including creating other users. The following table explains the different types of users that you can create when you sign in to the application as the initial user. Type of User Description Setup users You can provision setup users with the same job roles as the initial user so that they can perform the standard implementation set up tasks for your implementation. Setup tasks include managing security, enterprise setup, and creating other users, including other users with the same privileges. The roles assigned to the initial user are: Application Implementation Consultant job role IT Security Manager job role Application Diagnostic Administrator job role You also need to provision setup users with the following additional roles: Sales Analyst job role Sales Administrator job role Employee abstract role Setup users are not part of the sales organization so aren't created as resources in and aren't provisioned with the Resource abstract role. You cannot assign sales work to them and they cannot view sales transaction data or reports. However, setup users 21

30 Chapter 5 Securing Type of User About Users Description do have the privileges to assign themselves additional roles to make those tasks possible. Sales administrators Sales administrators, like other application users, are created as resources and are provisioned with job and abstract roles on the basis of the resource role they are assigned. Sales administrators are provisioned with the Sales Administrator job role, which includes permissions to manage the import of data from legacy systems, to customize the application according to business needs, and to set up and administer the sales territories and sales processes. Sales administrator users can view sales transactional data and reports but cannot configure sales application security or perform tasks related to an enterprise setup. Sales administrator users are provisioned with the following roles: Sales Administrator job role Resource abstract role Employee abstract role To create sales administrators, follow the same procedure outlined in the topic Creating Application Users for : Worked Example. Application users You create application users as resources. As resources, application users can be assigned work and appear in your sales organization directory. Application users are provisioned with job and abstract roles according to the resource role they are assigned. The provisioned job roles do not permit application users to perform implementation tasks, but they can perform a functional setup within the application, depending on their role. Application users are provisioned with the following roles: The job roles that they require to perform their job The Resource abstract role The Employee or the Contingent Worker abstract role, depending on the employee type of the user 22

31 Chapter 5 Securing About Users Note The user types outlined in the preceding table are suggestions. The privileges granted to any user are entirely dependent on the assigned job and abstract roles so, for example, you can create an application user who is also a setup user if you want. Methods of Creating Users You can create users in either of the following ways. You can: Create users individually in the Manage Users work area. You can navigate to this work area using the Navigator menu from any application page. Use this method to create all setup users, and to create application users unless you are creating a large number of users. Import users from a file using the File-Based Data Import group of tasks from the Setup and Maintenance work area. Import users from a file only if you have a large number of users to create. To import users, you must understand how user attributes are represented in and how to map the attributes in your file to the attributes required by the application. You cannot import setup users because the import process requires you to import sales resources. See Understanding File-Based Data Import: Getting Started and other help topics on file import. Tasks You Accomplish by Creating Users When you create users, you also accomplish the tasks listed in the following table. Not all the tasks apply to setup users because they are not created as resources in the application. Task Accomplished Application and Sales Administrator Users Setup User Comments Send automatic notifications containing the user names you entered and automatically generated temporary passwords. Yes Yes The application sends the notifications to the user or to an administrator only once, either on creation or later, depending on the setup. Automatically provision the job and abstract roles that provide the security settings users require to do their jobs. Yes Yes Job and abstract roles are provisioned based on the autoprovisioning rules discussed in related security topics. Create resources that can be assigned Sales work. Yes No Setup users are not resources in your application and so cannot be assigned to sales teams or view reports. 23

32 Chapter 5 Securing Task Accomplished About Users Application and Sales Administrator Users Setup User Comments Create the resource reporting hierarchy used by for reporting, forecasting, and work assignments. Yes No When you create a resource, you specify a manager for that resource and build a resource reporting hierarchy. Create resource records that individual users can update with personal information to complete a directory of your organization. Yes No Setup users are not resources and so their information does not appear in your Sales directory. Create a hierarchy of resource organizations. Yes Not applicable Each resource is assigned to a resource organization, and the application builds a hierarchy of these organizations based on the resource reporting hierarchy. Setup users are not resources and so are not assigned to resource organizations. Create rudimentary employee records that can be used by Oracle HCM Cloud if you have implemented it, or if you implement it in the future. Yes Yes You must specify each user as either an employee or as a contingent worker. Creating the Resource Reporting Hierarchy You build a resource reporting hierarchy when you create sales application users by specifying the manager of each user you create. If you are creating users in the user interface, then you must start by creating the user at the top of the hierarchy and work your way down. If you are importing users using file-based import, then the order does not matter provided that all of your users are in the same file. The resource reporting hierarchy does not have to mirror the formal reporting hierarchy, which is captured separately in the Oracle HCM Cloud application if it has been implemented. In, you can have only one resource reporting hierarchy reporting to one person. 24

33 Securing Chapter 5 About Users Creating Resource Organizations and the Resource Organization Hierarchy In, you must assign each manager that you create as a user with his or her own resource organization. All direct reports who are individual contributors inherit their manager's organization. The application automatically builds a resource organization hierarchy, using the resource reporting structure. The resource organizations remain even if managers leave. You can reassign the resource organizations to their replacements. In, resource organizations serve a limited purpose. The name of each resource organization appears in the application's Resource Directory, which users can access to obtain information about their coworkers, and in social media interactions. However, resource organizations are not used in application security or for work assignments. You assign work to individuals rather than their organizations. You access the Resource Directory from the Navigator menu. The resource organization names appear under each person's title. The resource organization names do not have to reflect the names of departments. Departments are tracked along with employee records in the Oracle HCM Cloud application if it has been implemented. Creating Basic Oracle HCM Cloud Employee Records When you create application users, you must specify information that is used to create basic employee records for the Oracle HCM Cloud application. Employee records are used only if you are implementing Oracle HCM Cloud or plan to do so. You must specify the following information for the employee record: Person Type Legal Employer Business Unit For information about these employee-related values, see the topic Creating Application Users for the : Worked Example. Related Topics Creating Application Users for : Worked Example 25

34 Securing Chapter 5 About Users About Provisioning Enterprise Roles to Users This topic describes how role provisioning is implemented in. About Provisioning Roles to Users You enable the provisioning of job and abstract roles to users by creating provisioning rules using the Manage HCM Role Provisioning Rules task from the Setup and Maintenance work area. Each rule (also referred to as a mapping) includes one or more conditions, the list of roles you want to provision, and an option to make the provisioning automatic. When you select automatic as an option, then the roles are provisioned automatically when you create the user if the user matches the rule conditions. It does not matter if you create users manually in the user interface, or import them from a file. When you are creating application users, you provision job roles based on the role a user plays in the organization. This resource role merely provides the job title which appears in the company resource directory. The resource role should not be confused with the job or abstract role, which provide the security permissions. The following figure provides an example of how role provisioning rules work: 1. When you create the sales manager user, you assign that user with the Sales Manager resource role, which is the user's title in the organization. 2. The role provisioning rule uses that resource role as a condition. 3. When you create a user with the sales manager resource role, then the condition is true and the rule automatically assigns the user with the Sales Manager job role and the Resource abstract role. 26

35 Securing Chapter 5 About Users For each of the predefined job roles that Oracle provides, a corresponding resource role is also provided. Resource Role and Job Role names are the same except for the Salesperson resource role, which matches the Sales Representative job role. Steps for Setting Up Role Provisioning You must set up role provisioning before you create users as follows: Resource Roles. If you are creating users with roles that are not provided by Oracle, or your organization uses different titles, create any additional resource roles that are required. Resource roles are used in provisioning roles to application users but not to setup users. For information on creating additional resource roles, see the topic Creating Additional Resource Roles. Employee Abstract Role. Create a rule to provision the Employee abstract role to all users who are employees. Create a separate rule to provision the Employee abstract role because this role is provisioned to application users and to users who are not sales resources, such as setup users. For information about creating the rule to provision the Employee abstract rule, see the topic Creating Setup Users for : Worked Example. Job Roles. Create the rules to provision users with the appropriate job roles. When you are creating the rule for application users, each rule must also provision the Resource abstract role. You can assign multiple job roles to an individual. For information on creating provisioning rules for application users, see the topic Creating Rules to Automatically Provision Roles to Sales Users. Creating Setup Users for This topic describes how to create setup users. The initial user you receive when you activate can perform all of the application setup tasks. As a best practice, it is recommended that you create additional setup users with the type of broad setup privileges Oracle provides to the initial user you received. Note In, setup users replace implementation users, described elsewhere in Oracle Applications documentation. The setup users created in this example are not created as resources in your sales application. Because they are not resources, they do not appear in the sales organization directory and cannot be assigned work or be assigned to sales territories. However, you can provide the same setup permissions to users in the sales organization, if you want. Creating a setup user follows the same general procedure you use to create all users, with the following differences: You do not assign resource roles to setup users because you do not want them to be part of the sales organization. You must create a provisioning rule to assign users with the appropriate job and abstract roles they require to do their job. When you create sales users, the provisioning rule is based on the resource role. When you create setup users, the provisioning rule must be based on another user attribute, such as a job. To create the setup user in this example you do the following: 1. Create a job called Customer Administrator. 27

36 Chapter 5 Securing About Users You create this job for creating setup users only. The job does not serve any other purpose in. 2. Create a provisioning rule that automatically provisions the following job roles to all users with the Customer Administrator job. Job Role Description Application Diagnostics Administrator Provides access to diagnostic tests and data. Application Implementation Consultant Provides access to all setup tasks across all products. IT Security Manager Provides access to security tasks, including the ability to assign other enterprise roles. Sales Analyst Makes it possible to create Sales Predictor rules. Sales Administrator Permits the setup user to access the same functional setups as a sales administrator. 3. Create a separate provisioning rule that provisions every user of type employee with the Employee abstract role. All of your users are employees, so they all receive this role. The Employee abstract role provides access to BI reports and the ability to run and monitor background processes. 4. Create each setup user as a user of type employee with the Customer Administrator job. Creating the Job for Provisioning Setup Users Use the following steps to create a job that you can use to assign setup users with the same implementation privileges as the initial user. You assign the job to users and use it in the provisioning rule you create to assign users with roles. 1. Sign in as the initial user or a user with implementation privileges, such as another setup user. 2. Navigate to the Setup and Maintenance work area. 3. On the Overview page of the Setup and Maintenance work area, search for the Manage Job task. 4. Click Go to Task. The Manage Jobs page appears. 5. Click Create. The Create Job: Basic Details page appears. 6. Enter the following: 28

37 Chapter 5 Securing About Users Field Value Name Customer Administrator Code CustomerAdministrator. (No spaces) You do not have to change any other values. 7. Click Next at the top of the page. 8. Click Submit on the next page, and click OK when the warning is displayed. The job may take a couple of minutes to create. You can use search on the Manage Job page to verify that it has been created. Creating the Provisioning Rule for Setup Users Use this procedure to create a provisioning rule that automatically provisions users assigned the Customer Administrator job with the job roles that are provided by Oracle to the initial user, as well as with the Sales Analyst and Sales Administrator job roles. 1. Navigate to the Setup and Maintenance work area. 2. On the All Tasks tab, search for the Manage HCM Role Provisioning Rules task. 3. Click Go to Task. The Manage Role Mappings page appears. 4. Click the Create icon. The Create Role Mapping page appears. 5. In the Mapping Name field, enter a name, for example, Setup User. 6. In the Conditions region, select Customer Administrator, the job you created earlier, from the Job list. If the job does not appear in the list, click Search and search for it using the full name. 7. Select Active from the HR Assignment Status list. This additional condition ensures that the provisioned roles are automatically removed if the user is terminated. 8. In the Associated Roles region, click Add to add the following job roles: Application Implementation Consultant IT Security Manager Application Diagnostics Administrator 29

38 Securing Sales Analyst (required for Sales Predictor) Sales Administrator Chapter 5 About Users 9. Make sure the Autoprovision option is selected for each of the job roles. 10. Click Save and Close. Creating the Provisioning Rule for the Employee Abstract Role Use the following procedure to create a rule to provision the Employee abstract role to all users who are employees. You can use this rule for all employee users, not just setup users. 1. In the Manage Role Mapping page, click the Create icon to create the second rule. The Create Role Mapping page appears. 2. In the Mapping Name field, enter a name, for example, Employee. 3. In the Conditions region, select Employee from the Assignment Type list. 4. Enter Active for HR Assignment Status. This additional condition ensures that the provisioned roles are automatically removed if the user is terminated. 5. In the Associated Roles region, click Add to add the Employee abstract role. 6. Make sure the Autoprovision option is selected for this role. 7. Click Save and Close. Creating a Setup User Use the following steps to create other setup users. 1. In the Navigator, select the Manage Users link under the My Team heading. The Manage Users page appears. 2. Click Create. The Create User page appears. 3. Enter the user's name and a unique address in the Personal Details region. The application automatically sends the initial sign-in credentials to this address when you save the record. You can leave the Hire Date as is. The Hire Date and the remaining fields are not used by. 4. In the User Details region, enter the user name. If you leave the User Name field blank, then the application creates a user name based on the entries you have already made. 30

39 Chapter 5 Securing About Users 5. In the User Notification region, select the Send User Name and Password option so setup users receive initial notifications with their login and password details when you save the record. 6. In the Employment Information region, enter the information shown in the following table. Field Entry Person Type Select Employee. The provisioning rule you set up is based on the employee's job. Legal Employer Select the legal employer Oracle created for you using the information you provided when you signed up with. Business Unit Select the business unit created for you using the information you provided when you signed up with. Job Select Customer Administrator, the job you just created. 7. Click Autoprovision Roles. The Roles region displays the roles for the Customer Administrator job: Application Implementation Consultant IT Security Manager Application Diagnostics Administrator Sales Analyst Sales Administrator Employee 8. Click Save and Close. An is sent to the new setup user containing the initial credentials for signing into the application. 31

40 Securing Chapter 5 About Users 32

41 Securing 6 Chapter 6 Getting Ready to Create Application Users Getting Ready to Create Application Users What You Must Do Before Creating Application Users Creating sales application users requires a bit more preparation than creating setup users. When you create sales application users, either in the UI or by importing them from a file, you not only provision the permissions the users need to do their jobs, but you also build the sales organization chart. This means that you must set up not only the provisioning rules, but also the elements that the application will use to create the organization chart, such as the root of the chart, and the job titles for each resource. You are getting ready to create two types of application users: Members of the sales team without any system administration duties. These are the salespeople, the sales managers, and the sales vice presidents. At least one sales administrator user who will set up and administer the sales territories and sales processes. Setup Overview 1. You must assign a title, called a resource role, to each sales user you create. The resource roles display right underneath user names in the resource directory and elsewhere in the UI. You also use the resource roles as conditions in your provisioning rules. For example, you assign the Sales Manager job role to a user with the Sales Manager resource role. Oracle provides standard resource roles, which correspond to the available job roles for sales, partner sales, and channel sales. For sales, these are: Sales Administrator Sales Manager Sales Vice President Salesperson If you want other job titles to display for your users or if you want to provision some users with special privileges, then you must create additional resource roles using the Manage Resource Roles task from the Setup and Maintenance work area. For example, you must create a CEO resource role if you want to include the CEO title in your organization chart. It's not one of the resource roles created for you. You must also create additional resource roles if you want to provide a small subset of resources with additional privileges. For example, if one of the sales managers in the organization is also in charge of maintaining territories and sales processes, you want to create a new resource role that you can provision with both the sales manager and the sales administrator job roles. For details, see the topic Creating Additional Resource Roles. 33

42 Securing Chapter 6 Getting Ready to Create Application Users 2. Create a resource organization for the top manager in your hierarchy using the Manage Internal Resource Organizations task from the Setup and Maintenance work area. You must assign resource organizations to all the manager users you create. All direct reports who are not managers inherit the organization. As you create users, the application creates an organization hierarchy that you can use to browse through the sales organization's resource directory. For details, see the topic Creating Resource Organizations. Note You can also create resource organizations while creating users in the Create User page. 3. Next, you must designate the resource organization you just created as the top of your organization tree by using the Manage Resource Organization Hierarchies task in the Setup and Maintenance work area. For details, see the topic Designating a Resource Organization as the Top of the Sales Hierarchy. 4. Decide what job roles you want to assign to your users. Remember that you are not restricted to assigning one job role to a user. For example, you will want to provision the sales manager in charge of determining sales territories and sales processes with the Sales Administrator job role in addition to the Sales Manager job role. This will enable this resource to perform the required sales setups. You must create at least one user with the Sales Administrator job role to perform these setups. 5. Using the Manage HCM Role Provisioning Rules task, set up the provisioning rules to automatically provision the appropriate job roles and the Resource abstract role to your users based on their resource role. You must create a provisioning rule for every resource role. For details, see the topic Creating Rules to Automatically Provision Roles to Sales Users. 6. When you create users, the application automatically sends s with the sign-in credentials to the users. You can configure this behavior as described in the topic Setting Up Notifications for New Users: Procedure. Creating a Resource Organization Use this procedure to create the resource organization for the top manager in your sales organization, usually the CEO. You must create a resource organization for every manager in your sales organization, but you can save time by creating the resource organizations while you creating users in the UI or by importing them. When you import users from a file, you can create the resource organizations automatically from the information you include in the file itself. Creating a Resource Organization 1. While signed in as a setup user, search for the Manage Internal Resource Organizations task in the Setup and Maintenance work area. 2. Click Go to Task. The Manage Internal Resource Organizations page appears. 3. Click Create. The Create Organization: Select Creation Method page appears. 4. Select Option 2: Create New Organization. 34

43 Securing Chapter 6 Getting Ready to Create Application Users 5. Click Next. 6. Enter the name of the resource organization in the Name field, for example, Vision Corp. This name will be visible in the resource directory. Note the following points: Each resource organization name you enter must be unique. Don't use managers' names, as you may want to reassign the organizations to others later. The names don't have to correspond to any formal organization in your enterprise. The names are there solely to create a resource directory. 7. In the Organization Usages region, click Add Row and select Sales Organization. 8. Click Finish. Designating a Resource Organization as the Top of the Sales Hierarchy After you have created the resource organization for the top person in the sales organization hierarchy, designate that resource organization as the top of the sales hierarchy in the application. Designating the Organization You Created as the Top of the Sales Hierarchy 1. Sign in as a setup user and search for the Manage Resource Organization Hierarchies task in the Setup and Maintenance work area. 2. Click Go to Task. The Manage Resource Organization Hierarchies page appears. 3. Click Search. 4. In the search results, click the Internal Resource Organization Hierarchy link. This value is supplied by Oracle. The View Organization Hierarchy: Internal Resource Organization Hierarchy page appears. 5. From the Action menu at the top right-hand corner of the page, select Edit This Hierarchy Version. 35

44 Securing Chapter 6 Getting Ready to Create Application Users The Edit Organization Hierarchy Version page appears. 6. Click Add in the Internal Resource Organization Hierarchy region. The Add Tree Node window appears. 7. Click Search. The Search Node window appears. 8. Click Search again in the Search Node window. 9. In the Search Results list, select the resource organization that you created for the top person in the hierarchy. 10. Click OK. The application returns you to the Edit Organization Hierarchy Version page. 11. Click Save and Close. 12. When a warning appears, click Yes. Creating Additional Resource Roles This topic describes how to create additional resource roles. After you create a resource role, you must create the appropriate provisioning rules to provision the user with the required job and abstract roles. The resource role by itself is only a title. Creating a Resource Role 1. Sign in as a setup user and search for the Manage Resource Roles task in the Setup and Maintenance work area. 2. Click Go to Task. The Manage Resource Roles page appears. 3. If you want to review all the existing resource roles to verify that it is necessary to create a new role, then click Search without entering search criteria. All the available resource roles are listed. Roles that are predefined by Oracle are labeled System. 4. Click Create to create a new resource role. 36

45 Securing Chapter 6 Getting Ready to Create Application Users The Create Role page appears. 5. In the Role Name field, enter the name of the resource role as it will appear in the application UI, for example, CEO. 6. In the Role Code field, enter a unique internal name. No spaces are permitted. If you are importing users from a file, then you must include this code in your file rather than the name. 7. Select the Manager option, if the resource role belongs to a manager, or the Member option, if the resource role belongs to an individual contributor. 8. From the Role Type list, select Sales to classify the role that you are creating. 9. Click Save and Close. Creating Rules to Automatically Provision Job Roles to Sales Users Before you create application users, you must create the rules to automatically provision them with the job roles they require. The rules use the resource role that you assign to each sales user as the trigger condition. You must create a separate rule to provision each resource role, including the resource roles provided by Oracle as well as any additional resource roles you created, such as the CEO. For internal sales users, including sales administrators, you must add the Resource abstract role in addition to the required job roles. The Resource abstract role permits the users to access the Resource Directory. Important Do not add the Resource abstract role for partner roles, including Partner Sales Representative, Partner Sales Manager, and Partner Administrator. 37

46 Securing Chapter 6 Getting Ready to Create Application Users Creating a Provisioning Rule 1. Sign in as a setup user. 2. Navigate to the Setup and Maintenance work area and search for the Manage HCM Role Provisioning Rules task. 3. Click Go to Task. The Manage Role Mappings page appears. 4. Click the Create icon. The Create Role Mapping page appears. 5. In the Mapping Name field, enter a name that will help you identify the mapping, for example, CEO, or Sales Vice President. 6. In the Conditions region, select the resource role you want to provision from the Resource Role list. For example, select CEO or Sales Vice President. 7. Select Active from the HR Assignment Status list. This additional condition ensures that the provisioned roles are automatically removed if the user is terminated in Global Human Resources. 8. In the Associated Roles region, click Add to add the job roles you want to provision. For the sales vice president or for the CEO, for example, you add the Sales VP job role. For all internal sales users, including the CEO and the Sales VP, add the Resource abstract role. Do not add this role for partner roles, including Partner Sales Representative, Partner Sales Manager and Partner Administrator. 9. Make sure the Autoprovision option is selected for all the roles. 10. Click Save and Close. Automatic and Manual Role Provisioning Roles provide user access to data and functions. To assign a role to users, you define a relationship, called a role mapping or provisioning rule, between the role and some conditions. Users who satisfy the conditions specified in the mapping are 38

47 Chapter 6 Securing Getting Ready to Create Application Users eligible to acquire the role specified in the mapping. This topic describes role mapping options for automatic and manual role provisioning. Use the Manage HCM Role Provisioning Rules task in the Setup and Maintenance work area to create role mappings. Automatic Provisioning of Roles to Users Role provisioning occurs automatically if: The user meets the conditions defined in the role-mapping. You select the Autoprovision option for the role specified in the role mapping. For example, to create a role mapping rule that autoprovisions the Resource and Sales Representative roles to salespersons, do the following: 1. Specify the following conditions. Attribute Value Resource Role Salesperson HR Assignment Status Active 2. Specify the Resource role and the Sales Representative role for the mapping, and select the Autoprovision option for each. This mapping rule is applied when the user is first created or when the user's status or resource role is modified by clicking the Autoprovision Roles option on the Create User or Edit User page. Manual Provisioning of Roles to Users Users, such as sales managers or administrators, can provision roles manually to other users if: The user meets the conditions defined in the role-mapping. You select the Requestable option for the role in the role mapping. Users can also request a role when managing their own accounts if: The user meets the conditions defined in the role-mapping conditions. You select the Self-requestable option for the role in the role mapping. For example, you can create a role mapping to assign roles to each active employee who has been assigned the Sales Operations Manager resource role as follows: 1. Specify the following conditions. Attribute Value Resource Role Sales Operations Manager HR Assignment Status Active 39

48 Chapter 6 Securing Getting Ready to Create Application Users 2. Specify the following roles. Role Option Resource Autoprovision Sales Administrator Autoprovision Customer Data Steward Requestable Sales Representative Self-requestable In this example, any user assigned the Sales Operations Manager resource role: Is automatically provisioned with the Resource and Sales Administrator roles when the Autoprovision Roles option is clicked on the Create User or Edit User page Can grant the Customer Data Steward role to other users Can request the Sales Representative job role Users keep manually provisioned roles until the user is terminated or the role is deprovisioned manually. Role-Mapping Names Role mapping names must be unique in the enterprise. Devise a naming scheme that shows the scope of each role mapping. For example, a role mapping named Sales Vice President Autoprovisioned Roles could include all roles provisioned automatically to resources assigned the Sales Vice President resource role. Provisioning Roles for Customization Testing How To Enable the Testing of Role-Specific Customizations Administrators who are creating role-specific customizations in either Application Composer or Page Composer must be provisioned with the same job role to test their work in the sandbox. This topic outlines the steps required to enable the testing. Setup Overview 1. A user with security privileges, such as the setup user or the initial user you received when you signed up with, creates a provisioning rule that will make it possible for administrators to request all the job roles they need for testing. You create the provisioning rule using the Manage HCM Role Provisioning Rules task from the Setup and Maintenance work area. For each job role you add to the rule, you enable the self-requestable option and deselect the autoprovision option. For details, see Creating the Provisioning Rule for the Job Roles Used in Testing. 40

49 Securing Chapter 6 Getting Ready to Create Application Users 2. The administrator who is creating the customizations in the sandbox navigates to the Resource Directory and requests the additional job role. For details, see Assigning Yourself an Additional Job Role. Creating the Provisioning Rule for the Job Roles Used in Testing Use this procedure to create a provisioning rule which makes it possible for the sales administrator to request additional job roles for use in customization testing. Creating the Provisioning Rule 1. Sign in as a setup user or the initial user you received when you signed up with. 2. Navigate to the Setup and Maintenance work area. 41

50 Securing Chapter 6 Getting Ready to Create Application Users 3. Enter Manage HCM Role Provisioning Rules in the Search: Tasks regional area, on the bottom left section of the page and click the arrow search icon. The results of your search appear on the right side of the page. 42

51 Securing Chapter 6 Getting Ready to Create Application Users 4. Click Go to Task. The Manage Role Mappings page appears. 5. Click the Create icon. The Create Role Mapping page appears. 6. In the Mapping Name field, enter Requestable Job Roles for Sales Admin, or another name that will help you identify this mapping in the future. 7. In the Conditions region, select the resource role assigned to the sales administrator from the Resource Roles list. 8. Enter Active for HR Assignment Status. This additional condition ensures that the provisioned enterprise roles are automatically removed if the user is terminated. 9. In the Associated Roles region, click Add to add the job roles you want to make requestable by the sales administrator. If you are creating customizations for salespersons and for sales managers, for example, then you want to add the Sales Representative and Sales Manger job roles. 10. For each job role you added: a. Select the Requestable and Self-Requestable options. 43

52 Securing Chapter 6 Getting Ready to Create Application Users b. Deselect the Autoprovision option. 11. Click Save and Close. Assigning Yourself an Additional Job Role Administrators can use this procedure to assign themselves the role they need to test role-specific customizations in the sandbox. For example, an administrator testing customizations for sales managers, requests the Sales Manager job role. Assigning Yourself an Additional Job Role 1. Navigate to the Resource Directory. 44

53 Securing Chapter 6 Getting Ready to Create Application Users 2. Select View Resource Details from the Actions menu in your record. The Resource page appears. 3. Select the Roles tab. 4. Click Add Role. The Add Role window appears. 5. Search for the role you want to use for testing by name or partial name, select it, and click OK. Note Available roles include only those that were set up as self-requestable during provisioning rule setup. The application returns you to the Resource page and displays the requested role in the Roles Requests region. 45

54 Securing Chapter 6 Getting Ready to Create Application Users The following image highlights the location of the Add Role button (1) and the Role Requests region (2). 6. You can remove a role you no longer need for testing by selecting it and clicking Remove. 7. Click Save and Close. The new role becomes available for your use in a few minutes, pending the completion of a background process. It displays in the Current Roles region the next time you navigate to this page. 46

55 Securing Chapter 6 Getting Ready to Create Application Users FAQs for Preparing for Application Users What happens when I autoprovision roles for a user? The role-provisioning process reviews the user's assignments against all current role mappings. The user immediately: Acquires any role for which he or she qualifies but doesn't have Loses any role for which he or she no longer qualifies It's recommended that you autoprovision roles to individual users on the Edit User page when new or changed role mappings exist. Otherwise, no automatic updating of roles occurs until you next update the user's assignments. Why did some roles appear automatically? Roles appear automatically for a user when: The user's assignment attributes, such as person type and job, match the conditions specified for the role in a role mapping. In the role mapping, the role has the Autoprovision option selected. Can I implement single sign-on in the cloud? Yes. Single sign-on enables users to sign in once but access multiple applications, within and across product families. Submit a service request for implementation of single sign-on. 47

56 Securing Chapter 6 Getting Ready to Create Application Users 48

57 Securing 7 Chapter 7 Creating Application Users Creating Application Users User Setup Options This topic introduces the enterprise options that are available for controlling default functionality when application users are created. Some of these options can be overridden. However, it is recommended that you configure these options to support most users before you start to create application users. To set these options, you select the Manage Enterprise HCM Information task in the Setup and Maintenance work area. You can edit the values for these options as necessary and specify an effective start date for changed values. Send User Name and Password The Send User Name and Password option controls whether an notification containing the user name and password is sent automatically when a user account is created. The notification can be sent to the alternate contact address, the new user, or you can suppress notifications. Alternate Contact Address The alternate contact is an enterprise-wide address that can receive user credential s for new user accounts. Default User Name Format You can select the default format used to generate user names for application users in cases where a user name is not specified. In, the default format is address. Setting Up Notifications for New Users This topic describes how to configure whether or not credential s are sent to recipients when application user accounts are created, and to configure how and when notifications are sent. The Send User Name and Password option controls whether or not credentials s are sent by default in the enterprise: If you set the value of the Send User Name and Password option to Yes, once a user is created, the application automatically sends an containing the user's user name and temporary password to the user's address. Alternatively, you can redirect all initial credential s to a single alternate user. The procedure to perform this task is described below. If you set the value of the Send User Name and Password option to No, then credential s are not sent by default. However, you can: Run the process Send User Name and Password Notifications to send credentials s in bulk to all users for whom s have not previously been sent. The procedure to perform this task is described below. Request that credentials s are sent for individual users on the Create User page. 49

58 Securing Chapter 7 Creating Application Users Note When users sign in with their temporary passwords, they must change their passwords and enter the security challenge questions. These questions cannot be edited later, although they can be reset by logging a service request on support.oracle.com. Designating a Single User to Receive All Credential s You can choose to redirect the initial credentials s sent to users to a single user. For example, when testing your implementation, you might want to create test users and send all of the credential s for the test users to one of the setup users. To send all user credential notifications to a single user, perform the following steps: 1. Navigate to the Setup and Maintenance work area. 2. On the All Tasks tab of the Overview page, search for and then select the task Manage Enterprise HCM Information. The Enterprise page opens. 3. Select Edit - Update. The Edit Enterprise page opens. 4. Scroll to the User and Role Provisioning Information section, then enter the address of the user who is to receive all initial credentials s in the Alternate Contact Address field. 5. Make sure the Send User Name and Password option is set to Yes. 6. Click Submit. 7. Click Done. Note The application sends the credentials containing a user's user name and temporary password only once, so, if you choose to send the initial to an alternate user, such as a setup user, you must resend the credentials to the real user yourself. Sending Notifications to All Users in Bulk The following procedure describes how to send credential notifications to all new users at the same time, instead of to each individual user as the user is created. 1. Navigate to the Edit Enterprise page as described in the procedure above. 2. Scroll to the User and Role Provisioning Information section. 3. Set the Send User Name and Password option to No so that credentials s are not sent to individual new users. 4. Click Submit, then click Done. 5. When you are ready to send notifications to users, select Navigator - Tools - Scheduled Processes. The Scheduled Processes Overview page opens. 6. Click Schedule New Process. 50

59 Securing Chapter 7 Creating Application Users 7. In the Schedule New Process dialog box, select Job for the Type option. 8. In the Name field, search for then select the process Send User Name and Password Notifications. 9. Click OK. 10. In the Process Details window, click Submit. 11. Click Close. Note The Send User Name and Password Notifications process sends the notification only to those users who have not previously been sent the notification. The process does not reset passwords or resend the notification. Oracle Applications Cloud Password Policy Oracle Identity Management defines the validation rules for user sign-in passwords. By default, user sign-in passwords must be at least 6 characters long, start with an alphabetic character, and contain at least: 2 alphabetic characters 1 numeric character 1 uppercase letter 1 lowercase letter In addition, passwords must not be the same as or contain the user's: First name Last name User name Password Policy Update To change the default Oracle Identity Management password policy in Oracle Applications Cloud, submit a service request. Setting the Default User Name Format When you create an application user, you can optionally specify the user name that is assigned to the user. If you do not explicitly specify a user name, then a user name is automatically created. This topic describes how to specify the format of user names that are automatically created for users. Specifying the Format of User Names Perform the steps in the following procedure. 1. Navigate to the Setup and Maintenance work area. 2. On the All Tasks tab of the Overview page, search for and select the task Manage Enterprise HCM Information. The Enterprise page opens. 51

60 Chapter 7 Securing Creating Application Users 3. Select Edit - Update. 4. In the Update Enterprise dialog box, enter the effective date of any changes you make, then click OK. The Edit Enterprise page opens. 5. Scroll down to the User and Role Provisioning Information section, then select the field Default User Name Format. 6. Select one of the options shown in the following table. Format Name Description Defined by Oracle Identity Management This is the default option. The user name follows the Oracle Identity Management user-name policy. By default, Oracle Identity Management uses the person's address. Party Number The party number is the user name. Person Number The HCM person number is the user name. For party users who have no person number, the party is used instead when person number is the default user name. Primary Work The primary work (or party for party users) is the user name. Note For, the relevant options are Defined by Oracle Identity Management and Primary Work , both of which use address for the user name. The Party Number and Person Number options are relevant if you have also implemented Oracle Human Capital Management Cloud. You can override default user names for individual users on the Create User and Edit User pages. Creating Application Users for Follow the steps in this example to create application users. Before creating application users, make sure you have: Set up any additional resource roles required, and have created autoprovisioning rules for job and abstract roles. Created the resource organizations that you will assign to each manager. You can also create the resource organization while creating each manager user. 52

61 Chapter 7 Securing Creating Application Users When you create application users, you automatically set up the reporting hierarchy of your organization by indicating each person's manager. For this reason, you must first create the user at the top of the hierarchy and work your way down. Steps to Create an Application User To create an application user: 1. In the Navigator, select the Manage Users link under the My Team heading. The Manage Users page appears. 2. Click Create. The Create User page appears. 3. In the Personal Details region, enter the following values. Field Entry Last Name Enter the user's last name. This entry is required. First Name Optionally, enter the user's first name. Enter a unique address. The application sends the initial password notification to this address by default. You can change the default behavior so that notifications are not sent, or are sent to a different address to the user's. For information, see the topic Setting Up Notifications for New Users: Procedure. You can leave the Hire Date as is. The Hire Date and remaining fields are not used by. 4. In the User Details region, enter the user name. If you leave the User Name field blank, then Oracle Identity Manager automatically creates a user name for you. By default, Oracle Identity Manager uses the address as the user name. 5. In the User Notification Preferences region, select the Send User Name and Password option if you want to send the notification with the login and password to the user when you save the record. 6. In the Employment Information region, enter the following values. Field Entry Person Type Select Employee. Legal Employer Select the legal employer Oracle created using the information you provided when you signed up with the service. 53

62 Chapter 7 Securing Field Creating Application Users Entry Business Unit Select the business unit for the user. Oracle creates an initial business unit using the information you provided when you signed up with the service. 7. In the Resource Information region, enter the following values. Field Entry Resource Role Select the role the user plays in the resource organization. Reporting Manager Select the user's manager. If you are creating the top user in your hierarchy, such as the CEO, you can leave this field blank. Organization If the user you are creating is a manager, select the appropriate resource organization. If you haven't already created a resource organization for the manager, then you can create one by clicking the Create link at the end of the Organization list. Workers automatically inherit the resource organization assigned to their managers. 8. Click Autoprovision Roles. Any roles for which the user qualifies automatically appear in the Role Requests table with the status Add Requested. The application provisions roles according to the provisioning you have set up for the selected resource role. Each user must have both the Employee and the Resource abstract roles in addition to the job roles they require. 54

63 Securing Chapter 7 Creating Application Users 9. You can also provision a role manually to the user if required by clicking Add Role. The Add Role dialog box opens. 10. Search for and select the role. The role is added to the Role Requests table with the status Add Requested. Tip Roles that you can provision to others appear in a role mapping for which you satisfy the role-mapping conditions and where the Requestable option is selected for the role. 11. Click Save and Close. Related Topics Creating Setup Users for : Worked Example Creating a Resource Organization Creating Users for : Explained 55

64 Securing Chapter 7 Creating Application Users 56

65 Securing 8 Chapter 8 Managing Application Users Managing Application Users Resetting User Passwords This topic describes how to update a user account by changing the user's password. When new users are created in Oracle applications, they receive a login and a temporary password which they can change. If necessary, you can reset a user's password at any time by performing the steps in the following procedure. 1. In the Setup and Maintenance work area, select the All Tasks tab of the Overview page. 2. Search for the task Manage Job Roles. 3. Click Go to Task. The Oracle Identity Manager Self-Service page opens. 4. Click the Administration link in the top-right corner of the page. The Oracle Identity Manager - Delegated Administration page opens. 5. In the Search area, search for the user whose password you want to change, then select the user from the search results. 6. In the new tab that opens for the user, click Reset Password. In the Reset Password dialog box, choose one of the following options, then click Reset Password: Manually Change the Password. If you select this option, you must enter the new password for the user. You can also choose whether or not the new password is sent to the user's primary work . Auto-generate the Password (Randomly generated). If you select this option, a temporary password is generated and sent to the user's primary work . Changing User Resource Roles When Job Assignments Change If an employee takes on a different role within the company, for example, if the user is promoted, then you must update the resource role assigned to the employee as described in this topic. Changing the resource role assigned to an employee involves: Assigning a new resource role to the user that corresponds to the new assignment, for example, Sales Manager Setting an end date for the old resource role, for example, Salesperson Perform the steps in the following procedure to change a user's resource role. 1. In the Setup and Maintenance work area, select the All Tasks tab on the Overview page. 57

66 Securing Chapter 8 Managing Application Users 2. Search for and select the task Manage Resources. 3. On the Manage Resources page, search for and select the resource. The Resource page for the individual opens. 4. Click the Roles tab, then click Add and add the new resource role for the user, for example, Sales Manager. 5. In the Roles list, select the current role assigned to the user, for example, Salesperson, and enter an end date in the To Date field. The value you enter is the date the user's assignment in the current role ends. 6. Click Save and Close. 7. To automatically provision any roles that you have set up using the role provisioning rule for the new resource role you just assigned the user, do the following: On the All Tasks tab on the Overview page, search for and select the task Manage Users. On the Manage Users page, search for and select the relevant user. On the Edit User page for the user, click the Autoprovision Roles button in the Resource Information section. In the Current Roles section, you can remove any individual role if it is no longer required. Terminating User Accounts This topic describes how to terminate user accounts if an employee leaves your company. You cannot delete a user account. However, when an employee leaves your company, you can suspend the user account by completing both of the following steps: 1. Perform either one of the following tasks: Inactivate the user's account Remove the user's roles 2. Set an end date for the resource Note The process outlined in this topic applies if you are using only. If your company uses Oracle HCM Cloud along with Oracle Sales, then a different process applies. When you deactivate a user account, the user record is not deleted from. You can still view the deactivated user's record in the Manage Users page. If you are using Oracle Identity Manager (OIM) to manage users, it is recommended you do not remove the deactivated users from OIM. Also, OIM periodically processes the updates from. In this case, users deactivated in appear active in OIM till the updates are processed. 58

67 Securing Chapter 8 Managing Application Users Inactivating a User Account When an employee leaves your company, in most cases it is recommended that you inactivate the user account. Inactivating the user's account prevents the user from being able to log in to the application. To inactivate a user account, perform the steps in the following procedure. 1. In the Setup and Maintenance work area, select the All Tasks tab of the Overview page. 2. Search for and select the task Manage Users. The Manage Users page opens. 3. Search for and select the user whose account you want to inactivate. The Edit User page for the user opens. 4. In the User Details section, in the User Account Status field, select Inactive. 5. Click Save and Close. Removing Roles From a User Instead of inactivating the user account, you can remove some or all of the roles assigned to the user. You might want to do this if you want to keep some roles active. For example, maybe you want to keep the user account valid to allow the user access to your custom pages. To selectively remove roles from a user, perform the steps in the following procedure. 1. Navigate to the Manage Users page as described in the previous task. 2. Search for and select the user whose roles you want to remove. The Edit User page for the user opens. 3. In the Current Roles section, select the role you want to remove, then click the Remove button. Repeat this process for each role assigned to the user that you want to remove. 4. Click Save and Close. Setting an End Date for the Resource After you have either inactivated a user account or removed the roles assigned to a user account, you must set an end date for the resource (user) as described in this topic. To set the end date for a user, perform the steps in the following procedure. 1. In the Setup and Maintenance work area, select the All Tasks tab of the Overview page. 2. Search for and select the task Manage Resources. The Manage Resources page opens. 3. Search for and select the resource you want to edit. The Resource page for the individual opens. 4. In the To Date field, enter the date the individual is leaving the company. 5. Click Save and Close. 59

68 Securing Chapter 8 Managing Application Users Note You can also set the end date for an employee in the Resource Directory which you can access from the Navigator menu. Upon the end date you specify for a resource, the following occurs: The terminated employee is no longer available in the application so can no longer be newly associated with any Sales objects, such as sales account, territory, lead, and opportunity. The user's association with Sales objects made before the end date are not automatically removed but you can remove them manually. Resource roles for the individual are deprovisioned. Inactive Users Report Reference The Inactive Users Report identifies users who have not signed in for a period of time that you define. Run the report as a scheduled process. Use the Scheduled Processes work area, available from the Navigator. In the Scheduled Processes work area: 1. As a prerequisite, run the Import User Login History process. (This process takes no parameters.) 2. As you run the process that generates the Inactive Users Report, set parameters: Define the inactivity period, in days. This is the only required parameter, and its default value is 30. Filter the users who may be included in the report, by name, department, location, or last-activity start or end date. The use of these parameters is optional. Report Results The process returns an XML file that provides the following information about each inactive user: The number of days the user has been inactive. The user's user name, given name, surname, location, and department. The user's status. FAQs for Terminating Users How are the records of a terminated employee reassigned? After you terminate an employee in the application, the assignment process automatically excludes the terminated employee when it runs again. However, you have to manually handle other reassignments, for example, you must manually replace the terminated employee with another employee on the territory team or sales account team. 60

69 Securing Chapter 8 Managing Application Users Can I reactivate a terminated employee record? Once you have specified an end date for a resource, it cannot be reversed in Oracle Sales. However, the ex-employee's record remains in the system so you can re-identify that person as a resource if the person is rehired. After that, you will need to do role and organization assignment again. 61

70 Securing Chapter 8 Managing Application Users 62

71 Chapter 9 Securing 9 Using the Security Console Using the Security Console Security Tools and Interfaces: How They Work Together This topic describes the interfaces and tools that you use to manage all aspects of security. It also describes the Oracle Fusion Middleware components that play a role in security management and identifies the few tasks for which you may interact with them directly. Specifically, this topic describes: Oracle Identity Management. The identity store for Oracle Fusion Applications. Oracle Entitlements Server (Authorization Policy Manager). The policy store for Oracle Fusion Applications. Security Console. A centralized interface to middleware components that can be used to perform role management and certificate management tasks. Tasks You perform many security-related tasks from an implementation project or from the Setup and Maintenance work area. This table identifies those security tasks and indicates whether the task accesses a work area in or an Oracle Fusion Middleware component. It also indicates whether or not you can use the Security Console to perform the task. Task Description Tool or Interface Security Console Manage Job Roles Review, manage, and create job and abstract roles. Oracle Identity Manager. Yes Manage Duties Review, manage, and create duty roles. Oracle Entitlements Server Authorization Policy Manager. Yes Manage Data Security Policies Manage data security policies. Oracle Entitlements Server Authorization Policy Manager. Yes Manage HCM Role Provisioning Rules Manage role mappings. Manage Role Mappings work area in Oracle Sales Cloud. No Manage Users Create and manage user accounts. Manage Users work area in. No 63

72 Chapter 9 Securing Task Manage Enterprise HCM Information Using the Security Console Description Tool or Interface Manage user-accountcreation options. Enterprise work area in. Security Console No Oracle Security Console The Oracle Fusion Applications Security Console is an easy-to-use administrative interface that you access by selecting Tools - Security Console on the home page or from the Navigator. You use the Security Console for most rolemanagement tasks. For example, use the Security Console to: Review predefined job, abstract, and duty roles. Create and manage custom job, abstract, and duty roles. Typically, you copy a predefined role and use it as the basis for a custom role. Review the roles assigned to users. Compare roles. Simulate the Navigator for a user or role. Oracle Identity Management Oracle Identity Management, a component of Oracle Fusion Middleware, is the identity store for Oracle Fusion Applications. It holds: Definitions of job and abstract roles User accounts Information about roles provisioned to users The Manage Job Roles task accesses Oracle Identity Management directly. However, you're recommended to manage job and abstract roles on the Security Console instead. This recommendation means that you must set up the Security Console before you manage job and abstract roles. Some security-related processes, such as Retrieve Latest LDAP Changes, communicate directly with Oracle Identity Management. Such processes enable to remain synchronized with Oracle Identity Management. Oracle Entitlements Server Authorization Policy Manager Oracle Entitlements Server Authorization Policy Manager, a component of Oracle Fusion Middleware, is a tool for managing the policy store for Oracle Fusion Applications. The policy store holds definitions of duty roles and function security privileges. Authorization Policy Manager can also be used to manage data security policies, which exist in the Applcore grants tables in the Oracle Fusion Applications database. The following tasks access Authorization Policy Manager directly. Manage Duties Manage Data Security Policies 64

73 Securing Chapter 9 Using the Security Console However, you're recommended to manage duty roles on the Security Console instead. This recommendation means that you must set up the Security Console before you manage duty roles. You can manage data security policies on the Security Console. However, you must set the Enable Data Security Policies and User Membership Edit profile option (ASE_ROLE_MGMT_PREF) to Yes first. Setting Up the Security Console To prepare the Security Console for use, set two profile options, Security Console Working App Stripe and Enable Data Security Policies and User Membership Edit. Also run an Import User and Role Application Security Data process, and configure options in the Administration page of the Security Console. Profile Options To set the profile options, search for and select the Manage Administrator Profile Values task in the Setup and Maintenance work area. Then search for and select each option. The Security Console Working App Stripe profile option (ASE_WORKING_APP_STRIPE) specifies a policy stripe within the policy store. In effect, this option selects an application whose roles are available to be worked with in the Security Console. For example, if you copy a job role in the Security Console, then you see inherited duty roles belonging to the application designated by your policy-stripe selection. The default policy-store application is HCM. To see roles inherited from another application, update the profile option to change to that application. (Note that some roles inherit from multiple applications.) Defining user-level values for this profile option allows different users to view different application stripes. The Enable Data Security Policies and User Membership Edit profile option (ASE_ROLE_MGMT_PREF) determines whether users can enter data in the Data Security Policies page and the User page of the Security Console rolecreation and role-edit trains. Import User and Role Process The Import User and Role Application Security Data process copies users, roles, privileges, and data security policies from the identity store, policy store, and ApplCore grants schema to Oracle Cloud Applications Security tables. Run the process to populate Applications Security tables. Then schedule it to run regularly to update those tables. Select Scheduled Processes in the Tools work area, and then select the process from the Schedule New Process option. You are recommended to schedule the Import User and Role Application Security Data process to run at the same frequency as the Retrieve Latest LDAP Changes and Send Pending LDAP Requests processes. With each scheduled run, the process copies only changes made since its previous run. Administration Options Within the Security Console, select the Administration tab to set these options: Role Copy Preferences: Create the prefix and suffix added to the name and code of role copies. Each role has a Role Name (a display name) and a Role Code (an internal name). When a user copies a role, the copy adopts the name and code of the source role, with this prefix or suffix (or both) added to distinguish the copy from its source. By default there is no prefix, the suffix for a role name is "Custom," and the suffix for a role code is "_CUSTOM." Certificate Preferences: Set the number of days for which a certificate remains valid. (Certificates establish keys for the encryption and decryption of data that Oracle Cloud applications exchange with other applications.) 65

74 Securing Chapter 9 Using the Security Console Security Console Visualizations A Security Console visualization consists of nodes representing users, roles, privileges, or aggregate privileges. Arrows connect the nodes to define relationships among them. You can trace paths from any item in a role hierarchy either toward users who are granted access or toward the privileges that roles can grant. Note Aggregate privileges, which combine the functional privilege for an individual task or duty with the relevant data security policies, are not defined in. In a visualization, nodes form circular (or arc) patterns. The nodes in each circle relate directly to a node at the center of the circle. That focal node represents the item you select to generate a visualization, or one you expand in the visualization. For example, a job role might consist of several duty roles. If you were to select the job role as the focus of a visualization (and if you set the Security Console to display paths leading toward privileges), an initial image would show nodes representing the duty roles encircling a node representing the job role. You could then manipulate the image (as described in the following sections). Expand or Collapse Nodes You can expand nodes or collapse them. To expand a node is to reveal roles, privileges, or users to which it connects. To collapse a node is to hide those items. In the earlier example, you might expand one of the duty-role nodes. It would then occupy the center of its own circle of nodes. Each would represent a subsidiary duty role or a privilege belonging to the duty role you expanded. To expand or collapse nodes: 1. Make a selection in the Expand Toward option to determine whether nodes expand toward privileges or toward users. (In the example, the expand toward privileges option would have been selected.) 2. Select a node and right-click. 3. Select one of these options: Expand reveals nodes to which the selected node connects directly, and Collapse hides those nodes. Expand All reveals all generations of connecting nodes, and Collapse All hides those nodes. These options appear only when appropriate. For example, a Collapse option appears only when the selected node is already expanded. Enlarge or Reduce the Image You can enlarge or reduce a visualization. If the image is large enough, each node displays the name of the item it represents. If the image is smaller, symbols replace the names: U signifies user, R signifies role, P signifies privilege, and A signifies aggregate privilege. If the image is smaller still, the nodes are unlabeled. Use tools located at the upper right of a visualization: Plus: Zoom in (enlarge the image). You can also use the mouse wheel to zoom in. Minus: Zoom out (reduce the image). You can also use the mouse wheel to zoom out. 66

75 Securing Chapter 9 Using the Security Console Circle: Click to activate a magnifying glass. When this feature is active, hover over nodes to enlarge them temporarily. You can use the mouse wheel to zoom in or out of the area beneath the magnifying glass. Click the circle button again to deactivate the magnifying glass. Square: Click to center the image and size it so that it is as large as it can be and still fit entirely in its display window. (Nodes that you have expanded remain expanded.) Enhance Your View Use these techniques to enhance your view of a visualization, or of nodes within it: If nodes are labeled with symbols or are unlabeled, hover over any node to display the name of the user, role, or privilege it represents. Click the background of the visualization, then drag the entire image in any direction. Create Related Visualizations You can select any node in a visualization as the focal point for a new visualization: Right-click a node, then select Set as Focus. Simulating Navigator Menus in the Security Console You can simulate Navigator menus available to roles or users. From a simulation, you can review the access inherent in a role or granted to a user, or determine how you can alter that access to create new roles. Opening a Simulation Open a simulated menu from the Security Console: 1. Create a visualization, or populate the Search Results column with a selection of roles or users. 2. In a visualization, right-click on a role or user. Or, in the Search Results column, left-click on the button near the lower right corner of the listing for a role or user. 3. Select Simulate Navigator. Working with the Simulation A simulated Navigator panel lists menu and task entries. A padlock icon next to an entry indicates that it can be, but is not currently, authorized for the role or user. An entry without a padlock icon is already authorized for the role or user. To plan how this authorization may be altered: 1. Click on any blue menu entry. 2. Select either of two options: One lists roles that grant access to the menu item. 67

76 Securing Chapter 9 Using the Security Console The other lists privileges required for access to the menu item. Security Console Analytics Use the Analytics page in the Security Console functional area to review statistics about: Role Categories. Each role belongs to a category that defines some common purpose. Typically, a category contains a type of role configured for an application, for example "Financials - Duty Roles." For each category, a Roles Category grid displays the number of: Roles Role memberships (roles belonging to other roles within the category) Function security policies and data security policies created for those roles In addition, a Roles by Category pie chart compares the number of roles in each category with those in other categories. Roles in Category. List the roles belonging to a category that you select by clicking on that category in the Role Categories grid. For each role, the Roles in Category grid also shows the number of: Role memberships Function security policies and data security policies Users assigned the role Individual role statistics. Click the name of a role in the Roles in Category grid to open a page that lists the function security policies, data security policies, and users associated with the role. The page also presents collapsible diagrams of hierarchies to which the role belongs. Click Export to export data from this page to a spreadsheet. FAQs for Using the Security Console How can I select security items to visualize? Enter text in the Search field. A search-suggestions dialog box lists roles, privileges, or users whose names contain the text you entered. Select one of these items in either of two ways. Select an item directly from the search-suggestions dialog box. Click the Search button (next to the Search field). The search-suggestions dialog box closes, and all items that occupied it appear in the Search Results column. Select an item there. 68

77 Securing Chapter 9 Using the Security Console You can filter the Search Results column before you select an item from it. Click Refine and, in a Refine Search Results window, select an item type. The column then shows only items of the selected type whose names contain the search text. 69

78 Securing Chapter 9 Using the Security Console 70

79 Securing 10 Chapter 10 Reviewing Roles and Role Assignments Reviewing Roles and Role Assignments Reviewing Roles and Role Assignments on the Security Console You can use the Security Console to: View the roles assigned to a user. Identify users who have a specific role. You must have the IT Security Manager job role to perform these tasks. Viewing the Roles Assigned to a User 1. On the home page, click Tools - Security Console. 2. On the Security Console, search for and select the user. A visualization appears showing the user and any roles that the user inherits directly. User and role names appear on hover. To expand an inherited role: 1. Select the role and right-click. 2. Select Expand. Identifying Users Who Have a Specific Role To identify all users who have a specific role: 1. On the Security Console, search for and select the role. A visualization appears showing the role and its hierarchy. 2. Set Expand Toward to Users. Tip Set the Expand Toward option to control whether the visualization moves up the hierarchy from the selected role (toward users) or down the hierarchy from the selected role (toward privileges). In the refreshed visualization, solid blue circles identify users. User names appear on hover. Users may inherit roles either directly or indirectly from other roles, which appear as solid green circles. Expand a role to view its hierarchy. 71

80 Chapter 10 Securing Reviewing Roles and Role Assignments Reviewing Job and Abstract Roles on the Security Console You can use the Security Console to review the role hierarchy of a job role or abstract role. You must have the IT Security Manager job role to perform this task. Follow these steps: 1. On the home page, click Tools - Security Console. 2. On the Security Console, ensure that Expand Toward is set to Privileges. 3. Search for the role. In the Oracle Entitlements Server Authorization Policy Manager, job and abstract roles have both an external role and an application role. Both roles appear in the Security Console search results. Application roles have the suffix (Application role). 4. Select the external role to view the complete role hierarchy. A visualization appears showing any roles that the role inherits directly. 5. To expand the hierarchy of any inherited role, select it, right-click, and select Expand. In the visualization, single-letter labels have the following meanings: Letter Security Artifact A Aggregate privilege Aggregate privileges are not defined for Oracle Sales Cloud roles. P Function security privilege R Role Role and privilege names appear on hover. Tip To review any function security privileges granted directly to a job or abstract role, review its application role rather than its external role on the Security Console. Comparing Roles Compare any two roles to see the structural differences between them. For example, assume you have copied a role and customized the copy. You then upgrade to a new release. You can compare your customized role from the earlier release 72

81 Securing Chapter 10 Reviewing Roles and Role Assignments with the role as shipped in the later release, to determine whether you want to incorporate upgrade changes into your custom role. 1. Begin the process from the Security Console, in either of two ways: Click the Compare Roles button. Create a visualization, right-click one of its roles, and select the Compare Roles option. 2. Select roles for comparison: If you began by clicking the Compare Roles button, select roles in both First Role and Second Role fields. If you began from a visualization, the First Role field displays the name of the role you selected in the visualization. Select another role in the Second Role field. For either field, click the search icon, enter text, and select from a list of roles whose names contain that text. 3. Filter for any combination of these artifacts in the two roles: Function security policies Data security policies Inherited roles 4. For the combination you select, choose whether to show: All artifacts Those that exist only in one role, or only in the other role Those that exist only in both roles 5. Click the Compare button. After you create the initial comparison, you can change the filter and show options. When you do, a new comparison is generated automatically. User and Role Access Audit Report Reference The User and Role Access Audit Report documents role hierarchies. Run the report to view all roles, privileges, and data security policies for: One user. All users. One role. 73

82 Securing Chapter 10 Reviewing Roles and Role Assignments All roles. Run the User and Role Access Audit Report as a scheduled process. Use the Scheduled Processes work area available from the Navigator. As you run the process, set parameters that focus the report on a user you select, all users, a role you select, or all roles. Report Results The process returns archive (ZIP) files. Each file name contains a prefix and a suffix that define its content. (Each file name also contains values that identify the process number, and the process run date and time.) If you select an individual user, the process returns: File Name File Content Description USER_ NAME_ [PROCESS]_ [DATE]_ [TIME]_ DataSec.zip One XML file documenting data security policies that apply to the selected user. USER_ NAME_ [PROCESS]_ [DATE]_ [TIME]_ Hierarchical. zip One XML file that documents functional security for the selected user. Its format depicts hierarchical relationships among security artifacts. USER_ NAME_ [PROCESS]_ [DATE]_ [TIME]_ TabularFormat. zip One XML file that documents functional security for the selected user. Its format is tabular (flattened). If you select an individual role, the process returns: File Name File Content Description ROLE_ NAME_ [PROCESS]_ [DATE]_ [TIME]_ DataSec.zip One XML file documenting data security policies that apply to the selected role. ROLE_ NAME_ [PROCESS]_ [DATE]_ [TIME]_ Hierarchical. zip One XML file that documents functional security for the selected role. Its format depicts hierarchical relationships among security artifacts. ROLE_ NAME_ [PROCESS]_ [DATE]_ [TIME]_ TabularFormat. zip One XML file that documents functional security for the selected role. Its format is tabular (flattened). If you select all users, the process returns: File Name File Content Description ALL_ USERS_ [PROCESS]_ [DATE]_ [TIME]_ DataSec.zip Multiple XML files, one for each user. Each documents data security policies that apply to its user. 74

83 Chapter 10 Securing Reviewing Roles and Role Assignments File Name File Content Description ALL_ USERS_ [PROCESS]_ [DATE]_ [TIME]_ Hierarchical. zip Multiple XML files, one for each user. Each documents functional security for its user, in a format that depicts hierarchical relationships among security artifacts. ALL_ USERS_ [PROCESS]_ [DATE]_ [TIME]_ CSV.zip A comma-separated-values file that documents functional security for all users in a tabular (flattened) format. If you select all roles, the process returns: File Name File Content Description ALL_ ROLES_ [PROCESS]_ [DATE]_ [TIME]_ DataSec.zip Multiple XML files, one for each role. Each documents data security policies that apply to its role. ALL_ ROLES_ [PROCESS]_ [DATE]_ [TIME]_ Hierarchical. zip Multiple XML files, one for each role. Each documents functional security for its role, in a format that depicts hierarchical relationships among security artifacts. ALL_ ROLES_ [PROCESS]_ [DATE]_ [TIME]_ CSV.zip A comma-separated-values file that documents functional security for all roles in a tabular (flattened) format. The process also returns a diagnostic log (in the form of a ZIP file). 75

84 Securing Chapter 10 Reviewing Roles and Role Assignments 76

85 Securing 11 Chapter 11 Certificate Management Certificate Management Managing Certificates Certificates establish keys for the encryption and decryption of data that Oracle Cloud applications exchange with other applications. Use the Certificates page in the Security Console functional area to work with certificates in either of two formats, PGP and X.509. For each format, a certificate consists of a public key and a private key. The Certificates page displays one record for each certificate. Each record reports these values: Type: For a PGP certificate, "Public Key" is the only type. For an X.509 certificate, the type is either "Self-Signed Certificate" or "Trusted Certificate" (one signed by a certificate authority). Private Key: A check mark indicates that the certificate's private key is present. For either certificate format, the private key is present for your own certificates (those you generate in the Security Console). The private key is absent when a certificate belongs to an external source and you import it via the Security Console. Status: For a PGP certificate, the only value is "Not Applicable." (A PGP certificate has no status.) For an X.509 certificate, the status is derived from the certificate. To the right in the row for each certificate, click a button to display a menu of actions appropriate for the certificate. Or, to view details for a certificate, select its name ("alias"). Actions include: Generate PGP or X.509 certificates. Generate signing requests to transform X.509 certificates from self-signed to trusted. Export or import PGP or X.509 certificates. Delete certificates. Generating Certificates For a PGP or X.509 certificate, one operation creates both the public and private keys. From the Certificates page, select the Generate option. In a Generate page, select the certificate format, then enter values appropriate for the format. For a PGP certificate, these values include: An alias (name) and passphrase to identify the certificate uniquely. The algorithm by which keys are generated, DSA or RSA. A key length. For an X.509 certificate, these values include: An alias (name) and private key password to identify the certificate uniquely. 77

86 Securing Chapter 11 Certificate Management A common name. An element of the "distinguished name" for the certificate, the common name identifies the entity for which the certificate is being created, in its communications with other web entities. It must match the name of the entity presenting the certificate. The maximum length is 64 characters. Optionally, other identifying values: Organization, Organization Unit, Locality, State/Province, and Country. These are also elements of the distinguished name for the certificate, although the Security Console does not perform any validation on these values. An algorithm by which keys are generated, MD5 or SHA1. A key length. A validity period, in days. This period defaults to a value set on the Administration page. You can enter a new value to override the default. Generating a Signing Request You can generate a request for a certificate authority (CA) to sign a self-signed X.509 certificate, to make it a trusted certificate. (This process does not apply to PGP certificates.) 1. Select Generate Certificate Signing Request. This option is available in either of two menus: One opens in the Certificates page, from the row for a self-signed X.509 certificate. The other is the Actions menu in the details page for that certificate. 2. Provide the private key password for the certificate, then select a file location. 3. Save the request file. Its default name is [alias]_csr.csr. You are expected to follow a process established by your organization to forward the file to a CA. You would import the trusted certificate returned in response. Importing and Exporting X.509 Certificates For an X.509 certificate, you import or export a complete certificate in a single operation. To export: 1. From the Certificates page, select the menu available in the row for the certificate you want to export. Or open the details page for that certificate and select its Actions menu. 2. In either menu, select Export, then Certificate. 3. Select a location for the export file. By default, this file is called [alias].cer. There are two types of import: The first replaces a self-signed certificate with a trusted version (one signed by a CA) of the same certificate. (A prerequisite is that you have received a response to a signing request.) a. In the Certificates page, locate the row for the self-signed certificate, and open its menu. Or, open the details page for the certificate, and select its Actions menu. In either menu, select Import. 78

87 Securing Chapter 11 Certificate Management b. Enter the private key password for the certificate. c. Browse for and select the file returned by a CA in response to a signing request, and click the Import button. In the Certificates page, the type value for the certificate changes from self-signed to trusted. The second imports a new X.509 certificate. You can import a.cer file, or you can import a keystore that contains one or more certificates. a. In the Certificates page, click the Import button. An Import page opens. b. Select X.509, then choose whether you are importing a certificate or a keystore. c. Enter identifying values, which depend on what you have chosen to import. In either case, enter an alias (which, if you are importing a.cer file, need not match its alias). For a keystore, you must also provide a keystore password and a private key password. d. Browse for and select the import file. e. Select Import and Close. Importing and Exporting PGP Certificates For a PGP certificate, you export the public and private keys for a certificate in separate operations. You can import only public keys. (The assumption is that you will import keys from external sources, who will not provide their private keys to you.) To export: 1. From the Certificates page, select the menu available in the row for the certificate you want to export. Or open the details page for that certificate and select its Actions menu. 2. In either menu, select Export, then Public Key or Private Key. 3. If you selected Private Key, provide its passphrase. (The public key does not require one.) 4. Select a location for the export file. By default, this file is called [alias]_pub.asc or [alias]_priv.asc To import a new PGP public key: 1. On the Certificates page, select the Import button. 2. In the Import page, select PGP and specify an alias (which need not match the alias of the file you are importing). 3. Browse for the public-key file, then select Import and Close. The Certificates page displays a record for the imported certificate, with the Private Key cell unchecked. Use a distinct import procedure if you need to replace the public key for a certificate you have already imported, and do not want to change the name of the certificate: 1. In the Certificates page, locate the row for the certificate whose public key you've imported, and open its menu. Or, open the details page for the certificate, and select its Actions menu. In either menu, select Import. 79

88 Securing Chapter 11 Certificate Management 2. Browse for the public-key file, then select Import. Deleting Certificates You can delete both PGP and X.509 certificates. In the Certificates page, select the menu available in the row for the certificate you want to delete. Or, in the details page for that certificate, select the Actions menu. In either menu, select Delete, then respond to a warning message. 80

89 Securing 12 Chapter 12 Customizing Security Customizing Security Overview This chapter describes some of the ways in which you can customize the security model. The Oracle implementation of role-based access control (RBAC) is designed to handle a wide range of security requirements in different environments. As a result, most companies can use the standard security settings without modification. If necessary, however, you can configure the default settings to meet specific business requirements. For example, you can create custom roles and role hierarchies. Before making any changes to the security reference implementation, however, do the following: Clearly define the change that is required and review the proposed changes with Oracle Support. Make sure you understand the interrelationships of the various security components and the effect of the proposed change on user access. Document any changes you make. In general, changes to the standard security settings take place in Authorization Policy Manager. Most changes take immediate effect; changes to the role hierarchy can, however, take up to 20 minutes to be processed. Note Never edit the predefined roles (you can identify predefined application roles by the ORA prefix in the role code). Instead, you must copy the predefined roles and edit the copies, or create custom roles from scratch. For additional information about changing the standard security settings for specific releases of, go to the Security Resource Center, which is available at (Article ID) on My Oracle Support. The Security Resource Center provides detailed instructions for performing security configuration tasks, and provides templates you can use to track the changes you make to standard settings. Copying Job or Abstract Roles Using the Security Console On the Security Console, you can copy any job role or abstract role and use it as the basis for a custom role. Copying roles is more efficient than creating them from scratch, especially if your changes are minor. This topic explains how to copy and edit a role to create a custom role. You must have the IT Security Manager job role to perform this task. Important Never edit the predefined roles. You can identify predefined application roles easily by their role codes, which start with the prefix ORA_. Copying a Job or Abstract Role Follow these steps: 1. On the Security Console, search for the role to copy. 81

90 Securing Chapter 12 Customizing Security In the Oracle Entitlements Server Authorization Policy Manager, job and abstract roles have both an external role and an application role. Both roles appear in the Security Console search results. 2. Select the relevant external role. Note Application roles have the name suffix (Application role). External roles have no name suffix. A visualization of the role appears, showing its role hierarchy. 3. In the search results, click the down arrow for the selected external role and select Copy Role. 4. In the Copy Options dialog box, select a copy option. If you select Copy top role, then only the selected role is copied. The copied role inherits the same role instances as the source role. If you select Copy top role and inherited roles, then a copy is made of every role in the role hierarchy. Note When you copy an external role, the associated application role is copied automatically, regardless of the copy option that you select. 5. Click Copy Role. 6. On the Copy Role: Basic Information page, edit the Role Name, Role Code, and Description values, as appropriate. By default, the Role Name and Role Code values are copied from the source role and a suffix is added. You can specify default prefix and suffix values on the Administration page of the Security Console. Note The prefix ORA_ is removed automatically from the role code of any application role that you copy. 7. Click Next. Managing Functional Security Policies The Copy Role: Functional Security Policies page is read-only for external roles. To review and edit any functional security privileges granted to the copied role, you must edit its application role. Managing Data Security Policies By default, the Copy Role: Data Security Policies page is read-only for users. To use the Data Security Policies page to manage data security policies, the profile option Enable Data Security Policies and User Membership Edit must be set to Yes. For additional information on enabling this option and managing data security policies on the Security Console, see the topic Managing Data Security Policies on the Security Console. 82

91 Securing Chapter 12 Customizing Security Click Next. Adding and Removing Inherited Roles The Copy Role: Role Hierarchy page shows a visualization of the copied job or abstract role and its inherited roles. You can add or remove roles. Typically, you add duty roles directly to a job or abstract role. Tip The application role associated with the external role isn't visible on the Copy Role: Role Hierarchy page. However, you see it when you view your saved custom role subsequently on the Security Console. To remove an inherited role: 1. Select the role in the visualization and right-click to open the actions menu. 2. Select Delete. 3. Click OK to close the confirmation message. To add a role: 1. Click Add Role. 2. In the Add Role Membership dialog box, search for and select the role to add. 3. Click Add Role Membership. 4. Click OK to close the confirmation message. 5. When you finish adding roles, close the Add Role Membership dialog box. The role visualization shows the updated role hierarchy. 6. Click Next. Viewing Users Assigned the Role A copied role cannot inherit users from the source job or abstract role. The Copy Role: Users page allows you to view the users who are assigned the source role you are copying and to edit this information for the new custom role. By default, the Copy Role: Users page is read-only for users. To use the Copy Role: Users page to provision the custom role to users, the profile option Enable Data Security Policies and User Membership Edit must be set to Yes. If the profile option is set to No, to provision the copied role you must create a role mapping in the usual way. For additional information on enabling the profile option, see the topic Managing Data Security Policies on the Security Console. Click Next. Reviewing the Role On the Copy Role: Summary and Impact Report page, review the summary of changes. Click Back to make corrections. Otherwise: 1. Click Save and Close to save the role. 83

92 Securing Chapter 12 Customizing Security 2. Click OK to close the confirmation message. The role is available immediately on the Security Console. To make the role available elsewhere in, you must run the Retrieve Latest LDAP Changes process. Tip Search for the role on the Security Console and review its visualization. Edit the role to make any corrections. Editing the Copied Application Role Once your custom role exists, you can review and edit its application role on the Security Console. To manage functional security privileges granted directly to the copied role, edit its application role. On the Edit Role: Functional Security Policies page, any functional security privileges granted to the copied application role appear. Select a privilege to view details of the code resources that it secures. To remove a privilege from the role: 1. Select the privilege and click the X icon. To add a privilege to the role: 1. Click Add Functional Security Policy. 2. In the Add Functional Security Policy dialog box, search for and select a privilege or role. 3. If you select a role, then click Add All Privileges to Role to add all functional security privileges from the role to your custom role. If you select a single privilege, then click Add Privilege to Role. 4. Click OK to close the confirmation message. 5. Repeat from step 2 for additional privileges. 6. Close the Add Functional Security Policy dialog box. 7. On the Edit Role: Impact and Summary Report page, click Save and Close to save any changes. Copying Sales Roles: Points to Consider Copying predefined roles and editing the copies is the recommended approach to creating custom roles. This topic describes some decisions that you must make when copying a role on the Security Console. Copying the Top Role If you select the Copy top role option when copying a role, then memberships are created for the copy in the roles of which the original is a member. Subsequent changes to those roles are reflected in your copy. Therefore: You can add roles directly to the copied role without affecting the source role. You can remove any role that's inherited directly by the copied role without affecting the source role. If you remove any role that's inherited indirectly by the copied role, then the removal affects both the copied role and any other role that inherits the removed role's parent role, including the source role. 84

93 Securing Chapter 12 Customizing Security If you edit any inherited role, then the changes affect any role that inherits the edited role. The changes aren't limited to the copied role. Important You must not edit predefined roles at any level of the role hierarchy. Predefined application roles have role codes with the prefix ORA_. If you need to edit the inherited roles, then you must select the Copy top role and inherited roles option instead. This option makes copies of the inherited roles, which you can edit without affecting other roles. Tip The Copy Role: Summary and Impact Report page provides a useful summary of your changes. Review this information to ensure that you haven't accidentally made a change that will affect other roles. Copying the Top Role and Inherited Roles If you select Copy top role and inherited roles, then the entire role hierarchy is copied. You can make changes to the hierarchy without affecting other roles. Equally, changes made subsequently to the source role hierarchy aren't reflected in the copied role. Reviewing All Inherited Roles The copied role might inherit roles not only from the crm application but also from other applications, for example, hcm. To see roles inherited from other application stripes, you must set the profile option Security Console Working App Stripe to the appropriate value. Naming Copied Roles By default, a copied external role has the same name as its source role with the suffix Custom. The role codes of copied roles have the suffix _CUSTOM. Copied application roles lose the prefix ORA_ automatically from their role codes. You can define a local naming convention for custom roles, with a prefix, suffix, or both, on the Administration tab of the Security Console. Related Topics Setting Up the Security Console: Explained Creating a Job or Abstract Role in Oracle Identity Manager If the predefined job or abstract roles don't meet enterprise requirements, then you can create new job or abstract roles. For example, you might want to create a new job role because the duties inherited by a predefined job role aren't as required. This topic describes how to create a job role. This procedure has three stages: 1. Create the job role in Oracle Identity Manager (OIM) using the Manage Job Roles task. 2. Add duty roles to the new job role in Authorization Policy Manager using the Manage Duties task. In Authorization Policy Manager, duty roles are known as application roles. 85

94 Securing Chapter 12 Customizing Security 3. Run the Retrieve Latest LDAP Changes process in. This process makes your custom role available in. Note You can also create job and abstract roles using the Security Console. Creating the Job Role Sign in to with the IT Security Manager job role and follow these steps. 1. Navigate to the Setup and Maintenance work area. 2. On the All Tasks tab of the Overview page, search for and select the task Manage Job Roles. 3. In the search results list, click the Go to Task icon. The Oracle Identity Manager Self-Service page opens. 4. On the Welcome tab of the Oracle Identity Manager Self-Service page, click the Administration link in the top-right corner. The Oracle Identity Manager - Delegated Administration page opens. 5. In the Roles section of the Welcome tab, click Create Role. The Create Role page opens. 6. In the Name field, enter the name of the new role, for example, INSIDE_SALES_REP_JOB. 7. In the Display Name field, enter the display name of the job, for example, Inside Sales Representative. 8. In the Role Category Name field, search for and select CRM - Job Roles. Note When you create a custom job role, the Role Category Name value must end with Job Roles. Otherwise, the custom role won't display in job role lists in Page Composer. 9. Click Save. The job role is now created in the LDAP identity store. Close the OIM browser window to return to the Oracle Fusion Applications Setup and Maintenance work area. Assigning Duties to the Job Role Follow these steps to assign one or more duties to the new job role. 1. Navigate to the Setup and Maintenance work area. 2. On the All Tasks tab of the Overview page, search for and select the Manage Duties task. 3. In the search results list, click the Go to Task icon. The Oracle Entitlements Server page opens. 4. In the Application Name section of the Authorization Management page, select crm. 5. In the Search section, search for the new job role you created. A job role is an external role with a global scope, so specify the following search criteria: For External Roles In Global Scope 86

95 Securing Chapter 12 Customizing Security In the search text box, enter the name of the job role you created, for example, Inside Sales Representative. 6. In the search results area, right-click the role and select View. 7. On the role page, click the Application Role Mapping tab. 8. Click Map. The Map Application Roles to External Role dialog box opens. In the Application field in the Map Application Roles to External Roles dialog box, select crm. In the Display Name field, enter the name of the duty role that you want to add, for example, Sales Representative, and click Search. Select the role in the Search Results, and click Map Roles. Tip The selected role appears under the crm folder on the Application Role Mapping tab of the role page. You can also delete duty roles on this tab. 9. Repeat Step 8 for additional duty roles. Close the Authorization Management browser window to return to the Setup and Maintenance work area. Running Retrieve Latest LDAP Changes After creating a custom job role or abstract role in Oracle Identity Manager or the Security Console, you must run the Retrieve Latest LDAP Changes process. This process makes the role available to. This topic describes how to run Retrieve Latest LDAP Changes. Note Once implementation is completed, it's recommended that you schedule Retrieve Latest LDAP Changes to run daily. Once the process is scheduled, you can't run it on an as-needed basis. If the process is scheduled when you create a custom job or abstract role, then you can wait for the process to complete its daily run. Once that run completes, the custom role is available in Oracle Sales. Alternatively, if you can't wait for the daily process, then you can end the scheduling temporarily and run the process as described here. When the process completes, you can schedule it again. Running Retrieve Latest LDAP Changes Sign in to with the IT Security Manager job role and follow these steps: 1. Select Navigator - Tools - Scheduled Processes to open the Scheduled Processes work area. 2. Click Schedule New Process. The Schedule New Process dialog box opens. 87

96 Securing Chapter 12 Customizing Security 3. In the Name field, search for and select the Retrieve Latest LDAP Changes process. 4. Click OK to close the Schedule New Process dialog box. 5. In the Process Details dialog box, click Submit. 6. Click OK, then Close. 7. On the Scheduled Processes page, click Refresh. Repeat this step periodically until the process completes. Once the process completes successfully, your custom role is available in interfaces. Copying and Editing Duty Roles Using the Security Console On the Security Console, you can copy a duty role and edit the copy to create a custom duty role. Copying duty roles is the recommended way of creating custom duty roles. This topic explains how to copy a duty role and edit the copy. You must have the IT Security Manager job role to perform these tasks. Important Never edit the predefined duty roles. You can identify predefined duty roles easily by their role codes, which have the prefix ORA_. Copying a Duty Role Follow these steps: 1. On the Security Console, search for and select the duty role to copy. A visualization of the role appears, showing any role hierarchy. 2. In the search results, click the down arrow for the selected role and select Copy Role. 3. In the Copy Options dialog box, select a copy option. If you select Copy top role, then only the selected role is copied. The copied role inherits the same role instances as the source role. If you select Copy top role and inherited roles, then a copy is made of every role in the role hierarchy. 4. Click Copy Role. 5. On the Copy Role: Basic Information page, edit the Role Name, Role Code, and Description values, as appropriate. By default, the Role Name and Role Code values are copied from the source role and a suffix is added. The prefix ORA_ is removed automatically from the role code. You can override the default suffix and also specify a default prefix on the Administration page of the Security Console. 88

97 Securing Chapter 12 Customizing Security 6. Click Next. Managing Functional Security Policies On the Copy Role: Functional Security Policies page, any function security privileges granted to the duty role appear. Select a privilege to view details of the code resources that it secures. To remove a privilege from the role: 1. Select the privilege and click the X icon. To add a privilege to the role: 1. Click Add Functional Security Policy. 2. In the Add Functional Security Policy dialog box, search for and select a privilege or role. 3. If you select a role, then click Add All Privileges to Role to grant all function security privileges from the role to your custom role. If you select a single privilege, then click Add Privilege to Role. 4. Click OK to close the confirmation message. 5. Repeat from step 2 for additional privileges. 6. Close the Add Functional Security Policies dialog box. 7. Click Next. Managing Data Security Policies By default, the Copy Role: Data Security Policies page is read-only for users. To use the Data Security Policies page to manage data security policies, the profile option Enable Data Security Policies and User Membership Edit must be set to Yes. For additional information on enabling this option and managing data security policies on the Security Console, see the topic Managing Data Security Policies on the Security Console: Explained. Click Next. Adding and Removing Inherited Roles The Copy Role: Role Hierarchy page shows the copied duty role and any duty roles that it inherits. To remove an inherited role: 1. Select the role in the visualization and right-click to open the actions menu. 2. Select Delete. 3. Click OK to close the information message. To add a role: 1. Click Add Role. 2. In the Add Role Membership dialog box, search for and select the role to add. 3. Click Add Role Membership. 89

98 Securing Chapter 12 Customizing Security 4. Click OK to close the confirmation message. 5. When you finish adding roles, close the Add Role Membership dialog box. The role visualization shows the updated role hierarchy. 6. Click Next. Reviewing the Role On the Copy Role: Impact and Summary Report page, review the summary of changes. Click Back to make corrections. Otherwise: 1. Click Save and Close to save the role. 2. Click OK to close the confirmation message. The role is available for use immediately. Tip Search for the role on the Security Console and review its visualization. Edit the role to make any corrections. Managing Data Security Policies on the Security Console By default, you can't manage data security policies on the Security Console. If you're customizing a role and want to remove a data security policy, for example, then you must enable update of data security policies first. This topic describes how to enable update of data security policies. It also describes how to edit, remove, and create data security policies for a custom role. Enabling Update of Data Security Policies The Data Security Policies page in the Create, Copy, and Edit Role processes on the Security Console is read-only for Oracle Sales Cloud users. To enable update, you must set the Enable Data Security Policies and User Membership Edit profile option, as follows: 1. On the home page, click Setup and Maintenance. 2. On the All Tasks tab of the Overview page, search for and select the Manage Administrator Profile Values task. 3. On the Manage Administrator Profile Values page, enter ASE_ROLE_MGMT_PREF in the Profile Option Code field and click Search. 4. Select ASE_ROLE_MGMT_PREF in the search results and set the profile value to Yes for the site. 5. Click Save and Close. Note Remember to set this profile value back to No when you finish editing data security policies for a role. 90

99 Chapter 12 Securing Customizing Security Editing, Removing, and Creating Data Security Policies for Custom Roles To create a custom role, you're recommended to copy a predefined role rather than create a role from scratch. In this case, your custom role automatically has the data security policies of the copied role. You can edit or remove the copied data security policies if necessary. You're unlikely to create data security policies unless you create custom roles from scratch. To edit or remove a data security policy for a custom role: 1. On the Data Security Policies page, click the down arrow in the relevant policy row to show the actions menu. 2. To remove the policy, select Remove Data Security Policy. 3. To edit the policy: a. Select Edit Data Security Policy. b. In the Edit Data Security Policy dialog box, you can edit any value. c. Click OK to save your changes, and close the confirmation message. To create a data security policy: 1. On the Data Security Policies page, click Create Data Security Policy. 2. In the Create Data Security Policy dialog box, enter a policy name. The names of predefined data security policies begin with the words Grant on. 3. Search for and select the database resource (for example, the table name). Tip Oracle Enterprise Repository holds details of Oracle Applications Cloud database resources. 4. Set the Data Set value to one of the following values. Value Description Select by key Use for a single object instance. Specify the primary key value that identifies the object instance in the database resource. Select by instance set Use for multiple object instances. All values Use to identify all object instances in the database resource. 91

100 Securing Chapter 12 Customizing Security 5. Complete the remaining fields, which depend on the selected combination of database resource and data set values. 6. In the Actions field, select the actions to which this data security policy applies. 7. Click OK to save the data security policy. Related Topics Security Policies: Explained Creating Custom Duty Roles in Authorization Policy Manager Duty roles are made up of functional security privileges and data security policies. You can create custom duty roles if the predefined duty roles don't meet your needs. For example, a predefined duty role might have more functional security privileges or data security policies than are required. This topic shows how to: Create a duty role. Select existing functional security privileges and add them to a duty role. Select existing data security policies and add them to a duty role. Note You can also create and copy custom duty roles using the Security Console. Creating a Duty Role Sign in to with the IT Security Manager job role and follow these steps: 1. Navigate to the Setup and Maintenance work area. 2. On the All Tasks tab of the Overview page, search for and select the task Manage Duties. 3. In the Search Results list, click Go to Task. The Authorization Management page opens. 4. In the Application Name section of the Home tab, select crm. Under the Application Roles heading on the Home tab, click New. An Untitled tab opens. 5. In the Display Name field on the Untitled tab, enter the display name of the new duty role, for example, Custom Sales Representative. 6. In the Role Name field, enter the name of the new duty role, for example, Custom_Sales_Rep_Duty. 92

101 Securing Chapter 12 Customizing Security 7. In the Role Category field, search for and select the appropriate role category, for example, CRM_DUTY. 8. Click Save. The duty role's display name now appears as the tab name. Adding Functional Security Privileges to a Duty Role In this stage, you create a security policy for the custom duty role you created, and add an existing functional security privilege to it. 1. Click Create Policy in the top-right corner of the duty role tab, then select Default Policy Domain. An Untitled tab opens. 2. In the Display Name field on the Untitled tab, enter the policy name, for example, Policy for Custom Sales Representative. Tip Names of predefined security policies begin with the words Policy for. 3. In the Name field, enter the policy name, for example, CUSTOM_SALES_REP_DUTY_POL. 4. In the Targets section, click the Add Targets icon. The Search Targets dialog box opens. Tip In this context, a target is a functional security privilege and a principal is a role. When a target is granted to the principal, it means that the functional security privilege is granted to the duty role. 5. In the Display Name (Starts With) field on the Entitlements tab, enter the name of the functional security privilege that you want to use, for example, Manage Opportunity Sources, and click Search. In the search results, select the functional security privilege and click Add Selected. The functional security privilege is added to the Selected Targets section. 6. Click Add Targets to save your changes and close the dialog box. 7. On the Untitled tab, click Save. The Untitled tab is updated with the name of the new policy, for example, Policy for Custom Sales Representative. Adding Data Security Policies to the Duty Role In this stage, you'll find the data security policies assigned to an existing duty role and add them to the custom duty role you created. 1. Click the Authorization Management Home tab. On the Home tab, click Search under the Application Roles heading. The Role Catalog page opens. 93

102 Securing Chapter 12 Customizing Security 2. In the Display Name field in the Search Roles section, enter the name of the predefined duty role to be used as a reference for your custom duty role. For example, enter Opportunity Sales Representative and click Search. Select the duty role in the Search Results and click Open. The Opportunity Sales Representative duty role page opens. 3. In the top-right corner of the page, click Find Policies, then select Default Policy Domain. The Search Authorization Policies tab opens. 4. In the Policies for: Opportunity Sales Representative section, select the Data Security tab. The data security policies for the duty role appear on the tab. 5. Select the first data security policy that you want to use and click Edit. 6. On the Data Security Policy: Edit page, select the Roles tab and click the Add icon. The Select and Add: Roles dialog box opens. Search for your new duty role. For example, enter Custom_Sales_Rep_Duty in the Role Name field, select crm as the Application, and click Search. 7. Select the new duty role, for example, Custom Sales Representative, and click OK. A copy of this data security policy now exists against your custom duty role. 8. Click Save. Click OK to close the confirmation window. 9. Repeat steps 5 through 8 to add additional data security policies to your duty role. Your custom duty role is now complete. Verifying the Duty Role In this stage, verify that the custom duty role you created is assigned the functional security privileges and data security policies you mapped to the role. 1. Click the Authorization Management Home tab. 2. On the Home tab, select crm in the Application Name field and select Search under Application Roles. The Search Role Catalog page opens. 3. Search for the custom duty role you created, for example, Custom Sales Representative. In the search results, select the duty role and click Open. The duty role page opens. 4. Click Find Policies, then select Default Policy Domain. In the Policies for: Custom Sales Representative section, click the Functional Policies tab and then the Data Security tab to view the functional security privileges and data security policies you associated with the role. 5. Click the Home tab. You can now assign the custom duty role you created to a job role. 94

103 Securing Chapter 12 Customizing Security Role Optimization Role Optimizer Overview Role optimization is the process used to analyze the existing role hierarchy for redundancies or other inefficiencies. Role optimization enables you to create a role hierarchy that minimizes the number of roles necessary to authorize every job role to its currently authorized privileges. The role optimizer feature automates the analysis process and generates a report you can use to optimize your job hierarchies. Important The use of the Role Optimization Report is not included in the cost of your service subscription or application license and incurs charges in addition to your subscription or licensing fee. Reasons to Optimize Changes to the predefined role hierarchies can put the privacy of your application data at risk. You can unintentionally make your data less secure if you: Create duty roles with small groups of privileges in an attempt to minimize: Dependencies The impact of making incremental changes Grant privileges that already exist in the role hierarchy Roles can proliferate or have duplicative privileges over time to make your role hierarchy less efficient, as you see in the following figure. 95

104 Securing Chapter 12 Customizing Security Benefits of Optimization By using the role optimizer, you can: Increase user productivity. You save time that you can perform other tasks. Lower administrative costs. You reduce the number of security objects and the amount of time you spend maintaining that you must administer them. Decrease access risk associated with undocumented role hierarchy changes. You identify and can eliminate redundant and inappropriate grants of privilege. The role optimizer can suggest more efficient role hierarchies, such as the one you see in this figure. Role Optimizer Access The role optimizer feature is available as a predefined report. Schedule and submit the Role Optimization Report on the Overview page of the Scheduled Processes work area. The process: 1. Analyzes your existing job role hierarchies. 2. Generates the optimized job role hierarchy and stores the data for each job role in a separate CSV file. 3. Archives and attaches the CSV files as the process output. 4. Generates a log and archives it as a ZIP file. The log file includes technical details of the analysis for troubleshooting. 96

105 Chapter 12 Securing Customizing Security Important The role optimization process makes no changes to your security structures. You use the report to map privileges to roles and update the role hierarchies. Report Usage To optimize your roles based on the report, navigate to the Setup and Maintenance work area. Use the Manage Duties task and the Manage Job Roles tasks to update your role hierarchy, as necessary. Role Optimization Report Use the Role Optimization Report to create the most efficient role hierarchy for your organization. Use the report results to evaluate and, if necessary, update your role hierarchy. The report results enable you to create a role hierarchy with the minimum number of roles necessary to authorize every job role to every privilege it is currently authorized to. Important The use of the Role Optimization Report is not included in the cost of your service subscription or application license and incurs charges in addition to your subscription or licensing fee. Users with the IT Security Manager role can run the Role Optimization Report, which is available from the security console. You should run this report if you: Make changes to the predefined role hierarchy. Implement your own role hierarchy instead of the predefined role hierarchy. Important The process makes no changes to your role hierarchies. Note The predefined role hierarchy in the security reference implementation is optimized as delivered. Report Files Monitor the process status on the Overview page. When the status value is Succeeded, two files appear in the Log and Output section of the report details. The following table describes the two files: File Name Description ClusterAnalysis-Job-CSVs. zip Contains one CSV file for every job role. Each CSV file contains the duty roles and privileges that make up the optimized job role hierarchy. The name of a CSV file, identifies the job role hierarchy data that the file contains. For example, the ClustersforJob-AR_ REVENUE_ MANAGER_ JOB_ csv file contains all of the role hierarchy data for the Accounts Receivables Revenue Manager job role. 97

106 Chapter 12 Securing File Name Customizing Security Description Diagnostics. zip Contains a log file that provides technical details about the analysis process. You can use this file for troubleshooting purposes. Import the raw data from the CSV file into your preferred application to read the results. Report data appears in these two sections: Privilege Clusters Cluster Details Role Optimization Report Results Privilege Clusters The Privilege Clusters section lists each privilege and the name of a recommended privilege cluster. Specific cluster recommendations are described in the cluster details section. Cluster Details A Cluster Details section appears for each privilege cluster referenced in the Privilege Clusters section. Each detail section includes: Cluster name. Names of recommended candidate roles that map to the privilege cluster. Names and descriptions of the jobs and privileges associated with the cluster. This table provides descriptions of the fields that appear the Cluster Details section: Field Name Description Cluster Name The name of the optimized cluster, usually in this format: Cluster ### Primary, Secondary, Tertiary Candidate Role Recommended role mappings for the privileges in the cluster. Up to three recommended duty roles map to the listed privileges. Select a role. Then assign the privileges in the cluster to that role. Jobs in Cluster The number of job roles that inherit the privilege cluster. 98

107 Chapter 12 Securing Field Name Customizing Security Description A list of job names and descriptions is also included. Privileges in Cluster The number of privileges that make up the cluster. A list of privilege names and descriptions is also included. Using the Role Optimization Report Privilege Clusters After you select the duty role to map to each privilege cluster, use the Manage Duties task and assign the privileges to the role. Job Roles Adding, removing, and replacing roles might be suggested as part of the role optimization report. You use the Manage Job Roles task to update job role hierarchies. 99

108 Securing Chapter 12 Customizing Security 100

109 Chapter 13 Securing 13 Synchronizing with Oracle Identity Management Synchronizing with Oracle Identity Management Synchronization of User and Role Information with Oracle Identity Management Oracle Identity Management (OIM) maintains Lightweight Directory Access Protocol (LDAP) user accounts for users of Oracle Cloud applications. OIM also stores the definitions of abstract roles and job roles, and holds information about roles provisioned to users. Most changes to user and role information are shared automatically by Oracle Sales and OIM. No action is necessary to make this exchange of information happen. However, you must run the processes Send Pending LDAP Requests and Retrieve Latest LDAP Changes to manage some types of information exchange between your application and OIM. The table summarizes the role of each process. Process Description Send Pending LDAP Requests Sends bulk requests and future-dated requests that are now active to OIM. The response to each request from OIM to your application indicates transaction status (for example, Completed). Retrieve Latest LDAP Changes Requests updates from OIM that might not have arrived automatically because, for example, there was a failure or error. This figure summarizes the information flow of the daily processes. 101

110 Chapter 13 Securing Synchronizing with Oracle Identity Management Scheduling the Processes You must run both processes at least daily to identify and process future-dated changes as soon as they take effect. Retrieve Latest LDAP Changes must complete before Send Pending LDAP Requests runs. For this reason, leave a gap between the scheduled start times of the processes. Depending on the size of your enterprise and the number of updates, a gap of 1 or 2 hours may be enough. Send Pending LDAP Requests has two required parameters, User Type and Batch Size. You're recommended to use the default values of these parameters. Parameter Description Default Value User Type The types of users to be processed. Values are Person, Party, and All All Batch Size The number of requests in a single batch. For example, if 400 requests exist and you set batch size to 25, then the process creates 16 batches of requests to process in parallel. The value A means that the batch size is calculated automatically. A Scheduling the LDAP Daily Processes You're recommended to schedule these processes to run daily: Process Description Send Pending LDAP Requests Sends bulk requests and future-dated requests that are now active to Oracle Identity Management. Retrieve Latest LDAP Changes Requests updates from Oracle Identity Management that may not have arrived automatically because of a failure or error, for example. Important Schedule the processes only when your implementation is complete. Once you schedule the processes, you can't run them on an as-needed basis, which is necessary during implementation. This procedure explains how to schedule the processes. 102

111 Securing Chapter 13 Synchronizing with Oracle Identity Management Scheduling the Retrieve Latest LDAP Changes Process 1. Select Navigator - Tools - Scheduled Processes to open the Scheduled Processes work area. 2. Click Schedule New Process in the Search Results section of the Scheduled Processes work area. 3. Search for and select the process Retrieve Latest LDAP Changes in the Schedule New Process dialog box. 4. In the Process Details dialog box, click Advanced. 5. On the Schedule tab, select Using a schedule. 6. In the Frequency field, select Daily. 7. Enter the start and end dates and times. Plan for Retrieve Latest LDAP Changes to complete before Send Pending LDAP Requests starts. 8. Click Submit. Scheduling the Send Pending LDAP Requests Process 1. Click Schedule New Process in the Search Results section of the Scheduled Processes work area. 2. Search for and select the process Send Pending LDAP Requests in the Schedule New Process dialog box. 3. In the Process Details dialog box, select a user type value and enter a batch size. You're recommended to leave User Type set to All and Batch Size set to A. Click Advanced 4. On the Schedule tab, select Using a schedule. 5. In the Frequency field, select Daily. 6. Enter the start and end dates and times. Leave a gap between the start times of the two processes so that Retrieve Latest LDAP Changes completes before Send Pending LDAP Requests starts. 7. Click Submit. About Sending Pending LDAP Requests It is recommended that you run the Send Pending LDAP Requests process daily to send future-dated and bulk requests to Oracle Identity Management (OIM). Schedule the process in the Scheduled Processes work area. 103

112 Securing Chapter 13 Synchronizing with Oracle Identity Management Send Pending LDAP Requests sends the following items to OIM: Requests to create, suspend, and reenable user accounts. When you create a person record for a worker, a user-account request is generated automatically. When a person has no roles and no current work relationships, a request to suspend the user account is generated automatically. A request to reenable a suspended user account is generated automatically if you rehire a terminated worker. The process sends these requests to OIM unless the automatic creation and management of user accounts is disabled for the enterprise. Work s. If you include work s when you create person records, then the process sends those s to OIM, which owns them. They're usable only when OIM returns them to Oracle Sales. Role provisioning and deprovisioning requests. The process sends these requests to OIM unless automatic role provisioning is disabled for the enterprise. Changes to person attributes for individual users. The process sends this information to OIM unless the automatic management of user accounts is disabled for the enterprise. Note All of these items are sent to OIM automatically unless they're either future-dated or generated by bulk data upload. You run the process Send Pending LDAP Requests to send future-dated and bulk requests to OIM. About Retrieving Latest LDAP Changes Retrieve Latest LDAP Changes delivers information to your Cloud application from the Oracle Identity Management (OIM) Lightweight Directory Access Protocol (LDAP) directory. Most information arrives automatically. Retrieve Latest LDAP Changes corrects any delivery failures. You're recommended to run Retrieve Latest LDAP Changes daily. Schedule the process in the Scheduled Processes work area. Retrieve Latest LDAP Changes delivers the following information to your application from OIM: Names of user accounts. The globally unique identifier (GUID) from the LDAP directory user account is added automatically to the person record. Latest information about abstract and job roles. OIM stores the latest information about all abstract and job roles. Your application keeps a local copy of all role names and types so that lists of roles in user interfaces are up-to-date. 104

113 Securing Chapter 13 Synchronizing with Oracle Identity Management Work s. A worker can have only one work , which OIM owns. Once the exists, you manage it in OIM. Retrieve Latest LDAP Changes sends any changes to your application. 105

114 Securing Chapter 13 Synchronizing with Oracle Identity Management 106

115 Securing 14 Chapter 14 Security and Reporting Security and Reporting Security for Sales Cloud Analytics and Reports Analytics are available throughout as embedded analytics and also in standalone mode by way of the transactional work areas. users interact with information in Oracle BI Applications and Oracle Transactional Business Intelligence using Oracle Business Intelligence Enterprise Edition (Oracle BI EE) components, such as Dashboards. The analytics and reports that are delivered with are secured based on the roles that use each report. For example, sales managers can access sales analytics and reports that salespeople don't have access to. If you want to create new analytics or reports or edit existing ones, you should become familiar with Sales Cloud security concepts and how access is secured to Oracle Transactional Business Intelligence subject areas, Oracle BI Presentation Catalog folders, and Oracle Business Intelligence reports. Subject Areas Subject areas are functionally secured using duty roles. The supplied user roles include the necessary duty roles to access the Oracle Business Intelligence content. The names of duty roles that grant access to subject areas include the words Transaction Analysis Duty (for example, Sales Managerial Transaction Analysis Duty). Access to a subject area is needed to run or create reports for that subject area. Note The BI Author Role is required to create new OTBI reports. By default, the Sales Representative job role is not assigned the BI Author role. BI Presentation Catalog Folders BI Presentation Catalog folders are functionally secured using the same duty roles that secure access to the subject areas. Therefore, a user who inherits the Sales Managerial Transaction Analysis Duty can access both the Sales Manager folder in the BI Presentation Catalog and the Sales Manager subject areas. Oracle Business Intelligence Reports Analyses are secured based on the folders in which they're stored. If you haven't secured BI reports using the report permissions, then they're secured at the folder level by default. You can set permissions against folders and reports for application roles, catalog groups, or users. For More Information When you receive your implementation, access to its functionality and data is secured using role-based access control (RBAC). For more information about securing subject areas, BI catalog folders and reports, see the following guides: Security Reference 107

116 Chapter 14 Securing Security and Reporting Available from the Oracle Cloud Documentation library, this guide describe the applications security reference implementation and includes descriptions of all the predefined data that is included in the security reference implementation for an offering. The security reference implementation can be customized to fit divergent enterprise requirements. Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition. This guide provides information about using Transactional Analysis Duty roles to secure access to the BI catalog. Delivered Roles for Sales Cloud Analytics and Reports Oracle Transactional Business Intelligence secures reporting objects and data through a set of delivered OTBI Transaction Analysis Duty roles. These OTBI Transaction Analysis Duty roles control which subject areas and analyses that a user can access and what data a user can see in. Your administrator can select users, application roles, and catalog groups to: Receive the delivery content of an agent. Have permission to access a section or alert section in a dashboard. Have permission to use a saved customization. Add or edit for an existing catalog group. Assign permissions to a catalog object. For information about setting the necessary security, see Oracle Middleware Security Guide for Oracle Business Intelligence Enterprise Edition. The following is a list of some OTBI Transactional Analysis Duty roles for Sales: Partner Channel Transaction Analysis Duty Partner Channel Administrative Transaction Analysis Duty Sales Administrative Transaction Analysis Duty Sales Executive Transaction Analysis Duty Sales Managerial Transaction Analysis Duty Sales Transaction Analysis Duty The following table lists analytics and reports available in. It also shows the predefined job roles that can access the different analytics and reports, and the OTBI Transactional Analysis Duty roles that provide the access. Analytic or Report Name Job Role OTBI Transactional Analysis Duty Role Forecast vs. Quota Sales VP Sales Executive Transaction Analysis Duty Sales Stage by Age Sales Performance Trend 108

117 Chapter 14 Securing Analytic or Report Name Security and Reporting Job Role OTBI Transactional Analysis Duty Role Sales Manager Sales Managerial Transaction Analysis Duty Sales Representative Sales Transaction Analysis Duty Top Open Opportunities Forecast Vs Open Pipeline: My Team My Team's Activities (By Type) My Team's Leads My Team's Performance My Team's Pipeline My Team's Tasks on Open Opportunities My Team's Top Open Opportunities Team Leadership Board Top Accounts by My Team's Activities My Open Leads by Age My Top Open Opportunities My Forecast vs. Open Pipeline My Open Leads by Source My Open Tasks My Performance My Pipeline My Stalled Opportunities My Top Accounts by Open Opportunities My Unaccepted Leads by Age My Won Opportunities 109

118 Chapter 14 Securing Analytic or Report Name Security and Reporting Job Role OTBI Transactional Analysis Duty Role Channel Account Manager Partner Channel Transaction Analysis Duty Top Accounts by My Activities Evaluating My Partners' Pipeline Evaluating My Partners' Quarterly and Yearly Closed Revenue Evaluating My Partners' Current Quarterly Sales Evaluating My Partners' Win Rate Note The predefined Transaction Analysis Duty roles provide permissions to view but not create analyses and reports. Permissions to create reports are assigned at the job role level using Business Intelligence roles. Business Intelligence Roles Business Intelligence roles apply to both Oracle Business Intelligence Publisher (Oracle BI Publisher) and Oracle Transactional Business Intelligence (OTBI). They grant access to Business Intelligence functionality, such as the ability to run or author reports. Users need one or more of these roles in addition to the roles that grant access to reports, subject areas, Business Intelligence catalog folders, and Oracle Sales cloud data. This topic describes the Business Intelligence roles. Business Intelligence roles are defined as application roles in Oracle Entitlements Server. This table identifies those roles. Business Intelligence Role Description BI Consumer Role Runs Business Intelligence reports. BI Author Role Creates and edits reports. BI Administrator Role Performs administrative tasks such as creating and editing dashboards and modifying security permissions for reports, folders, and so on. BI Publisher Data Model Developer Role Creates and edits Oracle Business Intelligence Publisher data models. 110

119 Securing Chapter 14 Security and Reporting BI Consumer Role The predefined OTBI Transaction Analysis Duty roles inherit the BI Consumer Role. You can configure custom roles to inherit BI Consumer Role so that they can run reports but not author them. BI Author Role BI Author Role inherits BI Consumer Role. Users with BI Author Role can create, edit, and run OTBI reports. All predefined Sales job roles that inherit an OTBI Transaction Analysis Duty role are also assigned the BI Author Role at the job role level, except for the Sales Representative job role which is not assigned the BI Author role. BI Administrator Role BI Administrator Role is a superuser role. It inherits BI Author Role, which inherits BI Consumer Role. The predefined Sales Cloud job roles do not have BI Administrator Role access. BI Publisher Data Model Developer Role BI Publisher Data Model Developer Role is inherited by the Application Developer role, which is inherited by the Application Implementation Consultant role. Therefore, users with either of these predefined job roles can manage BI Publisher data models. Customizing Security for Oracle Transactional Business Intelligence Oracle Transactional Business Intelligence (OTBI) secures reporting objects and data through a set of delivered OTBI Transaction Analysis Duty roles. You cannot customize the OTBI duty roles provided with, or the associated security privileges. However, you can customize OTBI reporting security according to your security requirements as follows: Create a custom job role and assign the required OTBI Transaction Analysis Duty roles to it. Modify Business Intelligence role assignments. Creating a Custom Job Role with OTBI Access If you want to customize the OTBI subject areas that users have access to, create a custom job role, then provide the role with access to OTBI reports by assigning OTBI Transaction Analysis Duty roles. The following are the high-levels steps in creating a custom job role and assigning it access to OTBI reports. 1. Sign in to with the IT Security Manager job role. 2. Create a custom job role in Oracle Identity Manager (OIM) using the Manage Job Roles task. 3. Save the new custom role, then configure the role to inherit the Transactional Business Intelligence Worker BI abstract role. The Transactional Business Intelligence Worker role inherits the Transactional Analysis Duty which is required to run reports and execute queries. 111

120 Securing Chapter 14 Security and Reporting 4. Assign duty roles to the new custom job role in Authorization Policy Manager using the Manage Duties task. 5. Assign the appropriate OTBI Transaction Analysis Duty role to the custom job role. Transaction Analysis Duty roles are located in the obi application in Authorization Policy Manager. For example, if you want your custom job role to have access to the subject areas that are secured by the Sales Transaction Analysis Duty role, search for this duty role in the obi application, then assign it to the custom job role. 6. Run the Retrieve Latest LDAP Changes process. This process makes your custom role available in Oracle Sales Cloud. Note Most changes you make to security settings in Authorization Policy Manager take immediate effect and can be viewed after you return to the Authorization Management Home page. Changes to the role hierarchy can, however, take up to 20 minutes to take effect. Modifying Business Intelligence Role Assignments The Business Intelligence roles enable users to perform tasks within Business Intelligence tools such as Oracle Business Intelligence Publisher. The default Business Intelligence roles used in are BI Consumer and BI Author. The delivered OTBI Transaction Analysis Duty roles inherit the BI Consumer role, which provides view-only access to analyses and reports. You assign the BI Author role at the job role level, giving you flexibility in granting the BI Author privilege to only those job roles that you want to have access to create and edit analyses and reports. All predefined Sales Cloud job roles that inherit an OTBI Transaction Analysis Duty role are also assigned the BI Author Role by default, except for the Sales Representative job role. However, you can optionally remove or add the BI Author role from a job role if required. Viewing Reporting Roles Viewing reporting roles can help you to understand Oracle Transactional Business Intelligence (OTBI) security. This topic explains how to view the following: 1. OTBI roles that a job role inherits 2. All of the duty roles you are assigned Note A user must be assigned the Transactional Analysis Duty role to run queries and reports. You can verify that a user, or the job role assigned to a user, has the Transactional Analysis Duty by performing the procedures in this topic. The Transactional Analysis Duty role is inherited by the Transactional Business Intelligence Worker abstract role. Viewing OTBI Duty Roles Assigned to a Job Role To view all the duty roles assigned to a job role, perform the steps in the following procedure. 1. Sign in with the IT Security Manager job role. 112

121 Securing Chapter 14 Security and Reporting 2. Select Navigator - Tools - Setup and Maintenance to open the Setup and Maintenance work area. 3. On the All Tasks tab of the Overview page, search for and select the Manage Duties task. The Oracle Entitlements Server Authorization Management page opens. On the Home tab: a. In the Application Name section, select crm. b. In the Search and Create section, click Search - External Roles. The Search - External Roles page opens. 4. In the Display Name field, enter the name of the job role. For example, enter Sales Manager, then click Search. 5. In the search results, select Sales Manager, then click Open Role. The Sales Manager page opens. 6. Select the Application Role Mapping tab. 7. Expand the obi folder. Notice the Transaction Analysis Duty roles that the Sales Manager job role inherits. Note also that the Sales Manager job role inherits BI Author Role. 8. Expand the Sales Managerial Transaction Analysis Duty role. It inherits BI Consumer Role. 9. Close the Authorization Management page and sign out. Viewing the Duty Roles You Are Assigned To view all of the duty roles that you are assigned, including Business Intelligence roles and Transactional Analysis Duty roles, perform the following steps. 1. Sign in to using your user ID and password. 2. Select Navigator - Tools - Reports and Analytics to open the Reports and Analytics work area. 3. In the Contents pane, click the Browse Catalog icon. The Business Intelligence Catalog page opens. 4. Click your user name in the global header, then select My Account. 5. Click the Roles and Catalog Groups tab. All the duty roles you are assigned are listed, including Transaction Analysis Duty roles and Business Intelligence roles. 6. Click OK. 7. Return to the Oracle Fusion Applications window and sign out. 113

122 Securing Chapter 14 Security and Reporting How can I customize Oracle Transactional Business Intelligence duty roles? If you are using, you can't customize the delivered OTBI duty roles or the associated security privileges. You can customize Oracle Transactional Business Intelligence reporting security by assigning different OTBI duty roles to a job role according to your needs. 114

123 Securing 15 Chapter 15 Implementing Federated Single Sign-On Implementing Federated Single Sign-On Overview This chapter describes how to implement federated Single Sign-On (SSO) for your application. Single Sign-On is an authentication mechanism that enables users to sign-in once but access multiple applications. Federated Single Sign-On provides users with SSO access to both their on-premise systems and using existing authentication methods and credentials. The topics in this chapter describe how to implement federated SSO using an existing on-premise LDAP repository. Information on implementing federated SSO for your applications is also available from (Doc ID) on My Oracle Support. About Federated Single Sign-On You can integrate with your existing identity management solutions to provide users with a Single Sign-On experience. Oracle Cloud provides this experience using a standards-based identity federation solution. Federated Single Sign-On authentication is available on all platforms used to access the Sales Cloud application, including Oracle Mobile platforms, and it is also available for Web services. With identity federation, delegates authentication responsibility to your identity management system (the Identity Provider). Your Identity Provider asserts a user's identity to after it has properly established the identity of the user. then validates the trust relationship with the Identity Provider and upon successful verification, grants the user access to Sales Cloud. The following figure illustrates how federated Single Sign-On works in Oracle Cloud Applications when you use Oracle Identity Federation Server as your identity management solution. 115

124 Securing Chapter 15 Implementing Federated Single Sign-On Here's how identity federation works in : 1. The browser user requests resources at the service provider site. Oracle identity federation (OIF) checks whether a security context for that user exists. If it does, OIF allows the user to access the target resources directly; otherwise, OIF discovers who the identity provider is. 2. OIF redirects the user to a login page hosted by the identity provider. 3. The user provides log-in credentials and issues a POST request to the identity provider. OIF at the identity provider site processes the request and performs an identity check on the user. If the user already has a valid identity context, OIF validates the user. 4. At the identity provider site, OIF validates the request, generates a signed SAML assertion, and responds with an HTML form including the SAML assertion. 5. The browser is redirected to resources again with SAML information received from the ID provider. 6. At the service provider site, OIF validates the SAML assertion's signature and parses the SAML assertion for authentication. OIF then creates a security context, which enables repeated log-ins and SSO without additional user challenges. OIF finally redirects the user to the target resources. If the user requests OIFprotected resources again later, the user is redirected to the target resources without having to go through Steps 2 to 5. Supported Identity Providers There are several identity management solutions and packages that can be used with federated Single Sign-On. The following solutions are certified for use with Oracle Cloud applications: Microsoft Active Directory Federation Server Oracle Identity Federation Server 11g Shibboleth If you use a different identity provider, contact Oracle to determine whether or not your provider is supported. Implementing Federated Single Sign-On This topic outlines the steps to follow to request and implement Single Sign-On (SSO) enablement in your Oracle Cloud instances. To implement federated Single Sign-On: 1. Verify that any requirements for SSO outlined below have been met. 2. Request Single Sign-On enablement by submitting a service request on My Oracle Support. Once your request is approved, Oracle Cloud operations personnel will provide you with the information necessary to set up your local identity provider for federated SSO. For information, see (Article ID) on My Oracle Support. 3. Perform the initial upload of employee resource data from your local identity provider to. For information on this task, see the topic Uploading User Data from an LDAP Directory into. 116

125 Securing Chapter 15 Implementing Federated Single Sign-On 4. To check that you have configured federated SSO correctly, verify that your users can access and on-premises applications using SSO. 5. Configure ongoing synchronization of user data between the on-premises identity provider and. You can synchronize employee resource data in the following scenarios: Synchronizing employee resource data when users are first provisioned in the environment. For information on this task, see the topic Synchronizing User Data when Users are Provisioned in Sales Cloud. Synchronizing employee resource data when users are provisioned first in your on-premises environment. For information on this task, see the topic Uploading User Data from an LDAP Directory into. Requirements for Single Sign-On Oracle Cloud implements Oracle Fusion Security Assertion Markup Language (SAML) Service Provider integrated with the Fusion SSO Server as the Service Provider (SP). To implement Single Sign-On, you must configure or deploy one of the following as an identity provider (IdP) in your environment: Microsoft Active Directory Federation Server (ADFS) 3.0 Oracle Identity Federation Server 11g Uploading User Data from an LDAP Directory into Federated Single Sign-On requires that user identities are synchronized between your on-premises identity store and the identity store used by. The user must exist in both domains, and must be linked using an identity attribute that uniquely identifies the user. This topic describes how to upload employee data from your on-premises environment to. You perform the procedures described in this topic: To initially load user data from your on-premises directory to during the setup of federated Single Sign-On (SSO). To perform on-going synchronization of user data between the on-premises directory and if users are first provisioned in your on-premises environment. The steps involved in uploading user data into are as follows: 1. Extract user data from your local LDAP directory service, either Oracle Internet Directory or Active Directory, to a local file. For details, see Extracting User Data from the Local Directory. 2. Convert the data in the file into a format that is delivered and supported by, for example, CSV format. 3. Load the employee resource data into using one of the supported data loading methods. For details, see Loading Employee Data into. 117

126 Securing Chapter 15 Implementing Federated Single Sign-On Extracting User Data from the Local Directory Extract user data from your local LDAP directory service to a file using the tools provided by your LDAP directory service vendor, either Oracle Internet Directory, or Microsoft Active Directory. Exporting Data from Oracle Internet Directory Oracle Internet Directory provides ldifwrite and bulkload command-line tools to export identity information from an LDIF file. To use the ldifwrite command to export user data: Use a command similar to the following to export users from Oracle Internet Directory to a file named output.ldif. ldifwrite connect="connect_str" basedn="ou=europe, o=imc, c=us filter="uid=abc" ldiffile="output.ldif" Make sure that you meet the LDAP search filter criteria "ou=europe, o=imc, c=us". For more information about Oracle Internet Directory, go to Exporting Data from Active Directory Active Directory provides the CSVDE and LDIFDE utilities to export identity information into Microsoft CSV file format and LDIF file formats, respectively. To export user data: Use the CSVDE command to export users from Active Directory. Filter out the administration or the machine accounts in the command. For example: csvde -s test.oracle.com -t 389 -f test.csv -r "(&(ObjectClass=user)(!cn=Administrator)(!cn=Guest)(!cn=user)(!cn=krbtg t)(!cn=user))" -d "CN=Users,DC=adfs,DC=fed,DC=oracle,DC=com" -l "cn,displayname,distinguishedname,givenname,mail,name,samaccountname,sn,userprincipalname" The following is the example output written to the file. DN,cn,distinguishedName,name,sAMAccountName,displayName,sn,givenName,us erprincipalname,mail "CN=remoteimage,CN=Users,DC=adfs,DC=fed,DC=oracle,DC=com",remoteimage," CN=remoteimage,CN=Users,DC=adfs,DC=fed,DC=oracle,DC=com",remoteimage,re moteimage,,,,, "CN=pgoginen,CN=Users,DC=adfs,DC=fed,DC=oracle,DC=com",pgoginen,"CN=pgo ginen,cn=users,dc=adfs,dc=fed,dc=oracle,dc=com",pgoginen,pgoginen,,,,, "CN=windows,CN=Users,DC=adfs,DC=fed,DC=oracle,DC=com",windows,"CN=windo ws,cn=users,dc=adfs,dc=fed,dc=oracle,dc=com",windows,windows,windows,,,, "CN=Alice Appleton,CN=Users,DC=adfs,DC=fed,DC=oracle,DC=com",AliceAppleton,"CN=Al ice Appleton,CN=Users,DC=adfs,DC=fed,DC=oracle,DC=com",Alice Appleton,alice,Alice Appleton,Appleton,Alice,[email protected],[email protected] For more information about Active Directory, see the Microsoft Windows Server documentation at technet.microsoft.com/en-us/library/bb aspx. Loading Employee Data into Load the employee resource data you exported from the local LDAP directory into using one of the following supported data loading methods: Manually create individual new resources on the Manage Users UI. 118

127 Securing Chapter 15 Implementing Federated Single Sign-On Import resource data using the employee resource import template. For detailed information on importing resources refer to: Importing Resources section of the File-Based Data Import Guide (Doc ID ). Importing Users chapter of the Getting Started with Your Implementation guide on docs.oracle.com. In, resources are employees or contingent workers (including contractors) who use the system on a continuing basis to perform setup and maintenance tasks, or business functions, or both. When you import user information from your LDAP directory into, you must identify users as resources and assign them resource roles and resource organizations in addition to providing their employee or contractor information. supports the following employee resource attributes for mapping users between your on-premises system and : Employee resource user name or user identity (UID or samaccountname) Employee resource address Synchronizing User Data when Users are First Provisioned in Sales Cloud After implementing federated Single Sign-On, you must perform ongoing synchronization of user data between the onpremises environment and. When users are first provisioned in, this creates new users in. You must extract this user data and import it into your on-premises LDAP user directory. To update your local LDAP user directory with new user data from, perform the steps in the following procedure. 1. Export resource data from Sales using the Setup and Maintenance, Schedule Export Processes task. For details see, Exporting Resource Data from. 2. Transform the resource data in the extract files into a format which will allow the data to be imported into your local LDAP directory. For details, see Transform the Extracted Resource and Person CSV Files. 3. Load the user data in the extract file into your local LDAP directory using one of the following procedures: Importing User Information Using the Oracle Internet Directory Importing User Information Using Microsoft Active Directory Exporting Resource Data from Perform the steps in the following procedure to extract user data from. 1. Log in to and navigate to the Setup and Maintenance page. 2. On the All Tasks tab of the Overview page, search for and select the Schedule Export Processes task. 119

128 Securing Chapter 15 Implementing Federated Single Sign-On 3. On the Overview page, select Create from the Actions menu to view the Create Export Process Definition: Enter Basic Information page. 4. In the Name field, enter a name for the scheduled export process definition. You can enter other basic details as appropriate. 5. Click Next and the Create Export Process Definition: Configure Export Objects page is displayed. Use this page to select and configure the objects that contain the data that you want to export. 6. Select Create from the Actions menu in the Export Objects section of the page. This displays the Manage Export Objects dialog box. 7. Move the objects you want to export from the list of Available Objects on the left side of the screen to the Selected Objects list on the right. In this instance, you need to export data associated with the Resource, Person, and Party objects. The Person and Party objects contain details associated with users, while the Resource object contains details associated with the same users' resource profiles. 8. Click Done to confirm your selection. The Configure Export Objects page now displays the objects you selected. 9. In the Export Objects area, select each object in turn, then navigate to the Details area, expand the object attribute, then define the following: Attributes you want to export. All attributes are selected for export by default. Deselect the checkbox in the Enabled column for an attribute if you don't want to export data associated with the attribute. Header text of the attributes. Edit the header text in the Header text column. This value is used as the column header in the files generated by the export process. You can optionally specify filters to determine the data you want to export by clicking on the Edit Filter Criteria button. 10. When you have defined the attributes for each object that you want to export, click Next. 11. The Create Export Process Definition: Create Schedule page is displayed allowing you to schedule the export process. You can schedule the export process to run immediately or at a scheduled time. 12. In this instance, select the Immediate radio button, then click Next. 13. On the Create Export Process Definition: Review screen, review your scheduled export specifications, and then click Activate to trigger the scheduled export. 14. The Overview page is displayed, where you can access the exported files once they are available. The following files are created: ResourceExpPVO.csv PersonExpPVO.csv PartyExpPVO.csv 120

129 Securing Chapter 15 Implementing Federated Single Sign-On Transform the Extracted Resource, Party and Person CSV Files After you have extracted new user data from into.csv files, you must edit the files as described in the following procedure so that you can import the files into your on-premises LDAP directory. 1. Download the ResourceExpPVO.csv file, the PersonExpPVO.csv file, and the PartyExpPVO.csv file created as a result of the data export process. 2. Open the ResourceExpPVO.csv file and navigate to the PartyId column to locate the PartyId values for all users. 3. Use the PartyId values in ResourceExpPVO.csv to identify the corresponding PartyId and user information in the PersonExpPVO.csv file and the PartyExpPVO.csv files. 4. Create a.csv file that contains all the user PartyIds, and their associated first name and last name (from PersonExpPVO.csv) and their associated addresses (from PartyExpPVO.csv). Importing Sales Cloud User Data into a Local Directory To import new user data from into your local directory, convert the user data extract file into a format that can be loaded into your local LDAP directory using tools provided by your LDAP vendor. The following procedures describe how to load user data into Oracle Internet Directory and Active Directory directories. Importing User Information Using the Oracle Internet Directory If you're using Oracle Internet Directory as your local LDAP directory, then you must convert the data in the exported.csv file into the LDIF format. In addition, the ordering of the attributes must match the user object class in Oracle Internet Directory. Import user data into Oracle Internet Directory using a command similar to the following: bulkload connect=connect_string check="true" generate="true" file=full_ path_to_ldif-file_name For more information about Oracle Internet Directory, see Oracle Internet Directory Administrator's Guide located at: docs.oracle.com/cd/e21764_01/oid.1111/e10029/toc.htm. For more information about bulkload, see the following document: bulktools.htm#beiifdag. Importing User Information Using Microsoft Active Directory If you're using Microsoft Active Directory as your local LDAP directory, then you must convert the data in the exported.csv file into either.csv or LDIF format. In addition, the ordering of the attribute must match the user object class in Active Directory. You can use the CSVDE or LDIFDE utilities provided by Active Directory to import user data into Active Directory. Note You must ensure that the uid attribute of users mastered in does not exceed 64 characters to ensure that the information is not lost during synchronization. If this requirement is not met, identity synchronization results in the username (samaccountname) being truncated in Active Directory. As a result, federated Single Sign-On will fail due to a mismatch between the local Active Directory samaccountname and the User Identity. Import user data into Active Directory using a command similar to the following: csvde -s server_name -t portnumber -i -f file_name.csv where: -i specifies import mode. If not indicated, the export mode, which is the default mode, is used. 121

130 Securing Chapter 15 Implementing Federated Single Sign-On portnumber is the port number. Port 389 is the default LDAP port. For the global catalog port, enter 3268 as the port number. For more information, see the Microsoft Windows Server documentation at bb aspx. 122

131 Securing 16 Chapter 16 Advanced Data Security Advanced Data Security Advanced Data Security Advanced Data Security offers two types of extended data protections. Database Vault protects data from access by highly privileged users and Transparent Data Encryption encrypts data at rest. Advanced Data Security is available for Oracle Applications Cloud by subscription. Oracle Database Vault Database Vault reduces the risk of highly privileged users such as database and system administrators accessing and viewing your application data. This feature restricts access to specific database objects, such as the application tables and SOA objects. Administrators can perform regular database maintenance activities, but cannot select from the application tables. If a DBA requires access to the application tables, she can request temporary access to the Fusion schema at which point keystroke auditing is enabled. Transparent Data Encryption Transparent Data Encryption (TDE) protects Fusion Applications data which is at rest on the file system from being read or used. Data in the database files (DBF) is protected because DBF files are encrypted. Data in backups and in temporary files is protected. All data from an encrypted tablespace is automatically encrypted when written to the undo tablespace, to the redo logs, and to any temporary tablespace. Advanced security enables encryption at the tablespace level on all tablespaces which contain applications data. This includes SOA tablespaces which might contain dehydrated payloads with applications data. Encryption keys are stored in the Oracle Wallet. The Oracle Wallet is an encrypted container outside the database that stores authentication and signing credentials, including passwords, the TDE master key, PKI private keys, certificates, and trusted certificates needed by secure sockets layer (SSL). Tablespace keys are stored in the header of the tablespace and in the header of each operating system (OS) file that makes up the tablespace. These keys are encrypted with the master key which is stored in the Oracle Wallet. Tablespace keys are AES128-bit encryption while the TDE master key is always an AES256-bit encryption. 123

132 Securing Chapter 16 Advanced Data Security 124

133 Securing Glossary Glossary abstract role A description of a person's function in the enterprise that is unrelated to the person's job (position), such as employee, contingent worker, or line manager. A type of enterprise role. action The kind of access, such as view or edit, named in a security policy. assignment A set of information, including job, position, pay, compensation, managers, working hours, and work location, that defines a worker's or nonworker's role in a legal employer. data security The control of access and action a user can take against which data. duty role A group of function and data privileges representing one duty of a job. Duty roles are specific to applications, stored in the policy store, and shared within an application instance. effective start date For a date-effective object, the start date of a physical record in the object's history. A physical record is available to transactions between its effective start and end dates. enterprise An organization with one or more legal entities under common control. entitlement Grant of access to functions and data. Oracle Fusion Middleware term for privilege. function security The control of access to a page or a specific use of a page. Function security controls what a user can do. job A generic role that is independent of any single department or location. For example, the jobs Manager and Consultant can occur in many departments. job role A role, such as an accounts payable manager or application implementation consultant, that usually identifies and aggregates the duties or responsibilities that make up the job. 125

134 Securing Glossary person type A subcategory of a system person type, which the enterprise can define. Person type is specified for a person at the employment-terms or assignment level. privilege cluster In the output of the Role Optimization Report, a group of privileges that you can map to a duty role. resource role Resource roles indicate the role a resource plays as an individual, or within a resource team. role Controls access to application functions and data. role deprovisioning The automatic or manual removal of a role from a user. role hierarchy Structure of roles to reflect an organization's lines of authority and responsibility. In a role hierarchy, a parent role inherits all the entitlement of one or more child roles. role mapping A relationship between one or more roles and one or more assignment conditions. Users with at least one assignment that matches the conditions qualify for the associated roles. role provisioning The automatic or manual allocation of a role to a user. security reference implementation Predefined function and data security that includes role based access control, and policies that protect functions, and data. The reference implementation supports identity management, access provisioning, and security enforcement across the tools, data transformations, access methods, and the information life cycle of an enterprise. setup user A user provisioned with the job roles and abstract roles required to perform the required implementation tasks. work relationship An association between a person and a legal employer, where the worker type determines whether the relationship is a nonworker, contingent worker, or employee work relationship. 126