3Authorization with Role-Based Access Control

This chapter contains the following:

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. You implement the role-based access controls provided by Oracle so that users have appropriate access to sales data and functions.

In a role-based access control model, users are assigned roles, and roles are assigned access privileges to protected resources. This diagram shows the relationship between users, roles, and privileges.

Components in role-based access control models

In the sales application, users gain access to application data and functions when you assign them these types of roles:

  • Job roles, which provide users with the permissions they need to perform tasks that are specific to a job, such as a sales representative

  • Abstract roles, which provide users with the permissions to complete tasks that are common to all users

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 this 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 signs in to the application and is successfully authenticated, a user session is established and all the roles assigned to the user are loaded into the session repository. The application determines the set of privileges to application 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.

Predefined Sales and Service Roles

Oracle provides many predefined job and abstract roles as part of the security reference implementation for the sales and service applications. The security reference implementation is a predefined set of security definitions that you can use as-is.

Sales Roles

The following are the main predefined job roles for sales users:

  • Channel Account Manager

  • Channel Operations Manager

  • Channel Sales Manager

  • Customer Contract Administrator

  • Customer Data Steward

  • Customer Relationship Management Application Administrator

  • Data Steward Manager

  • Enterprise Contract Administrator

  • Enterprise Contract Manager

  • Incentive Compensation Manager

  • Incentive Compensation Plan Administrator

  • Incentive Compensation Analyst

  • Marketing Manager

  • Marketing Operations Manager

  • Marketing VP

  • Master Data Management Application Administrator

  • Partner Administrator

  • Partner Sales Manager

  • Partner Sales Representative

  • Sales Administrator

  • Sales Analyst

  • Sales Catalog Administrator

  • Sales Lead Qualifier

  • Sales Manager

  • Sales Representative

  • Sales VP

  • Supplier Contract Administrator

You also assign the following abstract roles to sales users who are employees so they can carry out their work:

  • Employee

  • Resource

If you're using the incentive compensation functionality, you can also assign the following abstract roles to users:

  • Incentive Compensation Participant

  • Incentive Compensation Participant Manager

Service Roles

A number of job roles and duty roles are predefined in the Service offering. These are the predefined job roles specific to this product area:

  • Customer Service Manager

  • Customer Service Representative

  • Knowledge Analyst

  • Knowledge Manager

  • Field Service Technician

  • Internal Help Desk Administrator

  • Internal Help Desk Agent

  • Internal Help Desk Manager

  • Case Manager

  • Case Worker

Roles for Workflow Administration Access

Predefined roles provide access to workflow administration functionality. Users with the workflow roles can perform tasks such as setting up approval rules and managing submitted approval tasks. This table identifies the predefined Oracle Business Process Management (BPM) role for sales workflow administration access, and the predefined job roles that inherit it. It also shows the BPM role that provides workflow administration access for all product families. You can assign a predefined BPM role to a custom job role, if required.

Product Family Role Name and Code Inherited by Job Role

Sales

BPM Workflow Customer Relationship Management Administrator

BPMWorkflowCRMAdmin

Corporate Marketing Manager (ORA_MKT_CORPORATE_MARKETING_MANAGER_JOB)

Customer Relationship Management Application Administrator (ORA_ZCA_CUSTOMER_RELATIONSHIP_MANAGEMENT_APPLICATION_ADMINISTRATOR_JOB)

Marketing Analyst (ORA_MKT_MARKETING_ANALYST_JOB)

Marketing Manager (ORA_MKT_MARKETING_MANAGER_JOB)

Marketing Operations Manager (ORA_MKT_MARKETING_OPERATIONS_MANAGER_JOB) )

Marketing VP (ORA_MKT_MARKETING_VP_JOB)

