Setting Up Security

This chapter covers the following topics:

• Overview of Security Topic Organization
• About Service Request and Case Security
• Setting Up Service Request Data Security Process Overview
• About Mapping Responsibilities
• Creating a Responsibility Mapping
• Updating a Responsibility Mapping
• Turning Standard Service Security On or Off
• Creating Your Own Custom Security
• Enabling Responsibility Mappings for Oracle iSupport

Overview of Security Topic Organization

This group of topics explains how you can restrict user access to service request and case data.

• About Service Request and Case Security provides an overview.

• Setting Up Service Request Data Security outlines the major steps.

• Creating Your Own Custom Security provides guidelines for organizations who want to set up their own custom security.

The rest of the topics provide detailed procedures:

• Mapping Responsibilities to Service Request Types and Status Groups

• Turning Security On or Off

About Service Request and Case Security

Oracle TeleService supports both function and data security provided with all applications. See Oracle E-Business Suite Security Guide for details.

In addition, your application provides standard service security, data security built on top of the standard application security. This makes it possible for you to restrict by responsibility the ability of users to view and update service requests and related objects by service request (case) type.

Note: The security features for service requests and cases are identical. If you are implementing Case Management, then read case for every mention of service request in this guide and in the user interface used for setup.

To enable standard service security, you must map responsibilities to service request types and turn the standard security on according to the procedures in this chapter.

Note: If you are running multiple service applications in the same database instance, then you must map responsibilities to service request types and turn standard security on to keep users from one application accessing service requests of the other.

For example, an implementation running both Customer Support (to support customers) and Service Desk (to support employees) must create separate service request types and mappings for each application to prevent agents helping employees from viewing service requests logged for customers.

Note: Standard service security relies on the global application context that is set by the application framework on login. If you are using the Service Request public APIs to create and update service requests in an asynchronous manner, then the original application context may be lost. For this reason, you must set the global application context (user_id, resp_id, and resp_appl_id) to the original application context values to ensure that the user had appropriate access to the service request data.

Features of Standard Service Request Security

Standard service request security:

• Prevents users from creating, viewing, and modifying all service request data related to the service request types not mapped to their responsibility. This includes service request tasks, notes, and interaction history. It even prevents users from viewing relationships of a service request to other service requests of types they cannot access.

• Excludes them from the lists of resources used for service request ownership and tasks assignment.

  Note: For work assignment with the standard service request security enabled, you must make sure every employee has a user account and that the user account is associated with the resource.

  If you are assigning service requests or tasks to nonemployee resources who access the service requests or tasks through a third party software application, then you do not have to set up users for them.

• Prevents them from retrieving service requests via searches

• Prevents them from retrieving service requests via the Oracle Knowledge Management application

Standard security secures service request data not just in Oracle TeleService, but in all applications that use service requests. (See How Turning on Standard Service Security Impacts Other Applications.)

Turning service security on or off does not affect objects such as tasks and notes that are not attached to service requests.

Read-Only and Other Access Types

Standard service security provides either no access or create/update access. It does not distinguish between read-only access and update access.

To provide users with read-only access, you must implement custom data security.

The HTML-based Oracle TeleService modules provide a read-only page for agents with read-only permissions.

The Forms-based Oracle TeleService module and Oracle Depot Repair, however, displays the service request in the edit mode. Users who are restricted to read-only access get no indication that updates are disallowed until they attempt to save their changes and the application displays an error message.

Effect of Turning on Standard Service Security on Other Applications

Turning on standard service security affects all applications and Oracle application foundation modules that use service requests to different degrees:

• Oracle iSupport

  Customers creating service requests on the Web are subject to Oracle iSupport's own security, which is based on the customer: Customer contacts have access only to service requests for their organization.

  You can create responsibility to service request type mappings to prevent customer contacts from creating service requests of types not mapped to their responsibility. However, this restriction is for creation only. Those contacts are not restricted from viewing or updating any service request permitted by Oracle iSupport security.

  When agents work with customer-created service requests in other service applications, however, they are subject to full standard security restrictions (the same as for any other service request.)

• Tasks

  Tasks enforces standard service security only partially. Task standalone forms display all service request tasks regardless of the service request type. However, agents are prevented from making updates in all Task windows.

• Assignment Manager

  The Assignment Manger enforces standard service security fully. This means this module assigns only resources that have access to the service request type.

• Oracle Inbound

  If you have set up an Interactive Voice Recognition (IVR) system to route calls based on customer entering service request numbers, then these calls are routed only to agents who have access to service requests of this type.

  Agents transferring calls regarding service requests to other agents are restricted to transferring the calls only to agents with access to the service request type.

  All telephony implementations must map at least one agent in the call center to each service request type coming through the call center.

