Categories
- All Categories
- 15 Oracle Analytics Sharing Center
- 14 Oracle Analytics Lounge
- 211 Oracle Analytics News
- 41 Oracle Analytics Videos
- 15.7K Oracle Analytics Forums
- 6.1K Oracle Analytics Idea Labs
- Oracle Analytics User Groups
- 77 Oracle Analytics Trainings
- 14 Oracle Analytics Data Visualizations Challenge
- Find Partners
- For Partners
Security/Access Controls in HR Analytics

Hi,
We are going to start HR analytics implementation and before starting this we need to make sure and define security/access controls for the same to avoid any data confidentiality risk at later stage. Related to HR analytics implementation we have following access/privileges level questions:
1) We have a Business Analytics warehouse schema named "OBI_DW" and it has access to all warehouse tables including HR. We are a team of developers and using this schema to query warehouse tables from SQL Developer/TOAD client but now on wards we want to restrict HR related table access to particular developer responsible for HR related development and maintenance. Kindly suggest the way and possibility of this in Oracle BI Applications.
2) In BI apps metadata repository we have view data option on tables in physical layer and we are using single Business Analytics warehouse schema "OBI_DW" in physical layer of OOTB BI apps repository so we also want to know the possible security/access solution here so that only particular developer can view HR related data in BI apps metadata repository.
3) Similarly we have OOTB ETLs/Data stores in Oracle Data Integrator for BI apps and currently we are using a single Business Analytics warehouse database schema "OBI_DW". Please suggest how can we restrict access of HR related data stores and data here in ODI.
Note:-
We are using following versions:
OBIEE 11.1.1.9.3
Oracle Data warehouse DB 11.2.0.4
Oracle Source EBS database 11.2.0.4
Oracle BI apps 11.1.1.10.1
Oracle Data Integrator 11.1.1.9.0
Thanks
Asad Hussain
Answers
-
Same answer to all your questions:
You have to either move the HR content into an own database object in the RPD and use a different security on it like named users
OR
You can switch to a VPD concept in the source database itself and let the database do all the work with zero impact for you on the OBIEE side.
0 -
We are using single database schema for HR analytics and Procurement analytics contents. In oracle BI apps I don't think we can have a two repositories.
0 -
Who said anything about two repositories?! Why would there be a need for two repositories?
0 -
We have a OOTB Oracle BI apps RPD and If I move my HR related warehouse tables in a separate db schema then how can I handle this in single RPD to use multiple db schema/user while I have only one OOTB "Oracle Data Warehouse" having contents of HR Physical tables. In this Oracle Data Warehouse's connection pool I can use only one db user at a time.
I have highlighted the same in screen shot.
0 -
I doubt BI Applications supports using multiple schemas? I can see it causing all kinds of issues, particularly with ODI. Plus - good luck trying to get an SR raised against anything model related.
If your concern is that developers will be able to view data they shouldn't be able to on the database, then as Christian Berg suggested, I'd probably go down the route of securing the data on the table so the non-HR users either don't see the data or it is obfuscated. You can use things like dbms_redaction (Redacting Sensitive Data in Oracle 12c using Dbms_Redact - Beyond Blog ) on 12c to obfuscate sensitive information. You would need to be able to (securely) identify the difference between a "user" connection and a "system" connection to the database though - and only apply the policy to the former.
0 -
There is another option, which is to stop anyone getting the tables directly, and only allow access via ODI. You can have one person, or a set of people, who enter the passwords for the appropriate connections and grant access to the developers to use those models, without having access to the password. I believe you can designate in ODI who can work with HR tables and who can work with other sets of tables.
0