Sales Lead Qualifier (ORA_MKL_SALES_LEAD_QUALIFIER_JOB

All

BPM Workflow All Domains Administrator Role

BPMWorkflowAllDomainsAdmin

This role isn't assigned to any predefined job role, but you can add it to custom job roles.

Role Types

The different types of roles provided with your sales application work together to provide users with permissions to application resources. These types of roles are provided:

  • Job roles

  • Abstract roles

  • Duty roles

The permissions each role provides are described in security reference manuals available on http://docs.oracle.com.

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 job roles.

Job roles provide users with the permissions they need to carry out tasks specific to their jobs. For example, providing a user with the Sales Manager job role permits the user to manage salespeople 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.

Abstract Roles

Abstract roles represent a user's functions in the enterprise that are independent of the job they do. These are examples of the abstract roles used in the sales application:

  • Employee

  • Resource

Abstract roles let users to perform tasks that are common to all employees and resources. For example, users who are employees must be provisioned with the Employee abstract role, so they can update their employee profiles and pictures. You must also provision users with the Resource abstract role, so they can be assigned as a sales resource to work on leads, opportunities, and other sales tasks. You can assign abstract roles directly to users. You can also create abstract roles.

Duty Roles

Job and abstract roles permit users to carry out actions because 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.

For example, the Sales Manager job role inherits 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 lets managers work with sales forecasts. Job roles and abstract roles can inherit duty roles either directly or indirectly.

You can create duty roles and can include predefined and custom duty roles in custom job and abstract roles. You don't assign duty roles directly to users.

Role Hierarchies and Role Inheritance

Each role is a hierarchy of other roles that are linked to each other in a parent-child relationship. As this hierarchy chart shows, users are assigned job and abstract roles, which inherit duty roles and their associated privileges. Duty roles in turn can inherit privileges from subordinate duty roles. You can explore the complete structure of a job or abstract role on the Security Console.

Role inheritance

Role hierarchies allow privileges to be grouped to represent a feature set, which simplifies feature management. Role hierarchies also provide privilege granularity and facilitate role reuse. For example, each role hierarchy beneath the job role represents a feature that's 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 isn't recommended. Deep role hierarchies are difficult to manage, and modification of the privileges in roles that are heavily reused can cause undesired consequences in other features.

Role Inheritance Example

This example shows how roles and privileges are inherited for a user, Tom Green, assigned the Sales Manager job role. The chart shows a few of the duty roles that Tom inherits.

Duty roles for a sales manager

As an employee sales manager, Tom Green is provisioned with the roles required to do the job: the Sales Manager job role, and the Employee and Resource abstract roles. Roles are inherited as follows:

  • The Sales Manager job role inherits duty roles including the Sales Party Management duty role and the Opportunity Sales Manager duty role.

  • Duty roles inherit other duty roles. For example, the Sales Party Management duty inherits the Sales Party Review duty and the Trading Community Import Batch Management duty, as well as many privileges.

  • The duty roles can be associated with functional security policies and data security policies. For example, the inherited Sales Party Review duty includes security policies that specify which application pages sales managers can access to export assets.

Duty Role Components

If you want to configure the predefined security model by creating your own duty roles, then it's important to understand how duty roles are constructed. A typical duty role consists of two components: data security policies, and function security privileges. Duty roles can also inherit other duty roles.

Function Security Policies

Function security policies permit a user who's 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 can view and click the Delete button. Removing that policy removes the button from view. A function security policy is composed of:

  • 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, Delete Opportunity.

Some user interfaces aren't subject to data security so some function security privileges don't have an equivalent data security policy.

In the security reference manuals, functional privileges are listed in the Privileges section.

Data Security Policies

Data security policies specify the 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 role name. The name of the role the data security policy is granted to. The role can be a duty role, a job role or an abstract role. For example, the Opportunity Sales Manager duty role.

  • The business object that's being accessed, for example, opportunity. The data security policy identifies the object by its table name, for example, MOO_OPTY for opportunity.

  • A data privilege that defines the actions permitted on the data. For example, View Opportunity.

  • The condition that must be met for access to the business object to be granted. For example, sales managers can view opportunities provided they're in the management chain or are members of the sales team for the opportunity.

    If the View All condition is specified, the role provides access to all data of the relevant type.

Data privileges are listed in the Data Security Policies section of the security reference manuals.

Policy Store

The policy store is the repository of all roles for Oracle Cloud Applications. The policy store is also where the security policies defined for each role are stored. The Security Console is a tool for managing the policy store for Oracle Cloud applications.

Guidelines for Configuring Security

If the predefined security reference implementation doesn't fully represent your enterprise, then you can make changes. For example, the predefined Sales Representative job role includes sales forecasting privileges. If sales managers do sales forecasting in your organization, not the sales representatives, then you can create a sales representative role without those privileges.

During implementation, you evaluate the predefined roles and decide whether changes are needed. If changes are required, then you can either create a role from scratch or copy an existing role. You can perform both tasks on the Security Console.

You can identify predefined 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 can create your own 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 can create your own 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 necessary.

Predefined Roles with Missing Privileges

If the privileges for a job aren't defined in the security reference implementation, then you can create your own duty roles.

The typical implementation doesn't use custom duty roles.

Options for Reviewing Predefined Roles

There are a number of 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.

Security Console

On the Security Console, you can:

  • Review the role hierarchy of any job, abstract, or duty role.

  • Extract the role hierarchy to a spreadsheet.

  • Identify the function security privileges and data security policies granted to a role.

  • Compare roles to identify differences.

Tip: The role codes of all predefined roles have the prefix ORA_.

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, all roles, a specified user, or all users.

Security Reference Manuals

The following manuals describe the security reference implementation for Oracle CX Sales and B2B Service 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 for CX Sales and B2B Service includes descriptions of all predefined security data for Oracle CX Sales and B2B Service.

  • The Security Reference for Incentive Compensation includes descriptions of all predefined security data for Incentive Compensation.

These manuals contain a section for each predefined job and abstract role. For each role, you can review:

  • Duty roles

  • Role hierarchy

  • Function security privileges

  • Data security policies

You can access the security reference manuals on https://docs.oracle.com/.

Sales and Service Access Management Work Area

You can review the visibility provided by a job role to object data in the Sales and Service Access Management work area. You can display a read-only view of all the data security policies provided by a selected role for a selected object.

Oracle Cloud Applications Security Console

The Security Console is an easy-to-use administrative work area where you perform most security-management tasks.

Security Console Tasks

You can do these tasks on the Security Console:

  • Review role hierarchies and role analytics.

  • Create and manage custom job, abstract, and duty roles.

  • Review the roles assigned to users.

    Note: You use the Manage Users work area, not the Security Console, to create users and to provision users with roles.
  • Compare roles.

  • Simulate the Navigator for a user or role.

  • Manage the default format of user names and the enterprise password policy.

  • Manage notifications for user-lifecycle events, such as password expiration.

  • Manage PGP and X.509 certificates for data encryption and decryption.

    Note: Oracle CX Sales and B2B Service don't use certificate functionality.
  • Set up federation, and synchronize user and role information between Oracle Applications Security and Microsoft Active Directory, if appropriate.

Security Console Access

You must have the IT Security Manager job role to use the Security Console. You open the Security Console by clicking the Security Console link under the Tools heading in the Navigator. These tasks, performed in the Setup and Maintenance work area, also open the Security Console:

  • Manage Job Roles

  • Manage Duties

  • Manage Data Security Policies