Row level Security for BI Author Role

Hi All,
We are using OBIEE 11.1.1.5 in our project. We have a requirement where we need to configure row level security on certain column.
We are currently using external table and session variable approach to configure this. This security works fine for the users with BI Consumer
roles. But we are facing issue with configuring row level security for BI Author role.
BI Author can create any analysis in BI Answers and suppose he/she creates a report which does not contain the column on which row level
security is applied than he can see all the data. For eg.
We have one dimension Products having two levels Product Division and Brand. I want to configure security based on Product Division column.
But if BI Author create a report with only Brand and Measures than row level security is not working.
Does anyone has face this issue before.
Please let me know if you want any other information from my side.
Regards,
Vikas

If you are using a multidimensional cube you can use the "permit" command to control access to dimension members or provide cell level security within the cube. The OLAP database documentation provides on how to use the PERMIT command.
If you are using relational tables and/or views with additional CWM metadata mapped using OEM then you need to refer to the database documentation relating to Virtual Private Databases and Label Security
Business Intelligence Beans Product Management Team
Oracle Corporation

Similar Messages

Row Level Security for INSERT's

Hello there,
I implemented security-policies for the actions SELECT, UPDATE, DELETE and INSERT. All policies work well with exemption to the INSERT-policy. My question is:
How does the dynamic predicate work for INSERT-actions?
As far as I learned, a command like "SELECT ... FROM ..." is extended by a "WHERE " + predicate (from policy). But does this work with INSERT? I mean does something like "INSERT INTO Testtable VALUES(....)" + "WHERE " + predicate work? Am I constructing my predicate wrong or does RLS not work in this case?
Regards
Philipp Pott

