Problem
Is it possible to design a multi-tenant architecture in an Oracle DB instance, such that different customers’ data is transparently partitioned whilst keeping common code and common tables in a single location?
Possible Strategy
Consider the following architecture:
Here we have two schemas in an Oracle database instance:
- U_Common contains common tables and stored procedures, packages, etc.
- U_Cust_1 contains customer-specific tables, with private data.
- Client processes acting on behalf of Customer_1 are connecting to the U_Cust_1 schema.
(You may assume we also have U_Cust_2, etc.)
Assume that all access is performed through stored procedures or similar code objects.
In order for sessions connecting to U_Cust_1 to execute specific procedures in U_Common, they need:
- EXECUTE permissions on the objects in U_Common;
- Either:
o explicit namespace prefixes, e.g. U_Common.DoSomething()
o a synonym object referencing the code object in U_Common
In order to have common code objects that reference both common tables and customer tables, we need to create “template” versions of the tables in the U_Common schema:
However, when U_Cust_1 invokes the procedure in U_Common, the session can’t “see” the customer-specific version of the table, because the code is executing in the context of U_Common. It will see the template table data (or lack of it – presumably there are no rows in the template tables).
This can be addressed by adjusting the AUTHID pragma when the code objects are defined:
Default:
create or replace package U_Common [authid definer] is ..
Change to:
create or replace package U_Common authid current_user is ..
According to the documentation, this AUTHID clause instructs Oracle on whether to run the code with the invoker’s rights, or the owner’s rights. (the default is DEFINER, or owner.)
In practice, this means that when U_Cust_1 executes the code object defined as AUTHID CURRENT_USER, the customer tables in U_Cust_1 are in scope, and are accessed instead of the template tables in the U_Common schema.
Two interesting observations about executing code defined as AUTHID CURRENT_USER:
- the code does NOT see the Common tables. Any table in U_Common is “out of scope”;
- the code can see other procedures and packages in U_Common, including those defined as AUTHID DEFINER (default);
- when the code makes a nested call to those other procedures, the tables in U_Common are now visible!
Here’s a sequence diagram of the call stack:
This means that everything will work just fine, so long as the code objects are classified into “programs that access common data” and “programs that access customer data”.
Concerning Views
Views don’t work so well.
You can define a view in U_Common that joins a Common table with a Customer table, but any U_Common procedure that is authid current_user will not be able to “see” the view from the context of U_Cust_1.
You can try this:
grant SELECT on View to U_Cust_1
create synonym in U_Cust_1 for the U_Common.View
But the result set will be entirely pulled from the U_Common schema tables.
So this technique probably isn’t going to be used to create a transparently customer-partitioned application architecture. But it is still worth understanding how AUTHID works.
Recent Comments