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

Similar Messages

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 in OBIEE 11g

Hi guys,
We have a business intelligence project in OBIEE, and I have a question regarding row level security (RLS).
Specifically, I have an hierarchical organization with users belonging to different structures. If one user belongs
to a structure that is above another structure in hierarchy, then he should see both data from his structure and
the of the users in structures bellow it. In the reports, we must have filters implemented respecting this requirement,
i.e. if one logs in OBI and accesses the report, he should see in the filter "Users" only subordinate users and respectively
data displayed in the report should be filtered accordingly. How would you suggest to implements this type of security
in the data model? And how could I create the type of filter mentioned above?

This needs to be implemented in 3 different levels. 1. in database 2. in RPD 3 in reports
1. You need to have facts or dimensions which have columns through which you can filter based on their hierarchy. e.g position in an organisation or department in the hierarchy table which can be joined to fact.
2. In rpd you need to create a session variable and initialize it using init block based on the user who is logging in. This variable will be you position or department through which you want to filter based on hierarchy. e.g select position from hierarchy_table where user= 'NQSession(user)' . The resulting position value will be used as a filter.
3. Add this position variable as a content filter in your LTS in you BMM layer.
4. You can also use this session variable as a filter in you reports too.
hope this helps.
Senthil

Sequence in parent and row level security

Hi,
I have a column with "seq in parent" for the "autogen type" property in Designer.
I also have row level security (RLS) (or fine grained access control) on this column's table.
Since there are data that could not be seen because of the RLS and the sequence is "seq in parent", i get the error :
ORA-00001: unique constraint (string.string) violated
Cause: An UPDATE or INSERT statement attempted to insert a duplicate key.
Example : User A inserts a row and the sequence is 1. User B who cannot see the row inserted by A, inserts its own row. The sequence inserted by B also gets 1 instead of 2 (because he cannot see the existing sequence 1). The sequence is duplicated, hence the error.
Is there a turnaround for this ?
Thank you.

You could consider using a 'real' sequence instead of seq-in-parent. I think seq-in-parent is using something like 'SELECT MAX(seq) FROM'... and that could also fail (depending on the moment this statement is issued) when 2 users are inserting a record.
HTH
Roel

Row-level security at the Database level