Ok, I found the answer myself:
for INSERT's and UPDATE's the "update_check"-option of the DBMS_RLS.ADD_POLICY procedure (see PL/SQL Supplied Packages Reference, 61-5) is applicable. Setting this value to TRUE will let the server run the policy also after the insert.
With running the policy after the insert suddenly my routine worked and now rejects (prohibited) inserts with error ORA-28115 "Policy with check option violation".
Unfortunately this is not mentioned or shown by an example in the Oracle documentation. I found an example in the security-corner (http://otn.oracle.com/sample_code/deploy/security/9i_security.html) and some text in a technical white-paper (http://otn.oracle.com/deploy/security/oracle9iR2/pdf/VPD9ir2twp.pdf).
Huhh, on to the next steps / problems ..
Regards
Philipp

How to check the row level security in TOAD for oracle

Hi ,
for ex, i have 2 types of users
normal user and super user
super user can see the group set (some column name) created by normal user
but normal user can not see the set created by super user
this set crestion aslso has 3 types "U','P',S'
P & S can be viewed by even normal user
but U should not
so here we are having some row level security for the normal user .....
So, in TOAD for oracle how to check that......
Let me know if i'm not clear

Like
I'm the super user....
And some records are inserted to a table by different users ('a' , 'b', etc....)
So,if user 'a' logins then he can be able to see only the records inserted by 'a' only...
how to see in TOAD where such type of scripts (filter conditions) are written.....

Row level Security in obiee11g

Hello
I am trying to implement Row Level security for some 10,000 users based on the Cost Centers which are about 30,000. I know how to implement the data level security using groups an dapplication roles and creating security filters on those groups.
But There are two issues I am facing :
1. The no. of cost centers are huge i.e 30,000 . So creating these many groups doesn't seem feasible. Any other approach.
2. Cost center has got level based hierarchies having 20 levels and is a ragged hierarchy. There are some users who have access to Parent level node and there are some having access to child level cost centers. What I believed that for users having access to Parent level , I can assign all the child level cost centers and teh security will rollup to provide access to the Parent node (like you have access to California and Florida so automatically you get access to US (Cal + Flo).
But the issue is there could be one user who will have access to the TOp level so I will have to assign all teh cost center (30,000) so that he can get access to the Total Cost Centers. There could be other Managers who will have respective Parent Cost center access leading to assigning them to say 5000 - 10000 cost centers. My fact conatins the leaf level cost centers.
Is there a better approach to handle this.

Hi,
You can try to model your security requirement similar to Position-Based Security in OBIA .
Check *7.5.1 Primary Position based Security*
http://docs.oracle.com/cd/E10783_01/doc/bi.79/e10742/security.htm
Thanks

SAP Lumira - Implementing row level security

Hi All,
I aware that SAP Lumira 1.17 onward allows to share the datasets, stories to SAP Lumira Server as well as SAP BI Platform (4.1 SP3 onward).
But I would like to know if there is any way of implementing Row level security for this published contents i.e. datasets or stories. e.g. If user A (may be an administrator with access to all the regions) creates dataset and story and shares it with other users over SAP Lumira Server or SAP BI Platform. But when user B accesses these contents on any platform, SAP Lumira server or SAP BI Platform, he should be able to see data only as per his access (his own region). Can something of this sort be implemented?
Thanks,
Abhijit

Hi,
Sorry for the delay in getting back to you.
As per my understanding - as of today, we respect Row-level security when acquiring (fetching) the data from universe into Lumira desktop (also, contexts and business-security profiles i.e. columns)
now, when that desktop user has 'designed' the Lumira document, all of the above: row-level, contexts and security profiles are 'locked-down' into that artefact when shared onwards. (i.e. to Lum Server and hence, BI Platform)
once this content is being access from the BI Launchpad, refresh-on-demand is possible from the story, as well as scheduling of dataset on which it is based.
According this blog by Greg Wcislo (the product owner for the Add-on) Lumira integration for BI4 functionality detailed. note that features such as 'refresh on open' and 'changing design-time parameters' (i.e. prompts) are not yet supported, but very much in future scope / plans.
I believe that one of the other mid-term goals is to architect a 'Lumira server-side universe refresh' (i.e. so that the processing is handled 100% by Lumira server) rather than querying across BIPlatform services then replicating a dataset to HANA (which is currently the process flow)
I hope this helps.
Regards,
H

Row-level security problem using VPD

Hi all,
I've implemented row-level security for my application using the following procedure:
1) Created a procedure for setting the context for the application:
PROCEDURE set_empno
IS
emp_id NUMBER;
BEGIN
BEGIN
SELECT empno
INTO emp_id
FROM SCOTT.EMP
WHERE upper(ename) = SYS_CONTEXT('USERENV', 'SESSION_USER');
DBMS_SESSION.SET_CONTEXT('emp_sel_context', 'empno', emp_id);
EXCEPTION
WHEN OTHERS THEN emp_id := 0;
END;
END;
2) Created the application context:
CREATE CONTEXT emp_sel_context USING secman.app_security_context;
In which secman is my security schema and app_security_context is the name of above procedure package.
3) Created a function to access the application context:
FUNCTION emp_sec(E1 VARCHAR2, E2 VARCHAR2) RETURN VARCHAR2
IS
e_predicate VARCHAR2(2000);
BEGIN
e_predicate := 'empno = SYS_CONTEXT(''emp_sel_context'', ''empno'')';
RETURN e_predicate;
END;
END;
4) Created a logon trigger:
CREATE OR REPLACE
TRIGGER INIT_CONTEXT AFTER
LOGON ON DATABASE
BEGIN
SECMAN.APP_SECURITY_CONTEXT.SET_EMPNO;
END;
5) Added a policy on scott.emp like this:
begin
dbms_rls.add_policy (
object_schema => 'SCOTT',
object_name => 'EMP',
policy_name => 'EMP_SEL_POLICY',
function_schema => 'SECMAN',
policy_function => 'EMP_SECURITY.EMP_SEC',
statement_types => 'SELECT',
update_check => TRUE
end;
My problem is that when a user queries the EMP table the above procedure does not work and 'no rows selected' is returned for each user that queries the table. Does anybody know which part of my procedure is wrong?
Any helps is really appreciated.
S/\EE|)

i,
I suggest:
create another table emp1(logon with scott),this table only include empno,ename,then insert a few record,then modify
procedure set_empno as
PROCEDURE set_empno
IS
emp_id NUMBER;
BEGIN
BEGIN
SELECT empno
INTO emp_id
FROM SCOTT.EMP1
WHERE upper(ename) = SYS_CONTEXT('USERENV', 'SESSION_USER');
DBMS_SESSION.SET_CONTEXT('emp_sel_context', 'empno', emp_id);
EXCEPTION
WHEN OTHERS THEN emp_id := 0;
END;
END;
certainly ,you should grant select on emp1 to the user who will be test.
lixinzhu
2007/09/17

