VPD policies

I have a couple of generic questions regarding VPD policies :-
1. If a user has rights to select a record but does not have rights to UPDATE,then clicking SAVE button on my page shows the "record saved" message without saving anything,is there any way I can tell my users "Hey not saving cause you are not authorized !" ? I understand it behaves the same from sqlplus and returns "0 rows updated" but the users will got frustrated cause what they are trying to save is never getting saved and there is nothing which tells them that they do not have the required privileges
2. what is the benefit of using application contexts ? I have based my VPD policies using an article that appeared in Oracle mag- http://www.oracle.com/technology/oramag/oracle/04-mar/o24tech_security.html. This article does not use sys_context.
tks

Scott
I had a think about that and putting a condition on the SAVE button solves this problem but I need to have a streamlined solution, I guess I am moving away from my original question now :-)
I am trying to design the security for our application and it needs to be defined at two different levels :-
one which defines the access rights for roles in terms of what pages/tabs/regions a role can see, it would define if a role is allowed to see CREATE or DELETE or SAVE buttons on any page - this would be achieved by authorization schemes.
And the second which would be controlled by VPD will define which role has S/I/U/D rights for which departments and organisation units.
I realize both these access rules will need to work together and my security design has to consider both of them but what I am finding hard to work out is that I have an application having abt 35 pages and about 20 tables ; I cannot pass parameters to authorization schemes and if I were to attach security to every component then I will end up with heaps and heaps of authorization schemes. A typical page has 3 buttons and 2 regions - I don't want to have 5 authorization shemes for just this page.
Do I need to have a repository(table) which records each and every component(button/region) for each and every page and do its ongoing maintenance ?
Is there a way to call a generic security validation which toggles things here and there the moment user loggs in without having to call a authorization scheme for every component.
thanks

Similar Messages

Converting a delete statement using VPD policies and context

