Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager
11g Release 2 (11.1.2.0)

Part Number E27207-20
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

27 Multitenancy Access Control for CSR and Agent Operation

This chapter details the multitenancy access control feature of Oracle Adaptive Access Manager. Multitenancy access control handles access to the OAAM Administration Console for each organization so that it results in a different experience for administrative users of multiple tenants.

27.1 Multitenancy Access Control

Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations. With a multitenant architecture, each client organization feels as if they are working with a separate customized application instance.

Figure 27-1 shows a multitenancy access control scenario.

Figure 27-1 Multitenant Access Control Scenario

A Multitenant SaaS is shown.

Application ID

This is the application request coming from the client (browser). Generally the URL is mapped to an Application ID which is mapped to an Organization ID.

Organization ID

Each user belongs to only one Organization ID. It identifies what tenant applications a user utilizes and scopes which OAAM policies will run for them.

Shared Infrastructure/Shared Application

In the example shown in Figure 27-1, the online banking application (same instance of the same server) has its data partition in such a way that the application appears different for each client.

Awareness of the Applications

The online banking application can be customized by organizations as though each organization had a separate application. Each "application" corresponds to an Application ID: Bank1, Bank2, Bank3, and Bank4.

27.2 Mapping of Application ID (Client-Side) to Organization ID (Administration Side)

To ensure that a customer's data is unique from that of other customers, the Application ID is mapped to an Organization ID for use in OAAM Admin.

The Application ID of the client application is mapped to an Organization ID. Users are autoprovisioned to an Organization ID when they access an application for the first time. For information on mapping applications to Organization IDs, refer to the "Determining Application ID and User Group" section of the Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.

The Application ID is used by OAAM Server to personalize and brand customer pages. They are used by OAAM Admin to determine which set of configuration properties to use to customize the customer applications. For information on customizing user interface branding, refer to the "Customizing User Interface Branding" section of the Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.

From the user's perspective, there is no indication that the (online banking) application is being shared among multiple tenants. When the users access that application, they may go through a specific URL for the bank application or communicate the Organization ID in one of two other ways. OAAM Server can use the URL to display the appropriate pages. Then, the user enters his User ID, which is mapped to an Organization ID.

Figure 27-2 Mapping of Application ID to Organization ID

This illustrates the mapping of appid to orgid

But if banks share a common URL, OAAM Server does not know where users are logging in from; therefore it displays a generic bank screen. OAAM Server can be configured for one of the following scenarios: In example 1, the user enters a User ID and the Organization ID and that combination tells OAAM Server which pages to display. In example 2, the user enters a User ID and through an Organization ID look up OAAM Server is able to determine the correct pages to display. In example 3, the user is directed to the correct screen as soon as he accesses the URL.

27.3 Set Up Access Control for Multitenancy

To set up access control for multitenancy, perform the procedures in this session.

27.3.1 Set Access Control for Multitenancy

To set up access control for multitenancy, perform the following steps:

  1. In the Properties Search page, specify bharosa.multitenant.boolean as the name to search for.

  2. Click Search.

  3. Change the value of the bharosa.multitenant.boolean property to true. If you cannot find the property, create it and set it to true.

27.3.2 Providing CSR Access to Particular Organizations

To provide access to a particular organization to the CSR administrative user, the CSR administrative user needs to belong to that organization.

At any point, a CSR or CSR Manager can be servicing more than one organization. He will be able to see all the cases of the organizations he is assigned to.

When CSRs are changed or added to an organization, the setting takes effect at the next login and not for the current login.

If you are migrating from a previous release, you can continue to operate as you have been without any change because out of the box, multitenancy access control is off. If you want multitenancy access control, you must set it up. Once you have set up multitenancy, access control is applied. For example, if a CSR belonged to Organization 1 in a previous release, he will still have access to all the cases in Organization 1 after access control is applied. If there is no access control previously, the CSR will have access to all cases. Now if multitenancy access control is set up, he can only see cases from Organization 1. If the CSR was working on five different cases from five different organizations before the upgrade to 11g, now he will not have access to them.

27.3.2.1 Using WebLogic

To achieve this, an organization with the exact same name as the Organization ID must exist and then that organization should be assigned to the CSR administrative user:

  1. Log in to the WebLogic Administration Console as a WebLogic user:

    http://hostname:port/console

    Where hostname is the hostname of the Administration Server and port is the address of the port on which the Administration Server is listening for requests (7001 by default).

  2. Create a group/organization using WebLogic Security Realms that exactly match the name of the Organization ID. For example, Bank1.

    Refer to the "Create groups" section of the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help 11g.

  3. Assign, as necessary/applicable, this group/organization to the CSR and CSR Manager, as necessary.

    Refer to the "Add users to groups" section in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help 11g.