Row-level security tied to a user account.

Bear with me, I'm not quite sure I know what I'm talking about.
Recently we migrated from BO 5.1.7 to BO XII r2 on Solaris. Under Bo 5.1.7 our Finance users tell me there was a way to attach row level security to the account itself. For example, Finance users could only access RU's which belonged to Finance. This there a way to recreate this global security level so that we don't have to do it on a case-by-case basis?
Thank you in advance.

You can specify row-level security for a User or UserGroup on a Universe via the Universe Designer in Tools -> Manage Security
But that would be per Universe, and not global to Enterprise.
Sincerely,
Ted Ueda

Row Level Security not working for SAP R/3

Hi Guys
We have an environment where the details are as mentioned below:
1. Crystal Reports are created using Open SQL driver to extract data from SAP R/3 using the SAP Integration Kit.
2. The SAP roles are imported in Business Objects CMC.
3. Crystal Reports are published on the Enterprise as well.
3. Authorization objects are created in SAP R/3 and added as required for the row level security as mentioned in the SAP Installation guide as well. The aim is when the user logs into the Infoview and refreshes the report he should only see data that he is meant to so through the authorization objects.The data security works very much fine when the reports are designed directly on the table but when the reports are built on the Business View it doesnt work hence the user is able to see all data.
Any help in this issue is greatly appreciated.
Thanks and Regards
Kamal

Hi,
In order for row level security to work for you using the OpenSql driver, you need to configure the Security Definition Editor on your SAP server. This is a server side tool which the Integration solution for SAP offers as a transport.
This tool defined which tables are to be restricted based on authorizations.
However since you are seeing the issue on reports based on Business Views, you need to identify whether the Business View is configured in such a way where the user refreshing the report is based on the user logging into Infoview. If the connection to your SAP server is always established with the same user when BV is used then you security definition is pointless.
You can confirm this by tracing your SAP server to identify what user is being used to logon to SAP to refresh the reports.
thanks
Mike

Row Level Security Not working for the ECC table.

Hi All,
We have created a crystal report using SQL Driver.
We have set the row level security on PA0001 table so that we can restrict the query based on Company Code.
But when I run the report, it bypasses the row level security and gives access.
Am I missing some configuration?

Hi Ingo,
Security is set up using /crystal/rls transaction. A custom auth object is used for checking the company code with a single field "BUKRS".
This custom auth object is maintained for the PA0001 table.
This object is added at the role level with the restricted access to the Company Code..

Suggestion required for using row level security

We have a scenario to provide row level security to some of the transaction tables like HR_EMPLOYEE which has a foreign key column DEPT_ID to HR_DEPARTMENTS table. This table may grow up to about 5 million records. There could be regular SELECT operations on this table and not so frequent UPDATES compared to the SELECT operation.
We were looking at the following approaches...
Table :
HR_EMPLOYEE
     EMPNO
     DEPT_ID
     LAST_NAME
     FIRST_NAME
1. Enable Oracle Label Security policy on this table and use static predicates.
In this approach we add the OLS policy column (POLICY_COLUMN) and add predicate to access data.
e.g. we will be giving access to global data by predicate like
OR POLICY_COLUMN =CHAR_TO_LABEL('POLICY_NAME','C::DEPT1')
where C::DEPT is the OLS Label
2. Using VPD policy. We donot add any column, instead use the existing column DEPT_ID to provide row label security. In this approach the DEPT_ID is to be compared against an additional table and DOMINATES function will be used to verify the permission for the user to access the data.
e.g. In this approach, the policy function is like
'DOMINATES(char_to_label(''POLICY_NAME'', SA_SESSION.LABEL(''POLICY_NAME''))
,char_to_label(''POLICY_NAME'', POLICY_PKG.GET_LABEL_FROM_DEPTID(DEPT_ID))) = 1'
The GET_LABEL_FROM_DEPTID function returns the OLS label for the corresponding department. This is compared with the user's session label and appropriate rows are given access.
Can someone suggest on which of the above approaches is more performance effective considering the number of records and the additional OLS column added to the table.