We need Row-level security at the Database level, where the user who logs in to Crystal reports, should be able to fetch only those rows from the database that he is entitled to see. For this, the login name of the user is passed to a stored procedure which sets the context of the DB session and restricts the data retrieved.
We are not looking for row-level security where the data is first retrieved and then filtered based on the user login name. However, we are definitely looking for a way to set a context for a database session based on the user login name, even before we start fetching data. So effectively, the user who logs in will fetch only those rows which he is supposed to see.
Issue:
We face a problem of not being able to pass a variable (something like 'BOUSER' for BO which works, whereas, 'CurrentCEUserName' for Crystal Reports, which doesn't work), to the database stored procedure to set the context.
Please let us know if we can use 'CurrentCEUserName' variable in Crystal in the same way as 'BOUSER' is used in ConnectInit for BO? We would like to know how we could pass any variable in Crystal Reports which holds the user login information to a stored procedure.
Also, please suggest alternate ways to achieve this security restriction, if any.

Hi
A previous database had a personnel table with their station name, district and region, with a field holding their logon name. We also had an activity table with the fields referring to the activity, and a field of Station, district and region it occured in.
By linking the individual rows in an activity table to the personnel table on the station name field, we then used the CurrentCEUserName to filter on the personnel. This returned only the records in the activity table where the station the activity took place at was the same as the station associated with the selected personnel who has logged on.
The additional bonus was if we linked it on District or region we had the same result but at a greater level. ie all activity in the logged on personell's District or if linked on region, then their region.
The personnel table was maintained by the system administrators, so maintenance was low.
I hope this helps.
Kevin

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..

Row Level Security using BO SDK - Dynamic Group and Criteria (where clauses)

To the Universe Gurus out there:
I have a rather daunting task of implementing a Row Level Security on a number of tables within our project using BO XI R2 SP2 with SQLServer 2005. Given the nature of the requirements around this (listed below), I am going to go with BO SDK to accomplish the creation of Restrictions. That said, I need some insight into some of the problem areas I have listed below. Any help is much appreciated.
Background:
We have 11 tables that are to be restricted.
Each table is accessible to potentially 1..* group of users only.
For eg SALES is accessible to ALL_SALES members only.
Each row within each table is accessible to 1..* groups of users only. The restriction will occur on 2 columns Jurisdiction and LineID on SALES table.
For eg
1)Rows with NY Jurisdiction and LineID=123 are accessible to NY_SALES_ADMIN group only initially.
2)NY_ADMIN will then approve that the above rows be open to NY_SALES_INTERNAL group only. This approval in turn will call upon the BO SDK to add a new restriction for the group with appropriate where clause.
3)At a later point, the above rows will be opened to NY_SALES_EXTERNAL group also.
This same concept holds good a number of jurisdiction (more or less static) and a dynamic number of LineIDs. So, if 10000 rows of data corresponding to new LineID 999 and Jurisdiction AK are in the table now, they are initially accessible only to AK_SALES_ADMIN group only. No one else should be able to access it.
Results:
1) With the way I laid out the business rules above, I am ending up with 528 groups.
2) There is a restriction created for a unique combination of Jurisdiction and LineID for each table.
Problems/Questions:
How can I restrict access to the new rows to one group only. I know that I can let a certain group only look at certain data but how can I restrict that all others cannot look at the same.
AK_SALES_ADMIN can look at LineID=999 and Jurisdiction='AK'.
Do I use an Everyone group based restriction? If so, my Everyone group will end up with tons of restrictions. How will they be resolved in terms of priority.
Am I even thinking of this the right way or is there a more noble way to do this?
Regards

the connectinit setting should look something like this:
declare a date; begin vpd_setup('@VARIABLE('BOUSER')'); Commit; end;
The vpd_setup procedure (in Oracle) should look like this:
CREATE OR REPLACE procedure vpd_setup (p_user varchar)IS
BEGIN
DBMS_SESSION.set_vpd( 'SESSION_VALUES', 'USERID', p_user );
END vpd_setup;
Then you can retrieve the value of the context variable in your vpd functions
and set the vpd.

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 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

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

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

Row level security in Hyperion System 9 - 9.3.1

Hi Gurus,
I have a requirement where the users get to see records in a table based on their localization code. This is currently implemented using views.
The view has a set of conditions which checks the localization table with te employee table. For example, if any of the first manager, second manager etc.. localization code
matches then they get to see records for that location.
The RLS in Hyperion uses Groups to assign security rules. But in my case, the determination is dynamic based on the localization code. And these things change depending on employee movement, transfer, promotion etc..
In such a scenario, can I use RLS only if I know a set Groups of users and where they belong to? Can RLS accomodate my above said requirement?
z

Follow the steps in the following link to set up OID and Row level security:
http://www.rittmanmead.com/2007/05/21/using-initialization-blocks-with-ldap-and-database-queries-to-control-authentication-and-authorization/
Instructions for the link above:
1.In place of Edit Data Source as database you have to select LDAP,define the groups and default initializer as filter expression.
2.A more simpler approach ,is to create the groups explicitely using the Security Manager in BI Administrator, add filters to those groups, and assign users to those groups.
Otherwise follow Matt's view
Thanks,
Amrita

How to implement row level security?

Hi all,
There is a database which is for 3 companies to use it and how to use row level security to make sure that they can only manipluate their own data? For example, "employee" table, for each company they just can see their own employees information. How to use dynamic view to do it?
Many Thanks
Amy

