Posted by Karthik Srinivasan
Comments (7)
December 10th, 2008

Dear Readers, Greetings!

In the current business scenario, securing the data and restricting the users from what rows and columns of data they can see and what rows and columns of data they cannot see is very important.  We can secure the rows of data by row level security. Some people call this as ‘Fine grained access control’.  We can secure the columns of data by column level security. This is popularly called in Business Objects as ‘Object level security’

ROW LEVEL SECURITY

There are various ways through which the row level security can be implemented in a Business Objects environment.

One way is by securing the datamart. In case of this approach, the datamart is secured – meaning the security policies and rules are written in the datamart. Technically, a security table can be created and maintained having the users / groups with corresponding access rights.  Security policies can have a logic to compare the active logged in user and security table. All the users accessing the datamart are provided access to their data only after executing the security policies. We can also embed the security policies and rules in a view. A good example for row level security is — Non-Managers cannot see the data of   co-workers however managers can see the data of his / her sub-ordinates. In Oracle (for example), we can create a non-manager and manager views with the security rule (<security_table.user> = “USER”). The security views are imported in the Business Objects ( BO) universe and the reports use these security views through the universe. The main ADVANTAGE of securing your datamart is that your security rules can also be used by many other BI tools ( Cognos, Microstrategy )  as the rules are built at the datamart and NOT at the Business Objects)

Second way is by building the security rules at the Business Objects. Here the security rules comparing the logged in user and security data can be written in a virtual table of your Business Objects. These virtual tables are nothing but the universe derived table. BO Reports use the derived table to access the datamart tables. Alternatively, we can also define security filters in a BO universe. The filters are called as condition / filter  objects in the BO universe world. With this approach, you can take the maximum ADVANTAGE of the BO features however the disadvantage is that when you are going to a different BI tool like Cognos you need to rewrite the business security rules in your new tool.

In case of the projects dealing with the migration of Peoplesoft transactional reporting to Business Objects analytical reporting. We can potentially reuse / import some security tables  and security policies from Peoplesoft into our analytical datamart. These reusable components can save time in building the secured datamart and reporting environment.

COLUMN LEVEL SECURITY

Like ‘Row level security’, we can implement the column level security either at the datamart or Business Objects. In the financial industry, the business users do not want their revenue amounts, social security number , tax id number and other sensitive columns to be shown to unauthorized users.  Given this instance, we can mask the sensitive columns by a restricted tag in the place of sensitive columns. Non-sensitive columns like first name , last name , gender , age can be left and shown as it is to the end business user. These logic can be technically implemented in the business objects universe derived table or datamart views using a decode / ‘if then else’ / case statements.

Alternatively , we can use the universe object restriction feature in the BO designer to define restriction on the universe objects. So whenever a business user tries to drag the restricted object from the universe , the restriction rules get invoked , authorization occurs and the object access is given to the end user if he / she is successfully authenticated to access that object.

I’m signing off this BO security blog for now. The contents are based on my knowledge and BO experience in various projects.  Thanks for reading.  Please share your thoughts on this blog. Also, please let me know your project experiences pertaining to row and column level security in Business Objects.

Comments (7)

Bikram Khadka - April 7th, 2010

Hi Karthik, I am wondering if you are aware of implementing the BO security (user ids/roles) in database level. We are thinking of implementing this new BO security where internal/external users will be figured out in BO level and then the rest of securities(ids/roles) will be based on information stored in database. So security will be handled based on Active Directory. Thanks in advance, b

Formax - January 20th, 2010

This post brings me back to the 'old days' when I was a software developer. I haven't thought about rows, columns or referential integrity in years!

Raju - December 3rd, 2009

Hi Karthik, Thanks for your valuable information, actually I am new to this kind of work, I requested you to pls send the document if you have so that I will start to implement the same. Thanks, Raju

Karthik Srinivasan - July 30th, 2009

Everyone, Thanks for reading my blog and sharing your thoughts. Hi Murali, I did not access the blog for sometimes, as I was tied up with my project deliverables. If you are still in need of the answer to the query you posted, here it is. To implement the security at the database level, we can create security tables having the users and groups with their corresponding access rights. Security views can be created having the logic to compare the active logged in user and the security table. Users sitting from the database have to access the data only through this security view. Security views can be inserted into Business Objects universe and the reports can access the data using the security views inserted into the Business Objects Universe. Thanks and regards, Karthik

Prabhakar - June 1st, 2009

This is really good Information. I too have used security tables and used in the reports to secure data based on field values (e.g. OrgID). Two Tables: UserID_UserGroup_Relationship This will say which user belongs to which user group (Sales, Finance etc.). UserGroup_OrgID_Relationship This table will restrict which user group can see which OrgID in the data mart table) In the report, join these two tables with BO user ID who is running the report and OrgID in the fact table. The user will only see the data for the OrgID he/she has accees to.

murali - May 27th, 2009

This article has been very informative and interesting , can you provide some more information on how the security is implemented in the datamart level and how that can be used in business objects. Thanks, murali

Industrial Shredders - January 12th, 2009

Identity theft has brought great tensions to the corporate world causing many companieslosses each year. Everyone is scared of their personal information not leaked out tosome strangers. Not only offices but individuals at home should also purchase onefor safety.

Comments are closed.