Hi there,
would you be able to describe as detailed as possible what you want to achieve? From my first glimpse at your code, it seems as if you are using both OLS and VPD in a rather extraordinary way.
Best, Peter

Dynamically creating policies for Row-level security (RLS)

Hi everybody,
I’m looking for suggestions on how to configure Row-level security (RLS).
I have a large number of tables (about 500) and about 100 database users. Each user must see a portion of the data, filtered on a specific field. The field used to filter the data is a Client Id (let’s assume for simplicity that this field is present in all tables and has the same name everywhere).
Some users must be able to see just one client, other users must be able to see a group of clients, and some other users must be able to see all the clients. The association between Users and Client Id’s is stored in separate database tables.
I’d like to avoid having to manually create a policy for each table, so I’m looking for a solution that makes use of pl/sql programs to create policies dynamically.
Has anybody already implemented anything similar? Can you share your approach? Of course I’m looking for the easiest / most robust / most flexible way to implement this.
Andrea

It sounds like you would want a single policy function and that you would then apply that policy function to all 500 tables (at least given the simplifying assumptions you make in your question). If your policy function simply returned the `WHERE` clause
client_id IN (
    SELECT client_id
      FROM table_mapping_user_to_client
     WHERE user_id = <<something that identifies the current user>> )Then you would simply apply that policy to all the tables
FOR x IN (SELECT * FROM dba_tables WHERE <<condition to find the 500 tables>>)
LOOP
dbms_rls.add_policy(
    x.owner,
    x.table_name,
    'Restrict by client_id', -- name of policy
    <<owner of function above>>,
    <<name of function above>> );
END LOOP;Justin

Row-Level Security announced for Azure SQL Database

The announcement:
Next generation of Azure SQL Database service in staged general availability; Row-Level Security in public preview
We’ve announced the general availability of the latest update to Azure SQL Database (V12). This service update is now generally available in the North Europe and West Europe datacenters, will be generally available across regions in the United States on February
9, 2015, and will be rolled out worldwide by March 1, 2015. General availability pricing will take effect for servers on V12 worldwide on April 1, 2015. This service update introduces near-complete SQL Server engine compatibility, greater support for larger
databases, and expanded Premium performance.
The description topic is at
http://msdn.microsoft.com/library/dn765131 Row-level filtering of data selected from a table is enacted through a security predicate filter defined as an inline table valued function. The function is then invoked and enforced by a security policy. Also
see the Transact-SQL topic CREATE SECURITY POLICY at
http://msdn.microsoft.com/library/dn765135
Rick Byham, Microsoft, SQL Server Books Online, Implies no warranty

Hi Rick,
Thanks for your information.
Thanks,
Lydia Zhang
Lydia Zhang
TechNet Community Support

[Security]   Row-level security in ADF

Hi all,
I want to implement row-level security in my application, the scenario is like this:
There are several users that connect to the application
These users are authenticated in some way (XML file, OID, DB)
When each user wants to access (Select, Update, Delete) an ADF Table, either updatable or read-only, a predefined 'where condition' based on that table and the operation the user wants to do, must be concatenated to his DML, transparent from the user.
So if for example a user queries the Emp Salary table only records with salary < 10K/Month will be fetched from the underlying table. This should be done automatically and not hard-coded in the application.
I have tried VPD and it has some useful features but my problems are:
1) Where and how to define the 'where conditions'?
2) How to attach the 'where conditions' to the executing DML?
3) What is the best way to make DB know which user is really executing DMLs? (Not a single Application Server admin user)
4) What is the best authentication approach?
Any helps will be really appreciated.
S/\EE|)

