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

Part Number E14568-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

24 Multitenancy

Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants).

With a multitenant architecture, a software application is designed to virtually partition its data and configuration so that each client organization works with a customized virtual application instance.

The distinction between the customers is achieved during application design, so that customers do not share or see each other's data.

Oracle Adaptive Access Manager by default is enabled for multitenancy. A single shared instance of Oracle Adaptive Access Manager can support multiple tenants. Policies and rules can be centrally administrated and can be shared between applications, with the option to personalize for individual applications.

24.1 Multitenancy Scenario

Figure 24-1 shows a multitenancy scenario.

Figure 24-1 Multitenant SaaS

A Multitenant SaaS is shown.

Shared Infrastructure/Shared Application

In the example shown in Figure 24-1, the online banking application (same instance of the same server) is divided into virtual instances used by different tenants.

Awareness of the Applications

Each "application" corresponds to an Application ID: Bank1, Bank2, Bank3, and Bank4.

The online banking application can be customized by organizations as though each organization had a separate application.

The shared application presents the appropriate interface to any particular tenant at any given time. If the customer tries to access Bank1, a personalized customized interface for Bank 1 appears.

Access Control for All of Users Involved

Customers who use the "applications" are Customer (Bank 1), Customer (Bank2), Customer (Bank 3), and Customer (Bank 4).

The data and customizations are insulated from all of the other tenants.

24.2 Changes in Terminology

Some key terminology used in the 10g has changed in 11g. Table 24-1 shows the changes.

Table 24-1 Terminology Changes

For Deployed Application 10g terminology 11g terminology

OAAM Admin Console

Primary user group

Organization ID

OAAM Admin Console

Application ID

Organization ID

OAAM Server

Application ID

Remains same as 10g


Organization ID

Each end-user belongs to a single Organization ID. Multiple applications can be mapped to an Organization ID. The opposite is not true however.

Application ID

The Application ID is a transient value that uniquely identifies an application to allow specific control of the user experience. Application ID remains unchanged in 11gR1.

Deprovisioning

Users can not be easily removed from an Organization ID. Deprovisioning can be accomplished handled through native integration APIs only.

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

To ensure that customer 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.

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.

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, user enters his user ID, which is mapped to an Organization ID.

Figure 24-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 (which pages the organization and policy map to).

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.

24.4 Multitenant Support In Oracle Adaptive Access Manager

For areas other than case management, data access filtered on organization ID is not supported currently. Oracle Adaptive Access Manager cannot control the data administration and security personnel view in the Admin Console.

Policy scoping can be accomplished for specific subgroups of tenants to who use the same applications; user groups can be configured to categorize these populations of users.

These user groups must be manually maintained. Autoprovisioning is not available for the groups.