Hello,
I'm trying to convert a delete statement in a update statement using VPD policies and context.
+/* Supose the user 'user1' already exists. This is an application user */+
conn user1/pwd
create table user1.test_a (
id                number(4),
description       varchar2(100),
deleted           number(1)
+);+
alter table user1.test_a add constraint test_a_pk primary key (id);
insert into user1.test_a (1, 'abc', 0);
insert into user1.test_a (2, 'def', 0);
commit;
I'd like to convert each physical deletion into a logical deletion: statements like "delete from user1.test_a where id = 1" must be converted into "update user1.test_a set deleted = 1 where id = 1".
I've found the following way: I will create a policy to avoid physical deletion. Additionally, the policy function should update the deletion flag too.
conn user1/pwd
+/* Create context package */+
create or replace package user1.pkg_security_context is
procedure p_set_ctx(
i_test_a_id      in   user1.test_a.id   %type
+);+
end;
+/+
create or replace package body user1.pkg_security_context is
procedure p_set_ctx (
i_test_a_id      in   user1.test_a.id   %type
+) is+
begin
dbms_session.set_context( 'user1_ctx', 'test_a_id', i_test_a_id );
end;
end;
+/+
show errors
+/* Create trigger to set the context before deletion */+
create or replace trigger user1.test_a_bef_trg
before delete on user1.test_a
for each row
declare
pragma autonomous_transaction;
begin
-- only commits the preceding update, not the delete that fired the trigger.
commit;
user1.pkg_security_context.p_set_ctx( :old.id );
end;
+/+
show errors
create context user1_ctx using user1.pkg_security_context;
+/* Policy function */+
create or replace function user1.f_policy_chk_dels (
object_schema in   varchar2,
object_name   in   varchar2
+) return varchar2+
is
out_string                 varchar2(400)   default '1=2 ';
+/*+
* out_string is the return value.
* - 'WHERE 1=2' means 'nothing to access'
begin
if ( loc_logged_usr_authorized > 0 ) then
+/*+
* Set the flag deleted to 1
update user1.test_a set deleted = 1 where id = sys_context( 'user1_ctx', 'test_a_id' );
out_string := out_string || 'or 1=1 ';
end if;
return out_string;
end;
+/+
show errors
+/*+
* Create policy
begin
dbms_rls.add_policy(
object_schema   => 'user1'                   ,
object_name     => 'test_a'                  ,
policy_name     => 'policy_chk_dels'         ,
function_schema => 'user1'                   , -- function schema
policy_function => 'f_policy_chk_dels'       , -- policy function
statement_types => 'DELETE'
+);+
end;
+/+
When I try to delete a record of the table test_a:
conn user1/pwd
SQL> delete from ilogdia.oplsimulaciones sim       where sim.id = 9999;
+0 rows deleted+
No rows has been deleted, but the update stmt does not work. That means, the "deleted" flag has not been updated.
Any ideas?
Thank you in advance.
Marco A. Serrano
Edited by: albrotar on Oct 15, 2012 8:42 AM
Edited by: albrotar on Oct 15, 2012 8:42 AM
Edited by: albrotar on Oct 15, 2012 8:43 AM

The policy function is applied once per statement execution. The policy function executes first and the UPDATE statement, presumably, updates no rows because the context is not yet populated. The row-level populates the context (I'm assuming that your session can even see context values populated by an autonomous transaction-- I would guess it could but I'd have to test that) after the UPDATE statement is already complete. The COMMIT in the row-level trigger is also pointless-- it only applies to changes made by the current autonomous transaction, of which there are none-- it cannot apply to changes made in other autonomous transactions. Declaring the row-level trigger to use autonomous transactions doesn't seem to accomplish anything other than to open the question of whether the values set in the context by the autonomous transaction are visible in the caller's transaction.
Even if this, somehow, did work, using autonomous transactions would be a very bad idea since Oracle is free to roll-back a partially executed statement (and the work done by its triggers) and re-execute it. Oracle does that with some regularity to maintain write consistency.
Justin

How to get Info about all VPD policies configured?

Hi,
is it possible to get a list of all VPD policies configured in the database?
$VPD_POLICY - displays all the fine-grained security policies and predicates associated with the cursors currently in the library cache.
`- It's empty. This means that this view is populated only if the policy is currently used ..
Thanks.

I have not checked but the dba_* views should be able to give to you this. V$vpd_policy only shows the what's there in the library cache.
Please see this link,
http://download.oracle.com/docs/cd/E11882_01/network.112/e10574/vpd.htm#CIHJGHDE
HTH
Aman....

Support for VPD Policies in SQL Developer?

I've searched the GUI, the help and the google (TM). Is there support for VPD Policies in Oracle SQL Developer. Examples of things would be to enable and disable them, create new ones, etc.

Not as such, but you can always manage them through worksheet statements.
You can request this at the SQL Developer Exchange though, so other users can vote and add weight for possible future implementation.
Regards,
K.

Export Dump File without defined VPD policies

Hi there,
Can some one help me on this problem ?
I've some tables with vpd policies defined on them. When I export these tables the dump file puts some instructions related to these policies such as:
EXECUTE DBMS_RLS.ADD_GROUPED_POLICY(sys_context('userenv','current_schema'),'"TABLE1"','SYS_DEFAULT','POLICY1','MD','ACESS1','SELECT,UPDATE,DELETE',FALSE,TRUE,TRUE);
Then when I try to import those tables, I'm getting some problems with that if I don't have those policies/functions created (which is the case).
So,
how can I export tables without those instructions ?
Or
how can I prevent the execution of those lines during import task ?
Thanks in advance,
Helena

In both (export and import) cases the policy could also be disabled for the duration export and import.

How to copy all vpd policies to another schema ?

Hi all,
I have two schema :
app_test
app_live
app_test has 70 VPD policies implemented.
How to copy those policies to be implemented also in app_live ?
(to avoid runnng the script one by one again ?)
Thank you,
xtanto

To another schema?
You will need to run all the scripts again, in another schema.

Q : Using column level VPD policies with Oracle Jdeveloper ADF BC ?

For one of our big customer, we already successfully developped a new java application using Oracle Jdeveloper with ADF, ADF BC and the Virtual Private Database (VPD) with row level policies.
Our customer has new business requirements that could be fullfilled using column level VPD policies.
Has someone already successfully (or not) developped a business application using column level VPD policies with ADF, ADF BC on Oracle 10g R2 database and OracleAS 10g (10.1.2) ?
Is it supported by Oracle ? what are the pitfalls, difficulties, problems you've met ?
Is it a viable solution and if not, why ?
Thanks in advance.
Rémy

Tomas,
my 2 cent:
if you know how to get the info from the db during run time you should be able to overwrite the frameworks message bundle look to get the description from the db instead of from the resource bundle.
Or you load all descriptions from the db into a resource bundle and use the keys in the tooltip directly.
Timo

Order of execution of VPD policies

Hi,
I have a table on which I have defined two policies (one for column masking and one for row filtering).
From whatever testing I have done, it seems the policy functions get executed in the order in which the policies were created.
Does oracle guarantee any order of execution of policies defined on the same table?
Thanks!
Edited by: kedruwsky on Sep 26, 2008 7:43 AM

Sounds more like a question for the Database General forum (General Database Discussions
I'm guessing that there's no guarantee on the order of execution, just like having multiple triggers on tables.

Best practice for VPD and remote tables

Not specifically an HTMLDB question, but here goes...
HTMLDB 1.6 on 9.2.0.4 connecting over database link (fixed username/password) to 9.2.0.4
I've currently "wrapped" access to the remote tables in views, i.e. view "T" in the HTMLDB parsing schema LOCAL_USER is defined as "SELECT * FROM T@remote"
I'd like to put VPD controls on my backend tables, but I don't get how v('APP_USER') (or even APP_USER put into an application context) would be seen by the remote database.
Should I just put VPD policies on LOCAL_USER's views and call it a day?
Thanks for input!
-John

If you implemented the VPD in the remote database, what would your VPD be restricting? All queries would apply the policy based on the DB link fixed username resulting in all users of the HTML DB application having same policy restrictions.
The policy in the remote database does not has access to the value of v('APP_USER'). That value is only available in the database that has HTML DB. You would have to write APIs in the remote database in PL/SQL functions/procedures to pass in the V('APP_USER') value to the remote database. This is doable, but cumbersome.
If you want to have your policy modify your WHERE clause on the fly based on your HTML DB user account, then I would implement the VPD in the database which has your HTML DB repository. I am not sure which of the two scenarios below occur when doing a SELECT * FROM T.
1.) The query goes across the database link, gets all the data out of table T in the remote database, passes back to the HTML DB database, and applies the policy WHERE clause modification in the HTML DB database.
2.) The query applies the policy WHERE clause modification to the view, goes across the database link with the WHERE clause modified, and gets only the data allowed based on the policy from the remote database.
You should test this out to find out for performance purposes what query is actually performed on the remote database.
As always if anyone sees anything inaccurate in what I have written, please correct me.
Mike

Using VPD in combination with a user table?

I'm very new with VPD's. In fact, I don't know a thing about it yet (I know the philosophy behind it and the principle, but not the practical implementation). My question: Are VPD's always based on database-users? Our applications have a user-table now, where the access rights to applications are stored. Once a user is present in that table and has the necessary rights, he can login to the application. So we don't have an actual database-user for each "real-life" user, just an entry in a table.
Is it possible to use the system of VPD's (and maybe Oracle Label Security) with users stored in a table, instead of actual database users?

TomVD wrote:
My question: Are VPD's always based on database-users? No, they are not. You could for example put VPD policies on tables that restrict access after a certain time of the day (not caring which user attempts to access the data, using only SYSDATE and a given cut off access time).
TomVD wrote:
Is it possible to use the system of VPD's (and maybe Oracle Label Security) with users stored in a table, instead of actual database users?Yes you can.
VPD allows you to construct a predicate as you would like based on your requirements (you are basically appending a WHERE clause in to every query based on the logic you dictate on the objects and accesses you determine necessary).
Typically if you're running through a connection pool (as it sounds like you are) you would use an application context to set a specific value (the logging in user) and then validate that against your Users table in whatever fashion tickles your fancy
[Some Tutorials|http://www.google.ca/#hl=en&source=hp&q=oracle+vpd+tutorial&btnG=Google+Search&meta=&aq=0&oq=oracle+vpd+&fp=8e6c6930b7d53e73] may also be helpful
and of course .. [The Documentation|http://download.oracle.com/docs/cd/E11882_01/network.112/e10574/vpd.htm]

VPD date issue between 10.1 and 10.2 databases

I have uncovered an issue today with VPD against date fields. The issue came up at a client site on a 10.2 database. When I got back to the hotel and tried this on my own database, which is 10.1, I got no issue and everything worked ok.
Therefore, I am asking if anyone is able to try out the following for me on different Oracle databases and platforms and let me know whether it worked for you or not. I'd like to compile a list of database versions and platforms on which the issue occurs.
Step 1: create this table as a user
CREATE TABLE TST_DATE AS (
SELECT 1 PERSON_UID,
Trunc(SYSDATE) BIRTH_DATE,
To_Char(Trunc(SYSDATE), 'DD-MON-YYYY') CHAR_DATE,
123456 TAX_ID,
'Smith, Michael B.' FULL_NAME FROM dual);
Step 2: grant select rights on the table
GRANT SELECT ON TST_DATE TO PUBLIC;
Step 3: switch your login to SYS and run this script:
CREATE OR REPLACE FUNCTION F_CHECK_ITEM_TST(p_object_schema in varchar2, p_object_name varchar2)
RETURN VARCHAR2 IS
V_PREDICATE VARCHAR2(2000) := '1 = 2';
BEGIN
RETURN(V_PREDICATE);
END F_CHECK_ITEM_TST;
Step 4: As SYS, run this to grant access rights over the function
GRANT EXECUTE ON F_CHECK_ITEM_TST TO PUBLIC;
Step 5: As SYS, run this to enable the policy
BEGIN DBMS_RLS.ADD_POLICY(
OBJECT_SCHEMA => 'DRAKE',
OBJECT_NAME => 'TST_DATE',
POLICY_NAME => 'SecByTST',
FUNCTION_SCHEMA => 'SYS',
POLICY_FUNCTION => 'F_CHECK_ITEM_TST',
STATEMENT_TYPES => 'SELECT',
POLICY_TYPE => DBMS_RLS.DYNAMIC,
SEC_RELEVANT_COLS => 'BIRTH_DATE',
SEC_RELEVANT_COLS_OPT => DBMS_RLS.ALL_ROWS);
END;
Note: in the above policy change the OBJECT_SCHEMA name to be the name of the user who owns the table you created in Step 1
Step 6: Go into Discoverer Admin and import the table as a new folder.
Be sure to uncheck the "Date hierarchies" box and set "Default aggregate on data points" to detail. Grant access to any user.
Step 7: Using Desktop or Plus, log in as that user then try to query the folder with the date not included, there should be no problem.
Step 8: Now try to query with the date included
On my 10.2 database I get ORA-24334: no descriptor for this position. This happens when logged into Discoverer as the table owner, EUL owner or any other user. However, when logged into Discoverer as SYS which is exempt from all VPD policies, there is no error when the date is included.
We tried this in Discoverer Desktop, Plus and Viewer with the same results in all three. We can successfully query the table from SQL*Plus, SQL Developer and TOAD.
There also seems to be no issue at all with the 10.1 database so there seems to be an issue between Discoverer and the 10.2 database.
What do you think?
P.S. to cancel the policy use this script when logged in as SYS:
EXEC DBMS_RLS.drop_policy(
OBJECT_SCHEMA => 'DRAKE',
OBJECT_NAME => 'TST_DATE',
POLICY_NAME => 'SecByTST');
This same information is available on my blog in a more readable format here:
http://learndiscoverer.blogspot.com/2006/12/vpd-date-issue-between-101-and-102.html

Hi Rod
Well don't you just love Oracle. Obviously, whatever tests were done for certifying Discoverer against the 10.2 database did not include checking VPD policies. This merits a blog entry from me.
Your workaround for V_PREDICATE VARCHAR2(2000) := 'BIRTH_DATE=TO_DATE(''01-JAN-0001'')'; works. However, I had to write a new function to do this because my real function was trapping about a dozen items at the same time, some dates, some numbers and some varchars - exactly the way that the Oracle example code shows it in the 10.2 database manual.
So what I did was to create a new function that only handles dates and added a dedicated policy that works with only that function. Unfortuately, because I have many dates to manage, I was unabe to hard code the BIRTH_DATE so here is what I did:
V_PREDICATE VARCHAR2(2000) := 'SYSDATE = TO_DATE(''01-JAN-0001'')';
This works perfectly and Discoverer stopped complaining. It just has two policies on the same table for different data items. Isn't VPD cool? I'm hooked.
I really appreciate your time and effort on this. Now, let's see what Oracle support make of the issue because I raised a service request last night. No reply yet I'm afraid.
Best wishes
Michael

VPD: Problems calling a function on another schema

Here's the setup:
I've create a schema called "AllYourBase". It contains all of my tables, views, functions, procs, etc.
These tables are protected by a DBMS_RLS policy. The policy uses a function to define its predicate which looks like this:
create or replace function tous_filter(schemaName varchar2, tableName varchar2)
return varchar2 is
begin
return 'account = sys_context(''USERENV'', ''CLIENT_IDENTIFIER'')';
end;
All of the tables have an account column for this to work. So far, this is a pretty basic VPD setup.
I have other db users that login and view data in the "AllYourBase" schema.
So when "ArbyLong" logs in, I set sys_context('USERENV', 'CLIENT_IDENTIFIER') to "ArbyLong", and when he runs a query, he gets back his rows.
Now, "AllYourBase" has several functions. Here's a very contrived, simplified example of one (but it illustrates the issue I'm running into just fine):
create or replace function getUserID
return integer is retval integer;
begin
select user_id into retval from users;
return (retval);
end;
When "ArbyLong" runs the equivalent query (select user_id from users), he gets back the one row where the account column is equal to "ArbyLong", as expected.
But this getUserID function lives in the "AllYourBase" schema. And here's the catch: I've made "AllYourBase" exempt from the policies by running "grant exempt access policy to AllYourBase".
When "ArbyLong" runs the function getUserID, it runs in the "AllYourBase" schema and pulls ALL of the rows from the users table.
This particular function simply errors out (since it's only expecting one row), but other functions are returning data that the logged in user shouldn't see.
So even though there are policies in place, by calling a function on another schema who is exempt from the policies, a user is able to see all returned data and not just the rows they are normally limited to.
Ultimately my question is this: Is there a way to enforce VPD policies when a user calls a function that lives in another schema?
Doing my own research, the answers I've come up with are:
* Don't use "grant exempt policy"!
* Put the function directly into the users' schemas. So "ArbyLong" would have his own getUserID function that would look at the "AllYourBase" users table.
I'd rather not do either of these, so does anyone have any other ideas? If it turns out these are the only solutions, then I'll go with one of them.
Thanks!

Need more info. Are you using a ViewStack or other navigator container, and trying to access a view that has not been displayed yet, due to deferred instantiation?
If this post answers your question or helps, please mark it as such.
Greg Lafrance - Flex 2 and 3 ACE certified
www.ChikaraDev.com
Flex Training and Support Services

Error executing a query using VPD and BC4J

Hi all,
Our team is developing an application using an Oracle DB 9.2.0.4 and BC4J 10g (9.0.5.16.0) as persistence layer.
We also are using the VPD (virtual private database) to have security in the database at row level.
The problem we are facing is that every some time (days) we get a jdbc error when a query (see below) that uses VPD policies is executed. Once the error occurs I execute it from sqlplus without getting any error .. it only occurs from our java application.
To temporary solve this problem, we delete and recreate the VPD policies, then the application continue working fine for some time ...
I'll appreciate any comment / suggestions
Thank in advance.
Eduardo.
ERROR LOG:
oracle.jbo.SQLStmtException: JBO-27122: SQL error during statement preparation. Statement: SELECT * FROM (SELECT CalLocation.ID,
CalLocation.CODE, eo
CalLocation.NAME,
CalLocation.ZIP,
CalLocation.PHONE,
CalLocation.FAX,
CalLocation.ADDRESS1,
CalLocation.ADDRESS2,
CalLocation.URL,
CalLocation.OWNER,
CalLocation.CTY_ID,
CalLocation.DESCRIPTION,
ORefCity.CODE CTY_CODE,
ORefCountry.ID CTR_ID,
ORefCountry.CODE CTR_CODE,
ORefRegion.ID REG_ID,
ORefRegion.CODE REG_CODE
FROM CAL_LOCATIONS CalLocation,
OREF_CITIES ORefCity,
OREF_COUNTRIES ORefCountry,
OREF_REGIONS ORefRegion
WHERE ORefCity.ID = CalLocation.CTY_ID
and ORefCountry.ID = ORefCity.CTR_ID
and ORefRegion.ID = ORefCountry.REG_ID) QRSLT WHERE ( ( (CTY_ID = 867) ) )
## Detail 0 ##
java.sql.SQLException: Io exception: Broken pipe
     at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:189)
     at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:231)
     at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:345)
     at oracle.jdbc.driver.OracleStatement.open(OracleStatement.java:717)
     at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2605)
     at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:457)
     at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:387)

The symptoms we have been getting are quite similar to the bug 3662364 .
I'm going to implement the patch for that bug and see what happend then.
Thank you very much for your help.
Regards,
Eduardo.

PreparedStatement error using VPD

Hi all,
Our team is developing an application using an Oracle DB 9.2.0.4 and BC4J 10g (9.0.5.16.0) as persistence layer.
We also are using the VPD (virtual private database) to have security in the database at row level.
The problem we are facing is that every some time (days) we get a jdbc error when a query (see below) that uses VPD policies is executed. Once the error occurs I execute it from sqlplus without getting any error .. it only occurs from our java application.
To temporary solve this problem, we delete and recreate the VPD policies, then the application continue working fine for some time ...
I'll appreciate any comment / suggestions
Thank in advance.
Eduardo.
ERROR LOG:
oracle.jbo.SQLStmtException: JBO-27122: SQL error during statement preparation. Statement: SELECT * FROM (SELECT CalLocation.ID,
CalLocation.CODE, eo
CalLocation.NAME,
CalLocation.ZIP,
CalLocation.PHONE,
CalLocation.FAX,
CalLocation.ADDRESS1,
CalLocation.ADDRESS2,
CalLocation.URL,
CalLocation.OWNER,
CalLocation.CTY_ID,
CalLocation.DESCRIPTION,
ORefCity.CODE CTY_CODE,
ORefCountry.ID CTR_ID,
ORefCountry.CODE CTR_CODE,
ORefRegion.ID REG_ID,
ORefRegion.CODE REG_CODE
FROM CAL_LOCATIONS CalLocation,
OREF_CITIES ORefCity,
OREF_COUNTRIES ORefCountry,
OREF_REGIONS ORefRegion
WHERE ORefCity.ID = CalLocation.CTY_ID
and ORefCountry.ID = ORefCity.CTR_ID
and ORefRegion.ID = ORefCountry.REG_ID) QRSLT WHERE ( ( (CTY_ID = 867) ) )
## Detail 0 ##
java.sql.SQLException: Io exception: Broken pipe
     at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:189)
     at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:231)
     at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:345)
     at oracle.jdbc.driver.OracleStatement.open(OracleStatement.java:717)
     at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2605)
     at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:457)
     at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:387)

It seems to be related to the bug 3662364 .
Regards,
Eduardo.

Using VPD (Virtual Private Database) with Discoverer for Dummies

Firstly could you please excuse me for the title of the thread, but it’s all I could come up with. For those of you who are looking at me with a strange look of disgust, please view thread that started it all: BIS vs DBI vs Noetix .
Otherwise I’m hoping to gain a greater understanding of how VPD can be used to enhance Discoverer and it’s performance. I've just read that :
“Oracle 8i introduced the notion of a Virtual Private Database (VPD). A VPD offers Fine-Grained Access Control (FGAC) for secure separation of data. This ensures that users only have access to data that pertains to them. Using this option, one could even store multiple companies' data within the same schema, without them knowing about it.
VPD configuration is done via the DBMS_RLS (Row Level Security) package. Select from SYS.V$VPD_POLICY to see existing VPD configuration.”
With Regards to Discoverer, I would like to ask the following:
-When would be best to use VPD in Discoverer?
-Pro’s and Con’s of VPD?
-Tips / Tricks?
-and anything else Michael would like to add (I don’t believe there is a post limit, although this could change in the future)
I've found a few handy links:
http://www.adp-gmbh.ch/ora/security/vpd/index.html
http://www.oracle.com/technology/oramag/oracle/04-mar/o24tech_security.html
As Metalink support would say : I Looking forward to your ‘Positive’ comments. ;-)
Lance

Lance,
You sure do raise some interesting questions here.
I've noticed from some of your previous posts that you are using views to link Discoverer through to apps. I have found this very interesting document that may help with your queries; http://www.oracle.com/technology/deploy/security/oracle9ir2/pdf/VPD9ir2twp.pdf
If you scroll down to the section "Additional VPD Capabilities" and read the following sub-topics, this might enable you to base your Discoverer reports on views that contain VPD policies.
I trust "My Positive Comment" may help!!
Merry Christmas
Si ;-)
P.s This also may come in handy if running 10g http://www.stanford.edu/dept/itss/docs/oracle/10g/network.101/b10773/apdvpoli.htm
Message was edited by:
Simon Pittaway

VPD policies

Similar Messages

Maybe you are looking for