Column level versus row level security in SAP BI

This is a question. Sorry about the terminology clarification but it really does get to a question. Thanks for your patience and help.
There is some confusing terminology among BI users so let me explain terms. The terms appear to have some currency in the BOBJ world.
Row level security = the ability to control access to some data based on the values of a characteristic. Only the data authorized will be selected.
Column level security = the ability to exclude certain characteristics from display by any user.
In SAP BI row level security is managed by analysis authorizations (RSECADMIN).
To the extent of my experience (and I am unable to test it for about a month) column level security can only be managed by authorization object S_RS_IOBJ excluding the infoobject to be controlled with the sub-object DATA).
However my experience is that any query that reads an infoprovider that contains that infoobject will fail. It won't exclude and present to the user all the other infoobjects (i.e. columns).
Is this really so and if so is there any mechanism that can exclude columns without forcing the developer to either design an infoprovider or multicube that excludes the infoobject?
Edited by: Corwin Slack on Dec 14, 2009 2:07 PM

Two things
1. I would prefer not to have to rely on developers to implement a restriction in a query. Then I have to police every query.
2. I am not certain that the authorization isn't checked anyway because the query accesses the cube. (Sorry no test environment available until mid January)
My preference is that any queries that contain this authorization object just bypass the displaying the characteristic. My frecollection to date is that this isn't what happens. The query fails entirely.

Similar Messages

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 (VPD)

We are enhancing our corporate security model using VPD fine grain access to allow more flexible policies. This will provide different levels of row level access on each set of mart fact tables (Health Board level access on Mart A, GP Practice level on Mart B etc). We also want different column level security (masking) on common dimensions depending on which mart is being queried, e.g. a user might be allowed to see confidential patient columns when querying Mart A, but not on Mart B.
OID groups hold user attributes, and we can retrieve these via logon trigger and policy functions and then set user contexts accordingly.
When a query is submitted to the database (via Business Objects), it triggers the policy function on a particular mart fact table(s), which applies the particular row level constraint based upon the users context. So far so good. Problem is, when any dimension policy functions are being triggered (at the same time), they need to know which particular Mart is being queried, so that they can retrieve the correct user context to apply either confidential or non-confidential column masking.
I basically need a means of interrogating the SQL before (or as) it reaches the dimension policy functions, from which the function can identify the Mart from the named tables in the SQL FROM list. Is there a way of doing this, or some other mechanism entirely for delivering this level of access control?
One solution is to have a separate dimension view specific to each Mart. A particular view would join to a particular mart (in Business Objects), and the policy function amended for each. However we would rather avoid this as it could mean up to 20 + views for each dimension, and require a substantial maintenance overhead.
Thanks
Simon
Edinburgh

Why would you want a situation where USER1 cannot see any of the data in the table but owns a procedure that allows him to update any row in the table? That would basically defeat the purpose of using VPD-- if USER1 can circumvent the VPD policy in this procedure, USER1 can circumvent the policy in any procedure and can create procedures that allow him to view and manipulate the data.
Can you provide a bit more background about what problem you're trying to solve? Why does USER1 need to own the procedure if USER1 isn't allowed to see any of the data? Are you trying to write a procedure that will apply the caller's VPD policy (i.e. when USER2 calls the procedure, he can only update the rows that his VPD policy allows him to see)? Or do you want the procedure code to bypass the VPD policy entirely? Why are you fine with granting USER2 the ability to bypass the VPD policy but you are not OK granting USER1 that same privilege?
Justin

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.

High level and low level grabs

Hi, I'm looking at different acquisition options. Fast acquisition is a priority as is fast processing. I'm a little confused on high level versus low level. Is there any benefit to which one is used? Or is it 6 one way and 1/2 a dozen the other. Thanks

If you feel comfortable using the Low Level functions I would personally recommend using them instead of the High Level. Bruce's answer is correct, high level will call low level with standard options selected. If you think of ways to improve the speed of your code, you may want to use low level, my reason is because high level VIs will actually be a function call calling other functions, which introduces a minimum delay, instead, if you use low level you are directly calling the functions for acquisition so there is kind of a small time saving if you think of it as acquisition wise.
Also, the high level VIs if you check their block diagram it has more structures for error checking, session ID checking, etc., so with low level you have direct control over the acquisitio
n from your main program without introducing innecessary structures or functions.
Regards,
Nestor Sanchez
IMAQ/Motion Support
National Instruments
Nestor
National Instruments

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

Column masking row level security in Peoplesoft Databases

Hi
How about the credibility of using VPD( for column masking,row level security) in People soft Databases?where the sensitive data is redundant across 100's of tables.
My intention is to use the VPD across all the tables that contain the sensitive data ( ssn,bank accno, etc)
Appreciate your help.
Chelli

