2Authorization with Role-Based Access Control in Oracle Loyalty

This chapter contains the following:

Role-Based Access Control for Oracle Loyalty

When you receive your Oracle CX application, access to its functionality and data is secured using the industry-standard framework for authorization, role-based access control. You must implement the role-based access controls provided by Oracle Loyalty so that users have appropriate access to Oracle Loyalty data and functions.

The following image shows the components in role-based access control models.

In a role-based access control model, users are assigned roles, and roles are assigned access privileges to protected resources. The relationship between users, roles, and privileges is shown in the following figure.

Components in role-based access control models

In Oracle Loyalty, 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.

When the user logs into Oracle Loyalty and is successfully authenticated, a user session is established and all the roles assigned to the user are loaded into the session repository. Oracle Loyalty 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 Roles for Oracle Loyalty

Many job and abstract roles are predefined in Oracle Loyalty. The following are the main predefined Oracle Loyalty job roles:

  • Loyalty Marketing Manager

  • Loyalty Program Administrator

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

  • Employee

  • Resource

These predefined roles are part of the Oracle Loyalty security reference implementation. The security reference implementation is a predefined set of security definitions that you can use as supplied.

Role Types for Oracle Loyalty

This topic describes the roles provided by Oracle Loyalty and explains how they work together to provide users with permissions to application resources. Oracle Loyalty provides the following types of roles:

  • 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. Loyalty Representative and Loyalty Manager are examples of predefined job roles. You can also create company-specific job roles.

Job roles provide users with the permissions they need to perform activities specific to their jobs. For example, providing a user with the Loyalty Manager job role permits the user to create loyalty programs, loyalty promotions, manage loyalty members and their transactions. You can assign jobs directly to users.

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 Loyalty:

  • 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 Oracle Loyalty, you must also provision users with the Resource abstract role, so they can be assigned as a Loyalty resource to work on contacts, accounts, partners, and other Oracle Loyalty tasks. You can assign abstract roles directly to users. You can also create company-specific abstract roles.

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. For example, the Loyalty Manager job role inherits the Partner Account Maintenance Duty, Sales Party Management Duty and Service Request Troubleshooter. These grant loyalty managers access to Partner, Account, Contact and Service Request objects. The Service Request Troubleshooter duty also allows loyalty managers to create, edit, and resolve Oracle Loyalty service requests.

Duty roles can also inherit other duty roles. They're part of the security reference implementation, and are the building blocks of company-specific job and abstract roles. You can also create company-specific duty roles.

You can't assign duty roles directly to users.

About Role Hierarchies and Inheritance for Oracle Loyalty

This topic describes how users inherit roles and privileges and introduces the Oracle Loyalty role hierarchy. In Oracle Loyalty, 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 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.

The following figure shows how users inherit privileges associated with role hierarchies.

Role inheritance in Oracle Loyalty

Role hierarchies allow privileges to be grouped to represent a feature set in Oracle Loyalty, 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.

Security Policies for Oracle Loyalty

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 http://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. A functional policy is made up of the following:

  • A duty role name. The name of the duty where the policy applies.

  • A functional privilege that specifies the application features that are being secured.

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.

  • A data privilege that defines the action being performed.

  • The condition that must be met for access to be granted.

    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 all roles for Oracle CX 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 CX applications.

Security Configuration for Oracle Loyalty: Points to Consider

If the predefined security reference implementation doesn't fully represent your enterprise, then you can make changes.

During implementation, you evaluate the predefined roles and decide whether changes are needed. If changes are required, then you can either create a company-specific role from scratch or copy a predefined role and edit the copy as required. 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_.

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 company-specific job roles. Add duty roles to company-specific 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 company-specific 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 company-specific duty roles.

The typical implementation doesn't use company-specific duty roles.