Learn how to use Oracle Virtual Private Database (VPD) to secure your data. See all lessons at http://skillbuilders.com/12c-TSDP-Tutorial
First, Virtual Private Database. What is it? Answer: It's a declarative technique for enforcing security. Typically, it's based on user application context. That was the first limitation of 8i. Backed with 8i context were session-specific. The context variables were sort in the PGA. That means you simply couldn't use this in a web environment.
However, global context, with use of 9i, Virtual Private Database became usable for web applications with connection pooling. But whether you're using it to client server or on a three tier environment, it's declarative technique rather than a programmatic technique.
I can go behind the back of the application as a DBA and generate predicates to get appended to all SQLs. Select, insert, update, delete the end users. Issue the SQL and I will generate a predicate that filters the access. It's impossible to bypass. All users will have predicates appended to all their code. It doesn't matter whether they're using SQL Plus, Discoverer, Business Objects, Crystal Reports, eBusiness Suites, whatever they're using, I as DBA can filter their access to roles.
The end result, different users see different data sets while running the same code and accessing the same tables, hence, the name Virtual Private Database. Different users will think they're seeing a totally different set of tables, but in fact it's one column database, one set of tables hosting a single application shared by all the users.
The mechanism - you can apply VPD to tables, to views, to synonyms, and a declarative technique. Once the technique you write a function that generates the predicate, you associate the function with the table. From then on whenever the user issue SQL against that table the Cost-Based Optimizer rewrites the code. The Cost-Based Optimizer rewrites the user SQL to call the function to generate the predicate. The predicate is then appended to the SQL and it's the modified SQL that is parsed and executed.
Let's see how this actually works. I'm working here by the way.
This is just a perfectly normal 12.1 database. But what I'm going to demonstrate at this point will in fact work on 11g as well. I'm not going to be using any of the 12c enhancements to VPD for this little demonstration.
I'll work in the scott schema. What do we have to do? We write a function to generate the predicate string. Create function.
And I'll my function vpdf. The function must conform to a fixed specification. It must take two varchar arguments. One of the arguments is intended to be the schema to which the function will be applied. The other argument is the object within the schema to which the function will be applied. And it must return a varchar2, which is the generated predicate. Let's begin.
Within this function you can do just about anything. There are some limitations. It's impossible for the function to query or update the table against which the VPD calls here is going to be applied or we violate the rules of purity that we come across so often with PL/SQL. But apart from that, it can do just about anything - including a number of dreadful side effects can be introduced by writing VPD functions.
I'm going to do a very simple one on this one. I'll shall simple return immediately a predicate. What predicate? Ename, which is the ename column from this scott.emp table. Ename should equal sys_context.
I'll go to the local context, my user end context, and just extract session user.
We can see that John has tested this earlier today and therefore the object already was suggesting and he's just dropping it now and cleaning up the recreate.
I hope you realize these really are live demonstrations. I'm not just running scripts.
I've created a function. What's that function going to do? It's going to return this value here. Test it. Always test it and see what it's actually going to do. I'll select vpdf. I have to give it a couple of arguments. This one will do for now.