• Universal Work Queue

  The UWQ enforces standard security fully. This means:

  • Work queues of each agent display only those service requests of types the agent can access.

  • The number of service requests displayed in each node sums up only information agents can access.

  • The tasks nodes display all tasks, including all service request tasks. However, the agent cannot view the details of service request tasks they cannot access.

  • The Next Work and Request Work buttons assign only work the user can access.

• Oracle Depot Repair

  Oracle Depot Repair enforces service security fully.

• Oracle Enterprise Asset Management

  Users associating work orders to service requests can only see and select those service requests of types they can access.

• Oracle Installed Base

  Oracle Installed Base usually permits users to view all the service requests logged for a customer's product. Turning the standard security restricts that view to those service requests of types mapped to the responsibility.

• Oracle Field Service and Oracle Field Service Technician Portal

  Standard security affects the availability of service request details for dispatchers and technicians. For users to be able to drill down to view service request details, you must ensure that their responsibility has the appropriate service request types mapped.

Setting Up Service Request Data Security Process Overview

Use this high-level procedure to guide your implementation of the service request security.

To use the standard security provided with your application

1. Under the Service responsibility, navigate to Setup, then Mapping, and select Responsibility Mapping and map each responsibility to the service request types you wish users to access. Unmapped responsibilities cannot view or modify any service requests or related objects. For detailed procedures, see Mapping Responsibilities to Service Request Types.

2. Navigate to Setup, then Rules, and select Service System Parameters and turn standard security on. For details, see Turning Security On or Off.

To implement custom data security

1. Create custom security according to procedures described in Oracle E-Business Suite Security Guide - . See Creating Your Own Custom Security for guidelines.

2. Navigate to Setup, then Rules, and select Service System Parameters and turn the custom security on by selecting Custom Security from the Service Request Security drop-down list. For details, see Turning Security On or Off.

About Mapping Responsibilities

This group of topics explains why and how you map responsibilities to service request types and status groups. It covers:

• The Two Different Uses of Responsibility Mappings

• Where You Create and Update Responsibility Mappings

• Creating a New Responsibility Mapping

• Updating a Responsibility Mapping

Uses of Responsibility Mappings

You create mapping between service request types, responsibilities, and status groups for two reasons:

• As part of standard service security setup to specify which responsibilities get to access which service request types

  If you are using standard service request security, then you must specify which service request types an agent can use by mapping service request types to responsibilities.

• To specify different status groups for different responsibilities that use the service request type.

  By mapping different status groups to different responsibilities, you can specify different behavior for different users of the same service request type. By making different statuses or transitions available, you can, for example, permit only managers to set a service request to a Closed status. See Status Groups and Status Transitions and About Mapping Status Groups to Service Request Types and Responsibilities.

  If you do not specify a status group when mapping a service request type to a responsibility, then the application uses the default mapping created in the Service Request Types page.

  The mapping of status groups is independent of standard security. This means that the mappings work even if you choose to use custom security.

  Note: If you are automatically closing duplicate service requests using the status update feature offered by service request relationships, then you must include the seeded statuses of “Waiting”, “Clear”, and “Closed” and the status group transition rules must permit all statuses to transition to the status of “Closed” for the responsibility creating the relationship. For more information, see Service Request Linking to Specify Duplication and Other Relationships.

Where You Create and Update Responsibility Mappings

You create and update mappings from the Service Responsibility Setup page. (Navigation: Setup, Mapping, Responsibility Mapping).

From this page you can:

• Click Add Responsibility to create a mapping . See Creating a New Responsibility Mapping.

• ClickUpdate to update an existing mapping. See Updating a Responsibility Mapping.

• Click Remove to delete a mapping.

Notes:

By default, the page displays only active mappings. You can change the view by making an alternate selection from the View list:

• All: Includes active, inactive, and planned mappings.

• Planned: Limits the display to mappings that are not yet in effect.

• Active: (the default) Displays only mappings that are currently in effect.

Creating a Responsibility Mapping

Use this procedure to map service request types and status groups to responsibilities.

To map a responsibility

1. Under the Service responsibility, navigate to Setup, then Mapping, then Responsibility Mapping.

   The Service Responsibility Setup page appears.

2. Click Add Responsibility.

   The Step 1 Add Service Responsibility page appears.

   

3. Select the responsibility you want to map.

4. Use the Classification list to specify "Service Provider" if the mapping is intended for Oracle TeleService or other agent-facing service applications. Choose "Self Service User" for Oracle iSupport.

   If you selected "Self Service User", you can only map those service request types that have been set up with the Web Entry check box selected. For details, see Setting Up Service Request Types.

   If you selected "Service Provider", you can specify any service request types, including those specific to Oracle iSupport.