Hi,
yes you can. Database proxy user is setup in the prepare session method as well and EUS can be configured to take the J2EE username to then re-connect the app to teh database schema
    public void prepareSession(SessionData SessionData)
       super.prepareSession(SessionData);
       oconn = ((PrxyTransactionImpl)this.getDBTransaction()).getPrxyConnection();
       // Specify the user that connects through the proxy user and its roles
       Properties prop = new Properties();
       prop.put(OracleConnection.PROXY_USER_NAME,"hr");
       //prop.put(OracleConnection.PROXY_ROLES, roles);
       String appContext = "Begin ctxhrpckg.set_userinfo('"+getApplicationUserName()+"'); END;";
       java.sql.CallableStatement st= null;
      // Open the proxy session (DB-authenticated users)
      try
        oconn.openProxySession(OracleConnection.PROXYTYPE_USER_NAME, prop);
        st = getDBTransaction().createCallableStatement(appContext,0);
        st.execute();
      catch (SQLException e)
        e.printStackTrace();
package oracle.sample.dbprxy.adfbc;
import oracle.jbo.server.DBTransactionImpl2;
import oracle.jbo.server.DatabaseTransactionFactory;
* TransactionFactory that returns PrxTransactionImpl, which is a subclass of
* DBTransactionImpl2
* @author Frank Nimphius
public class PrxyDatabaseTransactionFactory extends DatabaseTransactionFactory
public PrxyDatabaseTransactionFactory()
    super();
   * Override the create method to return an instance of PrxyTransactionImpl instead
   * of DBTransactionImpl2
   * @return PrxyTransactionImpl
public DBTransactionImpl2 create()
    return new PrxyTransactionImpl();
package oracle.sample.dbprxy.adfbc;
import oracle.jbo.server.DBTransactionImpl2;
import oracle.jdbc.OracleConnection;
public class PrxyTransactionImpl
extends DBTransactionImpl2
public PrxyTransactionImpl()
    super();
   * The DBTransactionImpl2 does not expose the connection in a public
   * method. This class is a wrapper to expose the connection to the
   * BC app, so it can be accessed in the ApplicationModuleImpl class
   * @return OracleConnection - SQL Connection
public OracleConnection getPrxyConnection()
    return (OracleConnection) this.getJdbcConnection();
}Note that for EUS ApplicationModule pooling should be disabled
Frank

Obi 11g row level security not working

All,
I am very familiar and have worked with obi 10g row level security and it works pretty easily. Now in 11g not so easy. I am basically setting permissions on data filters on app roles as per the new 11g instructions and meta data guide, however, I never see the filters being applied in the report and also in the nqquery.log. I have tried in vain, and nothing. The filters are never being applied for the test user. I even verified the user is in the specified app role via their my account->app roles tab. Now has anyone had this experience or now is there something that must be done additionally now.
Very frustrated... ;(

Ok, so I have found the solution and ultimately the answer to why the object level and row level security was not being applied. It so happens that the app policy: 'resourceType=oracle.bi.server.permission, resourceName=oracle.bi.server.manageRepositories all' not only allows the management and access to online RPDs; but, IT ALSO DOES NOT APPLY SECURITY/PERMISSIONS IN THE RPD TO THAT USER thus you are super user. So the OOTB BIAdministrator app role which my AD user was being assigned never had any security applied due to this. How I tested:
1) I created a test user
2) Assigned that user to the BIAuthor app role and saw that they had the security applied that I was testing, which was simple object denial and row-level security to just one year on the date dim.
3) Since it was working, I then assigned that user to the BIAdministrator role. This produced that the test user now does not have any restrictions that I set and that were working before. Thus, security/perms in the RPD are not applied.
4). I removed the user from the BIAdministrator app role, kept in the BIAuthor app role and then created new test app role. I mapped that user to this new role along with the BIAuthor role. I then proceeded in creating new app policy with just that policy and assigning the new app role to it.
5) I logged into the presentation services again with this test user after assigning to new app role and policy. My test user again does not have the security being applied and does not get any perms/security that I set and applied in the RPD. On top of that my test user is now able to login in online mode to the rpd via the bi admin tool.

Row level security not working if I hit the aggregate

I have applied row level security on presentation layer , however it does not work if the report hit the aggregate any idea on this...

Hi Ingo,
Security is set up using /crystal/rls transaction. A custom auth object is used for checking the company code with a single field "BUKRS".
This custom auth object is maintained for the PA0001 table.
This object is added at the role level with the restricted access to the Company Code..

Row level Security for BI Author Role

Similar Messages

Maybe you are looking for