Hi.
I also have a trouble like yours,but mine is more simple.
I'd tried to solve,and find that it's really hard and must lost a lot of time to solve,because some table have 2,3 or more derive information that to use VPD is not easy.
Can i ask for any aspect to solve problem like this.
Thanks for any answer and support.
Thinhbk.

SAP-BO SSO and Row Level Security

Hi,
We can configure the SAP authentication and able to login InfoView via SAP user name and password. And also, we can import the roles from the SAP system.
When we create a connection to BW cubes from designer, we want to use "Use Single Sign On when refreshing reports at view time" to apply row-level security which is defined at the BW cubes.
In our tests, we use "Use BusinessObjects credential mapping" while creating connection from designer to test the row level security. As you can guess, after importing the SAP user, in CMC screen > Users and Groups > Users, we manually enter the password of the user to the Database credentials part. However, as you can guess, the password of the user's is not static and that is not a good solution.
My question is that, do I need to configure SSO between SAP and BO system or how can I enable row level security?
System Information
Business Objects XI 3.1
SAP Intg. Kit 3.1
Thanks a lot,
Omer

Hi Omer,
please note that only row-level security implemented through authorization variables in BW queries can be used in BusinessObjects. Row-level security defined at cube level will not be applied.
As long as you have used the SAP authentication to log on your BOBJ server, the SAP credentials will be used automatically to get the data from your SAP BW source as long as the "Use Single Sign On when refreshing reports at view time" option is selected in the Database configuration panel (Found in the CMC when viewing the properties of your report) and the option "Use BusinessObjects credential mapping" is selected in your universe connection.
Please note that this will only work for reports that are invoked directly in the infoview. If a user schedules such a report, she/he has to enter her/his SAP credentials explicitely in the Database Configuration Panel appearing in the scheduling assistant window. In this case you can activate SNC trust between your two servers in order to avoid entering a password when the report is scheduled.
Regards,
Stratos
Edited by: Efstratios Karaivazoglou on May 5, 2009 10:16 AM
Edited by: Efstratios Karaivazoglou on May 5, 2009 10:23 AM

Row-level Security Filters applied to Columns and Tables only? no Areas?

Good day all,
Just quick question (obiee 10.3.3.2) - Is there a way to edit row-level security using Whole subject areas (instead of bringing in the individual Fact tables and applying filters by copying/pasting them).
Follow up question - if I have nested facts in presentation layer (ones preceding with "-" - do I specifically add them to conditions, or would they be inherited by only including parent fact)?
Thanks!
Message was edited by:
wildmight

I'm not sure how that would help; by using the Faculty_ID Session Variable I can identify the CRN and Term of all courses a faculty member is teaching. But I don't think that has to do with the problem I am having?

Row level security at universe design level

Hi,
I am creating a Universe layer on top of non SAP OLAP cube ( from MS Analysis Services 2005 ) .
My concern is that can we maintain the row level or data level security at universe design level or if i am using that universe in creation of WEBI report so is there any possiblity to maintain this security at WEBI level.
Regards,
Mishra Vibhav.

Thanks for the reply.
Much Appriciated.
My only concern is that i read in the Universe Designer developer guide that it does the row level security so can eloborate a bit about how we maintain at Universe level.
Warm Regrads,
Mishra Vibhav

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

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.

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

OBIEE Row-Level Security Inquiry

I had discussed a security requirement with one of our resources and it seems like a simple concept but for some reason I can’t think of simple way to implement in OBIEE.
If we have a fact table with a security column that has values which state what groups can see the data in that row (Multiple groups separated by semi-colons). The data in the row is layed out like this:
Group 1;Group 2;Group 3;Group 4
There is a user and group mapping table as well where if I pull a user (Say User1) the data in the column for their group assignments would look like:
Group 3;Group 10; Group 11
Since this user is in Group 3 they can see the values in that row of the fact table above (Because Group 3 appears in both).
Now I can run a session variable to get the user groups but how to then correlate to what rows they can see in that fact table is where I am stuck.
Can I solicit any suggestions?

They are various problems with your approach. To start with let's how OBIEE would like you to have the data:
State Sales
1 99
2 30
3 50
Then your user to group table should be like this:
User State
1 1
1 2
1 3
2 1
3 3
You would then do an row-wise Init Block to populate the GROUP variable. Then you simply do a filter in your BMM layer State = VALUEOF(NQ_SESSION.GROUP). Note that GROUP is that a list of groups so OBIEE will take care to convert this to SQL correctly. Now the way you have your data I don't think you can easily do row-level security. Basically what you need is to have your Group as dimension in your fact. What you have a is concatenated value which is useless. Also your user to group mapping table needs to be flat so you can do the row-wise init block. Hope it helps.

Column level versus row level security in SAP BI

Similar Messages

Maybe you are looking for