SAP BI Platform Security Best Practices: Access Rights and Custom Access Levels

This is the first in a series of blogs about security in the SAP BI Platform.

The SAP BI Platform comes with a set of five default access levels:

• View
• Schedule
• View on Demand
• Full Control (owner)
• Full Control

However, there are many situations where these either give too much access or not enough for a given situation. While it is possible to use an access level to assign security and then to add “advanced rights” on top of it, best practice is to create custom access levels to use when assigning security.

When designing custom access levels, it’s important to understand the different types of access rights that are available and how individual rights work.

Types of Access Rights

There are four major types of access rights:

• General rights apply to most or all of the objects in the BI Platform, although there are a couple, like “Change Preferences” or “Change user password” that are fairly limited in their scope. Probably the most used right in the General rights is “View object,”, because it applies to every object in the system.
• Content rights apply to folders and various types of reports and other documents. Many of these rights are the same as the General rights, but they apply only to one type of object and can override the General rights. These rights basically answer the question, “What can I see and work with?”
• Application rights apply to the various applications within the BI Platform. These include things like Web Intelligence, BI Launchpad, the IDT, etc. These rights are specific to the application they apply to and answer the question, “What can I do?”
• System rights come in two general types:
  • Data Access rights apply to various types of data connections and the ability to use universes to access data. They answer the question, “What data can I use?”
  • All other system rights apply to various system level objects like access levels, servers, profiles, etc.

Owner Rights

Each access right might have two versions – a “full” version that applies the right for every object to which it is applied and a “that the user owns” or “owner” version that applies the right only to objects which the user owns. If both the full version and the user owns/owner version are granted within a single access level, the user owns/owner version is redundant and doesn’t do anything because the full version of the right already includes access to the objects the user owns.

Assigning Rights

When adding rights to an access level, there are several columns on the screen

• The first column is the name of the right
• The green circle with a checkmark means “Granted”
• The red circle with an “x” means “Denied”
• The yellow triangle with a “?” means “Not Assigned”
• The single page means “Apply to this object”
• The two linked pages means “Apply to sub-objects”

Granted, Denied and Not Assigned are mutually exclusive for a right. Apply to this object and Apply to sub-objects can be used singly or as a pair.

Deleted, Granted, and Not Assigned

When a right is set to Denied, it will almost always override any other access.

When a right is set to Granted, it will be granted unless it is combined with something where the access is denied.

When a right is set to Not Assigned, it will be effectively denied unless it is combined with something where the access is granted and not denied.

For example, if the View Object right is assigned as shown in the table below:

If a user is a member of Group X and Y, the user will be able to see both folders.

If a user is a member of just Group Y, the user will only be able to see Folder A because access to Folder B has not been assigned.

If a user is a member of Group X and Z, the user will be able to see only Folder A because access to Folder B has been denied through membership in Group Z.

Another example occurred several years ago when a user posted a question to the SAP Community saying that he had set an advanced right to deny the Everyone user group access to view a specific folder, not understanding that the Administrator account is also a member of the Everyone group. The folder disappeared, but he couldn’t add a new folder with the same name because the folder was still in the system, even though no one could view it.

It is very important to remember that Denied will override Granted. Use denied very sparingly and with forethought to the consequences.

This Object vs. Sub-Objects

The last two columns specify how the right is applied.  “Apply to this object” means that the right assignment only applies to the object where it was assigned.  “Apply to sub-objects” means that the right assignment applies to the sub-objects of the object where it was assigned – such as the reports in a folder.

One example of how this can be used is with an access level we commonly configure with our clients.  The level is usually called “This Level Only”. The only right it contains is the General View Object right, which is granted and only “Apply to this object” is checked.  We use this access level to give the Everyone user group access to view the top level of Public Folders.  This means that everyone can access the Public Folders root folder, but not any of the sub-folders.  From here, user groups are granted access to specific folders inside the Public Folders.  If the Everyone user group was given access to view the top level folder and its sub-folders, many times the system administrator has to remember to set the group to “No Access” for any of the sub-folders where access is restricted.  It is much easier and makes more sense to grant access to specific folders instead of first removing access and then granting it to specific groups when a new folder is added to the system.  This access level can be used in other places as well.

Best Practices

There are several best practices around the configuration and use of access rights and Custom Access Levels.

• Avoid explicitly denying an access right because it can have unintended consequences. Instead, use “Not Assigned” to effectively deny access.
• Create access levels that contain only one type of rights plus applicable General rights. This means having separate access levels for Content, Application, and System rights.
• All access levels should have the General View Object right granted because users have to be able to view an object (connection, universe, application, folder, etc.) in order to be able to use it.
• Create two “Data” access levels. One that provides permissions for various connection types and universes so that the user can view/refresh reports and another that provides the additional rights to create queries so that users can create reports.  These access levels will be used to assign access to connections and universes only.
• Have a separate access level for each Application. For Webi, there might be two access levels – one that will allow users to view and refresh reports in the Webi application and another that will contain all of the view and refresh rights along with additional rights to create and modify reports.  There might be a third Webi access level that will provide users access to view, refresh, and work with filters or alerts in a report.
• For Content access levels, use the General rights when possible and avoid overriding the general rights that are available within each Content type’s rights.
• When assigning most types of access, use a custom access level instead of using “Advanced” security. Custom access levels are reusable and make it easier to understand what type of access is being granted.

With careful planning and awareness of how access rights work, it is possible to configure SAP BI Platform security in a way that is easy to understand and to maintain.

The next blog post in this series will discuss User Group configuration and assignment.

Visit Protiviti’s SAP consulting services page for more information on our solutions.

About the Author 

Dell Stinnett-Christy is a Senior Manager in Technology Consulting/BI.  She has been working with Crystal Reports for over 20 years and with SAP BusinessObjects (BOBJ) for 14 years, including time in industry prior to becoming a consultant.  She currently does BOBJ security reviews, custom application design and implementation using the Crystal and BOBJ APIs, and the occasional BOBJ install or upgrade.