Restrict data based on role ?

Question

There are several levels in on organization structure - how would i implement security such that folks in the org. tree can seen only data at/below their levels.
ex;
CEO->VP->DIR->MGR->DEPT
The fact table carries dept only. So CEO should be able to see rollups at VP,DIR,MGR,DEPT levels. DIR should be able to see across all departments he manages.
What facilities does discoverer provide to handle this kind of a requirement.
The reports i have all need to present the same kind of information but the content should be based on the role.

Answer 1

http://download-west.oracle.com/docs/html/B13918_03/security2.htm#sthref1002
14.8.1 Introducing Virtual Private Databases, Single Sign-On, and Discoverer
The Oracle9i Release 1 (and later) Enterprise Edition database's powerful Virtual Private Database (VPD) feature enables you to define and implement custom security policies. Among other things, the VPD feature enables you to enforce fine-grained access control based upon attributes of a user's session information (referred to as application context). This VPD functionality is commonly employed as a way of controlling access to data using the currently logged-on user's Single Sign-On (SSO) identity. For more information about setting up a VPD, see Oracle9i Application Developer's Guide - Fundamentals.
If Discoverer has been configured to require SSO authentication, Discoverer can pass a Discoverer end-user's SSO user name to the database (as the CLIENT_IDENTIFIER attribute of the built-in application context USERENV). Providing a VPD policy based on SSO user names has been implemented in the database, the data returned to a Discoverer worksheet will be restricted to the data that the SSO user is authorized to access.
You can optionally add user-defined PL/SQL statements to both database LOGON (and subsequent) triggers and to a Discoverer trigger (eul_trigger$post_login) to use the SSO user name to further control the data that is returned. You can use the database and Discoverer triggers separately or in conjunction with each other.
14.8.2 Example showing how SSO user names can limit Discoverer data
The Discoverer manager at Acme Corp. does the following:
1.
Configures the Discoverer middle tier machines so that SSO authentication is necessary to access the Discoverer URLs.
2.
Creates a Discoverer public connection called 'Analysis', that has access to a workbook called 'Sales'.
3.
Creates a VPD policy against the base tables of the workbooks. The VPD policy determines the data that is returned, based on the value of a variable called 'CONTEXT1'.
4.
Creates a database LOGON trigger that sets variable CONTEXT1 to the value of the SSO user name (extracted from the application context information passed to the database by Discoverer).
The Sales workbook is used by two Discoverer users at ACME Corp., Fred Bloggs and Jane Smith. A typical workflow for these two users is shown below:
1.
User 'Fred.Bloggs' authenticates via SSO and accesses the top level Discoverer URL.
2.
Fred selects the public connection 'Analysis', and opens the workbook 'Sales'.
3.
Fred views the data in the default worksheet, and then logs out.
4.
User 'Jane.Smith' authenticates via SSO and accesses the top level Discoverer URL.
5.
Jane selects the public connection 'Analysis', and then opens workbook 'Sales'.
6.
Jane views the data in the default worksheet.
Jane sees different data to Fred, despite the identical database connection, workbook, worksheet and database query. The difference is determined by the VPD policy being based on SSO user identities.
FYI