To move a user from working on one organization to another:

  1. Log in to the WebLogic Administration Console as a WebLogic user:

    http://hostname:port/console

    Where hostname is the hostname of the Administration Server and port is the address of the port on which the Administration Server is listening for requests (7001 by default).

  2. In the Settings for Realm Name page, go to Users and Groups > Users in Security Realms.

  3. Change the user membership of the group/organization, by removing the group/organization from the CSR and CSR Manager, and adding the new group/organization to the CSR and CSR Manager.

    The changes are effective from the next login for the CSR and CSR Managers.

    Refer to the "Modify users" section in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help 11g.

27.3.2.2 Adding Users and Groups to Oracle Internet Directory

If you want to add users and groups through OID, refer to the "Adding Users and Groups to Oracle Internet Directory" in the Oracle Fusion Middleware Tutorial for Oracle Identity Management.

27.3.2.3 Adding Users and Groups in the LDAP Store

If you want to take care of user and group creation in the external LDAP store, see "Creating Users and Groups for Oracle Adaptive Access Manager" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management.

27.4 What to Expect

This section provides summaries and examples of the multitenant access control experience in OAAM. Multitenancy access control is only applicable for case management data access and filtering on Organization ID and filtering on Session search results. Oracle Adaptive Access Manager cannot control the data administration and security personnel view in the OAAM Administration Console.

Table 27-1 Multitenant Experiences for CSR and Agents

Task CSR Experience Agent Experience

Create CSR Case

CSRs can select one Organization ID to create a case.

N/A

Create Agent Case

N/A

Agents can select one Organization ID to create a case.

Search Cases

CSRs can see Organization IDs for which they have access, and from which they can select one (or more) Organization IDs.

Agents can see Organization IDs for which they have access, and from which they can select one (or more) Organization IDs.

View Cases

CSRs are able to see the cases from only those organization's users to which they have access.

Agents are able to see the cases from only those organization's users to which they have access. Escalated cases associated with the Organization ID to which agent has access are also included in the search result if it fits the query criterion.

Case Details

CSR can see the case detail for cases that belong to any user belonging to an organization he has access to. If the user does not belong to the organization he has access to, the CSR will not see that case in the search results.

Agents can see the case detail for cases that belong to any user belonging to an organization they have access to or cases that are associated with their Organization ID.

Case Actions

CSRs can perform case actions on cases they can see.

Agent can perform case actions on a cases they can see.

Sessions Search and Details Pages

CSRs do not have access to sessions search and details pages.

Agent cannot navigate to any of the details pages from sessions page or sessions search if multitenant access control is enabled. If multitenant access control is disabled, Agent is able to access details pages from any sessions search if the link is available.

Search Sessions

N/A

Agents can search sessions belonging to the users that belong to the organizations that they have access to and those organizations to which they have access.

Search Cases (with changed Organization ID Assignment)

CSR was assigned to "org1." He has created cases created for users in "org1."

He serviced users for that organization for some time.

He is then removed from "org1" service and has started servicing "org2."

When he logs in again after this, he can no longer see the cases for "org1" (whether he created them or not). He can only see and work on the cases that belong to "org2."

Same experience as the CSR.

Link Sessions

N/A

Agents can link sessions to the cases belonging to organizations that they have access to.

Also in search sessions for linking, Agents are able to see the sessions of only those organizations to which they have access.


27.5 Multitenancy Access Control Use Case

The following sections describe examples of common multitenant access control use cases.

27.5.1 CSR and CSR Manager Access Controls

Second Bank has deployed OAAM to secure both the consumer banking application and the business banking application. Their CSRs are broken up into two separate organizations. One organization assists only consumer banking customers and the other assists only business banking customers. They need to have strict control over the customer data visible to each of these CSR organizations. Also, there is a organization of senior CSR managers that need to have access to data for all customers. When the consumer banking CSR searches, views, creates, edits cases they only see data related to consumer banking customers. Likewise the business banking CSRs only see data for business banking customers. Neither is even aware that OAAM is doing this pre-filtering of data. The CSR managers can see data related to both consumer and business banking customer activity and they can perform all case flow operations.

Actors: CSR and CSR Manager