5. Select the type of mapping you wish to create using the Access list:

   • To grant this responsibility access to all Service Request Types, select All Request Types. If you have selected Self Service User in the last step, then you are mapping the responsibility only to those Service Request Types that are specified for Web entry.

     Note: Granting All Request Types access provides access not only to all existing Service Request Types, but also all of those created in the future.

   • To enable access for this responsibility to a subset of service request types, select Select Service Request Type.

6. Click Continue.

   Step 2 Map Responsibility to Service Request Types page appears.

7. If you selected Select Service Request Type, then select one or more types:

   1. Click Add Another Row.

   2. Select a Service Request Type.

8. To specify a status group for this service request type and responsibility, select it from the Status Group list. For users of this responsibility, the selection you make here overrides the mapping you have made in the Service Request Types page. If you do not make a mapping here, then the application automatically uses the mapping you have entered in Service Request Types page.

9. Optionally, enter dates in the Start Date and End Date fields if you to restrict the availability of this mapping.

10. Click Finish to save your entries and return to the Service Responsibility Setup page.

Updating a Responsibility Mapping

Use this procedure to update a responsibility to a service request type and status group mapping.

To update a responsibility mapping

1. Under the service responsibility, navigate to Setup, then Mapping, and select Responsibility Mapping.

   The Service Responsibility Setup page appears in a browser window.

2. To change the classification or acess type for this mapping:

   1. Click Update Responsibility.

      The Update Responsibility Setup window appears.Here you can select a different access type and classification.

   2. Click Apply.

      You are returned to the Mapping of Responsibility to Service Request Types page.

3. Click Update next to the mapping you wish to update.

   The Mapping of Responsibility to Service Request Types page appears.

   On this page you can:

   • Remove a service request type from the mapping, by entering an end date.

   • Specify a service request status group.

   • Map additional types using the Add Another Row button.

Turning Standard Service Security On or Off

Use this procedure to turn on or turn off service request security.

Note: If you turn standard service security on or off while users are accessing the application, then you may have to bounce the Apache server after you have changed the setting.

Prerequisites:

You must map service request types to responsibilities or create your own custom security framework before turning security on as a second step. Turning security on as a first step prevents all users from accessing service requests, tasks, and other related business objects.

To turn security on or off

1. Navigate to Setup, then Rules, and select Service System Parameters.

   The Service System Parameters page appears.

   Note: Only the Security region relates to security. The second Self Service region, is for restricting customer access to service request types during service request creation in Oracle iSupport. See Enabling Responsibility Mappings for Oracle iSupport.

   

2. Using the Service Request Security list, select one of the following:

   • No Security: to turn off security and make all service requests and related tasks available to all users.

   • Standard Security: to enable service security supplied with the application.

   • Custom Security: to disable the seeded security and turn on your own custom security.

3. Click Apply.

Creating Your Own Custom Security

Your organization can create its own custom security framework according to the concepts and procedures described in Oracle E-Business Suite Security Guide.

For example, you may want to:

• Restrict users to view only privileges

• Restrict the ability of users to view service requests by status.

  Limiting users to only viewing service requests with the status of Open, for example. You can do so, by inserting a WHERE clause in the SQL statement of the object instance set predicate.

• Restrict access to service requests, tasks, and other business objects to specific responsibilities or individuals

  You can accomplish this by selecting a more restricted grantee such as a responsibility or a resource. By default, all seeded grantees are global.

The custom security you create replaces the standard security provided with your application.

Note: The application expects all grants to obey the following rules:

• Anyone with create access to a service request must also have read and update access to the service request.

• Anyone with update access to a service request must also have read access to the service request.

When you turn service security off, the predefined grants are disabled.

You can use the predefined data as a guide for creating custom security. See Standard Service Security Predefined Data for a list of predefined data.

Enabling Responsibility Mappings for Oracle iSupport

You can restrict customer contacts from creating service requests by service request type. To do so, you create the same responsibility to service request type mappings used in standard service security and then turn on the mappings using the procedure below.

Prerequisites:

You must map Oracle iSupport responsibilities to service request types that have been specified as Web Enabled. (See Mapping Responsibilities to Service Request Types.)

To use mappings to restrict request creation in Oracle iSupport

1. Under the Service responsibility, navigate to Setup, then Rules, and select Service System Parameters.

   The Service System Parameters page appears.

2. To restrict Oracle iSupport users from creating service requests of types mapped to their responsibility, select the Only Service Request Types Mapped to User's Responsibility option. This restricts only the creation of service requests; not the ability to access existing requests.

   Note: You can use the mappings for this purpose even when standard security is turned off.

3. Selecting All Web Enabled Service Request Types permits users to create service request of any type specified as Web Entry enabled. Any mappings you have created are disabled.

4. Click Apply.