Business Objects Administration – Security Rights migration from SAP BO 3.x and BI 4.x

Hi Readers,

In this blog we are going to see the security rights migration from SAP BO 3.x and BI 4.x and the challenges we could encounter while doing BO content migration from 3.x to 4.x.

This post describes security settings as they correspond to the new interface and functions. The structure of the interface has been redesigned and security settings changed in certain cases. This means that some 3.x security settings are not directly compatible with the new interface. Where equivalents exist, these are used.

This document will guide you in the changes you might need to make when migrating content from 3.x to 4.x. Certain rights have been renamed, others are unaffected, and some rights are not supported in 4.x, and will require unsetting before resaving and migrating those reports.

Below are some of the known general Issues.

• Rights are not supported in 4.x and exist in 3.x
• Rights that are renamed in 4.x and exist in 3.x

Let us see each case in detail.

• Rights are not supported in 4.x

The typical example for this category would be Desktop intelligence application and redesign of      BI launch pad interface.

• Desktop intelligence

As Desktop Intelligence is removed in 4.x all the corresponding rights are not supported.

• Interface

In 3.x we are allowed to hide the toolbar based on the user rights. But in case of 4.x it is replaced by toolboxes in which we can disable the individual component.

Some of the rights come under this category:

Right	Migration status
Enable drill mode	No longer maintained in 4.x
Extend scope of analysis	No longer maintained in 4.x
Interactive: General – Ability to hide / show toolbars	Toolbar is replaced with toolbox
Enable HTML Report Panel	HTML viewer is removed in 4.x
Desktop Intelligence Application level rights	Desktop Intelligence Application is removed

How to resolve this?

We need to remove these rights in 3.x before migration so that they will not be migrated to the new version.

• Rights that are renamed in 4.x

The right “View SQL“in 3.x has been renamed to “Query Script – Enable Viewing” in 4.x.

Similarly below are some of the rights that belong to this category in my knowledge.

Rights in 3.x	Rights in 4.x
Create document	Documents – enable creation
Data Tracking: Enable for users	Data – enable data tracking
Data Tracking: Enable format display changes by users	Data – enable formatting of changed data
Edit SQL	Query script – enable editing (SQL , MDX…)
Enable Auto save for this user	Documents – enable auto save
Enable formula and variable creation	Reporting – create formulas and variables
Enable Java Report Panel	Interfaces – enable Rich Internet Application
Enable Publish and Manage Document Content for this user (did not exist)	Documents – enable publish and manage content as web service
Merge dimensions for synchronization	Reporting – enable merged dimensions
View SQL	Query script – enable viewing (SQL , MDX…)
Web Intelligence Rich Client : Save a document locally on the file system	Desktop interface – save documents locally
Web Intelligence Rich Client: Allow local data providers	Desktop Interface – enable local data providers
Web Intelligence Rich Client: Export a document	Desktop interface – export documents
Web Intelligence Rich Client: Import a document	Desktop interface – import documents
Web Intelligence Rich Client: Install from Info View	Desktop interface – install from BI launch pad
Web Intelligence Rich Client: Print a document	Desktop interface – print documents
Web Intelligence Rich Client: Remove document security	Desktop interface – remove document security
Web Intelligence Rich Client: Save a document for all users	Desktop interface – save document for all users
Web Intelligence Rich Client: Send by mail	Desktop interface – send by mail

How to overcome this?

We need to remap these rights in 4.x after migration by comparing them against 3.x rights.

• Special cases

The below rights are added in XI3 SP4 and are not included till 4.0.3.

i.    Import from BI On Demand

ii.   Export to BI On Demand

Resolution

SAP recommends not to migrate to XI 3.4 or later to BI 4.0.3.x or a previous release as some of the rights that are added in these versions are not replicated in till BI 4.0.3.x.

Hope the post was useful for those considering 4.x migration.

Thanks for reading.  Read More About  Business Objects Administration

BusinessObjects Administration – Custom Access Levels

Hi BOOglers,

Another interesting feature in business objects, Custom access level is going to be the topic of discussion for this blog. Please note the custom access levels are introduced only from Business Objects 3.0 onwards.

As you all know Access levels are groups of rights that users frequently need. They allow administrators to set common security levels quickly and uniformly rather than individual rights to be set one by one. Business Objects comes with several predefined access levels. Beginning with View and ending with Full Control, each access level builds upon the rights granted by the previous level. We can also create and customize your own access levels. This will greatly reduce administrative and maintenance costs associated with security.

Predefined Access Levels

Below four are list of predefined access levels and associated list of right(s).

Access level	Description	Rights involved
View	If set on the folder level, a principal can view the folder, objects within the folder, and each object’s generated instances.		View objects View document instances
Schedule	A principal can generate instances by scheduling an object to run against a specified data source once or on a recurring basis. The principal can view, delete, and pause the scheduling of instances that they own.		View access level rights, plus: Schedule the document to run Print the report’s data Edit objects that the user owns
View On Demand	A principal can refresh data on demand against a data source.		Schedule access level rights, plus: Refresh the report’s data
Full Control	A principal has full administrative Control of the object.		All available rights

* Principle refer to User group or User

Access levels in CMC

Advanced rights

Icon	Rights option	Description
	Granted	The right is granted to a principal.
	Denied	The right is denied to a principal.
	Not Specified	The right is unspecified for a principal. By default, rights set to Not Specified are denied.
	Apply to Object	The right applies to the object. This option becomes available when you click Granted or Denied.
	Apply to Sub Object	The right applies to sub-objects. This option becomes available when you click Granted or Denied.

Custom Access Levels

Consider a situation in which an administrator must manage two groups, Marketing managers and Marketing employees. Both groups need to access ten reports in the Business Objects Enterprise system, but Marketing managers require more rights than marketing employees. The predefined access levels do not meet the needs of either group. Instead of adding groups to each report as principals and modifying their rights in ten different places, the administrator can create two new access levels, Marketing Managers and Marketing Employees. The administrator then adds both groups as principals to the reports and assigns the groups their respective access levels. When rights need to be modified, the administrator can modify the access levels. Because the access levels apply to both groups across all ten reports, the rights those groups have to the reports are automatically updated.

We can create a new custom access level either start from the scratch or copy the existing access levels. We can also add/remove set of rights from existing custom access level from the existing custom access level.

Right Click on the Custom Access level and Select Included Rights.

And you will get the screen like below. Select the appropriate rights as per the requirement,

Then click OK to complete.

Finally you can assign the Custom Access level against each User group/User on a particular folder.

Administrator will get the best benefits out of this because they will get-rid of the traditional rights assignment using Advanced rights option. Also It is easy to manage the rights when they are grouped together.

Feel free to leave your comments. Thanks for reading! 

Read More About  Business Objects Administration

Business Objects Security

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.

Read More About  Business Objects Security