Here are two options to achieve what you want.
A. You can do this by coding, that's if you are ready to. Are you? If yes then try the steps below:
1. create a security codes table. Say for example
001 - company a
002 - company b
2. create a security table that will list all users and which company they should have access to. You can also implement this by roles.
3. alter all tables in the application schema to add a security code column. This will be a foreign key reference to table created in 1 above.
4. update all data in the tables according to which company they belong to.
5. write a procedure or package that does a validity check whenever a user requests for data. This procedure/package determines which company data the user has access/rights to.
With this, you should be able to achieve what you want if you do not want to spend on VPD and FGAC. The problem comes where there are users who would have cross access to data from both companies. In this regard, then you have to modify your security table a little bit to handle this.
B. This option i will admit is not so clean. You can also achieve this by two different views for every table in the application schema. And on each of these views, create a private synonym for every user. For illustration purposes:
Table name = Employee.
Create a view employee_a on employee
create a view employee_b on employee
Let's say you have users x and y. X has access to employees of company a and y has access to employees of company b. You can now create private synonyms for each of these users as follows:
create synonym employee on employee_a in x schema.
create synonym employee on employee_b on y schema.
This i have not tried but believe should work.
Hope one of these options serve your purpose.

Parent-child hierarcy - row level security

Hi,
Im using OBI 11.1.1.5 and have a problem about row-level security in parent-child dimension.
I have created a parent-child dimension, simlar to:
a1
--a1.1
----a1.1.1
----a1.1.2
--a1.2
----a1.2.1
By using a session variable 'SESVAR1', I want to restrict the visible hierarcy. For instance user 'a1.1' should only see:
a1.1
--a1.1.1
--a1.1.2
To do this I created a parent-child closure table with the whole dataset. Then I created a physical table using select statement with my session variable in repository. Whenever I viewed data in repository, it showed the correct set.
I created a parent-child dimension, using the original parent-child closure table. But since current distance values are different from the original hierarcy, I can not managed to build a security such a security system with this method.
How can I build a security system, that a member can only see its child hierarchy only?
Thanks for answers and links...
Edited by: user4516917 on 16.Nis.2012 06:54
Edited by: user4516917 on 16.Nis.2012 06:55

According to searches I made in support.oracle and google, it seems that it is not possible to view just a branch of a parent-child tree. Because the closure table is static. Therefore, you can not change the distances of objects dynamically.
This parent-child ability is very frustrating for me. As I understand, parent-child dimension ability can only be used in read-only sources. Any filtering or dynamic changes does not seem possible in this structure. Any changes on parent-child table requires parent-child relation table to be rebuilt.
I couldnt find any functionality of indexcol or choose functions in parent-child dimensions. I think they can only be used in level based dimensions.
Any comments appriciated..

Row Level Security in OBIEE using OID as authentication Mechanism

Hi OBIEE Gurus,
I am trying to implement Row Level Security in OBIEE . Currently I have setup OBIEE to have OID do the user authentication.
I want to implement RLS by doing the following :
1. Have Security Groups defined in OID and assign users with group membership.
2. Import these Security Groups into OBIEE metadata
3. Apply filters to these Security Groups
4. Run Answers requests to see if RLS works or not
Please let me know if this approach works. If this is not the right way or most efficient way to do this, please let me know if there is any document I can follow to accomplish this.
Appreciate your help.
Edited by: drakesh on Sep 26, 2008 7:09 AM

Follow the steps in the following link to set up OID and Row level security:
http://www.rittmanmead.com/2007/05/21/using-initialization-blocks-with-ldap-and-database-queries-to-control-authentication-and-authorization/
Instructions for the link above:
1.In place of Edit Data Source as database you have to select LDAP,define the groups and default initializer as filter expression.
2.A more simpler approach ,is to create the groups explicitely using the Security Manager in BI Administrator, add filters to those groups, and assign users to those groups.
Otherwise follow Matt's view
Thanks,
Amrita

Dynamically creating policies for Row-level security (RLS)

Similar Messages

Maybe you are looking for