Setup: To set up the scenario:

  1. Enable multitenancy access control.

  2. Create consumer and business organizations to assist the customers with the exact names as the Organization IDs.

    One organization assists only consumer banking customers and the other assists only business banking customers. They need to have strict control over the customer data visible to each of these CSR organizations.

  3. Create CSR1, CSR2, and CSRSenior as administrators.

  4. Assign CSR1 to the consumer organization, CSR2 to the business organization, and CSRSenior to both consumer and business organizations.

    To provide access to a particular organization to the CSR administrative user, the CSR administrative user needs to belong to that organization.

    When the consumer banking CSRs (CSR1) search, view, create, and edit cases they only see data related to consumer banking customers. Likewise the business banking CSRs (CSR2) only see data for business banking customers. Neither is even aware that OAAM is doing this pre-filtering of data. The CSR managers (CSRSenior) can see data related to both consumer and business banking customer activity and they can perform all case flow operations.

Flow:

  1. CSR opens the OAAM Administration Console.

  2. CSR sees only the appropriate user interface views and controls afforded his role

  3. CSR sees only the appropriate data afforded by his role (Organization ID). He cannot see data for users/sessions related to Organization IDs he does not have permission to view.

  4. CSR Manager sees only the appropriate data afforded by his role (Organization ID). He cannot see data for users/sessions related to Organization IDs he does not have permission to view.

27.5.2 Agent Access Controls

Second Bank has deployed OAAM to secure both the consumer banking application and the business banking application. Their security analysts are broken up into two separate groups. One group investigates only consumer banking issues and the other investigates only business banking issues. They need to have strict control over all session, policy, and so on, and data visible to each of these security analysts organizations. Also, there is a organization of senior security analysts managers that need to have access to all data. When the consumer banking security analysts searches, views, creates, edits cases they only see data related to consumer banking. Likewise the business banking security analysts only see data for business banking. Neither is even aware that OAAM is doing this pre-filtering of data. The security analysts managers can see data related to both consumer and business banking activity/polices/and so on and they can perform all case flow operations. As well, managers have a filter so they can choose to only view business banking cases/data or only consumer banking cases/data.

Actors: Security Analyst and CSR

Flow:

  1. CSR/Analyst opens the OAAM Administration Console.

  2. CSR/Analyst sees only the appropriate user interface views and controls afforded his role.

  3. CSR/Analyst sees only the appropriate data afforded by his role (Organization ID). He cannot see data for users/sessions related to Organization IDs he does not have permission to view.

  4. CSR/Analyst Manager sees only the appropriate data afforded by his role (Organization ID). He ca not see data for users/sessions related to Organization IDs he does not have permission to view.

  5. CSR Manager can filter what data he sees based on Organization ID.

27.5.3 CSR Case API Data Access Controls

Second Bank decides to integrate OAAM with their existing customer ticketing application. They will use the APIs to get customer data and take customer service actions on behalf of customers. Their CSRs are broken up into two separate organizations. One organization assists only consumer banking customers and the other assists only business banking customers. They need to have strict control over the customer data visible to each of these CSR organizations. Also, there is an organization of senior CSR managers that need to have access to data for all customers. The API will allow them to configure the integration to control access to the customer data based on Organization ID to these different groups of employees.

Actor: CSR

Flow:

  1. CSR opens his custom console.

  2. CSR sees only the appropriate data afforded by his role (organization ID)

27.6 Troubleshooting/FAQ

This section provides information on how to troubleshoot problems that you might encounter when setting up multitenancy access control.

27.6.1 I thought I had set up multitenancy access control but CSRs and Investigators still have access to all cases

Verify that you have bharosa.multitenant.boolean set to true. If set to false, multitenancy access control is disabled. By default, multitenancy access control is disabled.

When multitenancy access control is disabled:

  • CSRs and Investigators can view and select from all the Organization IDs during case creation.

  • In the Cases Home page all Organization IDs are listed for CSRs and Investigators.

27.6.2 I have set up multitenancy access control and I have verified that the property is set to true but the CSRs and Investigators are able to access to all cases

You must log out and log back in for access control to be applied. Changing the property takes effect at the next login and not for the current login.

27.6.3 Are Security and System Administrators affected when I set up multitenancy access control?

Enabling and disabling multitenancy access control has no effect on users with the security and system administrator roles. Multitenancy access control is only applicable to case management. Their user experience will not be affected.

27.6.4 Can CSRs and Investigators have access to multiple organizations?

Yes. They can be assigned to multiple organizations.

27.6.5 Can I limit access of a CSR or Investigator to certain organizations even though he had access before?

Yes. Once access control is set up appropriately, the CSR or Investigator will not have access to that Organization ID anymore. He will be limited from accessing the cases of that organization. Changing the property takes effect at the next login and not for the current login.

27.6.6 My CSRs and Investigators have no access to cases. What is wrong?

Make sure the CSRs and Investigators are assigned to proper roles and organizations so they can access the cases.