An Overview of Security Levels in the SAP BusinessObjects BI Platform 4.x
There are many security levels and layers in the SAP BusinessObjects BI platform 4.x to protect information confidentiality and to make sure that information is being accessed only by authorized users. Security starts from the log-in screen, which authenticates and authorizes end users. From there, you can make the security settings for the object-level, application-level, and data-level layers. Authentication checks the user’s credentials (user name and password) using one of the SAP BusinessObjects BI platform-supported authentication methods (e.g., Lightweight Directory Access Protocol [LDAP], Windows Active Directory (AD), and Enterprise [the user credentials are stored in the SAP BusinessObjects repository in the Enterprise method]), to make sure that the user is eligible to access the system. After this step is completed, the user is able to access the system and then the authorization process starts. In the authorization step, the system checks to make sure the user has sufficient privileges to perform specific actions or to access specific information in the system. There are two main interfaces (URLs) in the SAP BusinessObjects BI platform 4.x. The first one is the BI Launch Pad and the second is the CMC. In the scenario in this article, I show how to access the BI Launch Pad using this test user to examine the effect of the changes made. Then I show how to use the CMC interface to apply different security settings to a test user. The BI Launch Pad is the main end-user interface; from here, end users can access their reports, dashboards, and other BI documents based on their security profiles. From the BI Launch Pad, they can do the following:- Access Crystal Reports
- Access and create Web Intelligence reports
- Access dashboards created with SAP BusinessObjects Dashboards and SAP BusinessObjects Design Studio
- Access SAP Lumira visualizations
- Schedule reports to run on a specific date and time or for a specific period (daily, weekly, monthly, and so on)
- Manage users and groups.
- Manage folders, categories, and BI documents
- Manage Universes and connections
- Manage the SAP BusinessObjects server
- Monitor servers
- Migrate and promote objects between different SAP BusinessObjects environments
- Manage enterprise security, including object-level security, application-level security, access levels, and Universe access-level set up

(Note: The BI Launch Pad and the CMC URLs are typically the same, except the BI Launch Pad URL ends with BI and the CMC URL ends with CMC.)
Business Scenario
To help you to understand security levels in SAP BusinessObjects, let’s walk through the following business scenario. In this example, let’s say that you have a monthly sales-by-region report that is used to track regional sales as well as branch sales. For this report, let’s say that there are four different user groups with different access levels, as follows:- HR users – They should not have access to this report because it is not related to HR.
- Testing users – They should have access and be able to refresh the report, but they do not need to be able to use the drill-down functionality. They are just responsible for making sure that the report is working and can be refreshed.
- Finance department – They should have access to the report and they need to be able to use the drill-down functionality in Web Intelligence to drill down to the branch level.
- Regional managers – They should have access this report. They need to be able to drill down to the branch level, and each region manager should be able to see his or her own region’s performance. All region managers should use same Web Intelligence report (in this case, monthly sales by region), but the report only displays relevant region information based on the logged-in region manager’s credentials.
Object-Level Security Access
Different security levels can be assigned to BI end users and end-user groups to grant them access to BI documents, folders, and categories. There are five default (or predefined) access levels, which are outlined in Table 1.Access level | Rights |
No access | Sets object permissions to Not Specified. This can be overridden through inheritance. |
View only | End users/End-user groups can:
inside this folder or category.
but they can copy reports to their favorites or personal folders and edit them there End users/End-user groups cannot:
|
Schedule | Same rights as the view-only access level, but with
the following permissions and restrictions.
End users/End-user groups can:
send them to different destinations
|
View on demand | Same rights as the schedule-access level, but
with the following permissions/restrictions.
End users/End-user groups can:
End users/End-user groups cannot:
|
Full control | Same rights as the view-on-demand access level,
but with the following permissions/restrictions.
End users/End-user groups can:
|
Note the following:
- BusinessObjects administrators can create and customize their own access levels
- End users need to have the proper access level on the Universe and connections used in the BI document in order to refresh the report or dashboard
Application-Level Security Access
Object-level security controls which BI documents can be accessed by which user, but you may need to control end-user access to other features. For example, you may have two user groups (in this example, from above, the finance department (group 1) and testing users (group 2), both of which have view-on-demand access levels to a specific report. In this scenario, you want to allow the first group to drill down in Web Intelligence reports, but you want to prevent the second group from being able to do the same. To achieve this, you need to use the application-level security setting to create a customized application-level security to prevent assigned users and groups from using the drill-down functionality of Web Intelligence. This can be done for other features in other applications (e.g., Web Intelligence, Crystal Reports, BusinessObjects Dashboards, Design Studio dashboards, and Lumira visualizations), such as data tracking, conditional formatting, sorting, and ranking. For each application, there are a variety of different features for which access can be granted or restricted. Note that application-level security is applied regardless of which report or BI document is accessed by the testing users (group 2). By this, I mean that regardless of which report they are trying to access, testing users (in this example) are not able to access the drill-down functionality in Web Intelligence. Again, using my business case example, object-level security access is used to give the finance department access to the monthly-sales-by-region report. However, then application-level security access needs to be customized to allow those end users to use the drill-down functionality in Web Intelligence, which they have permission to use. This is because finance users need to reconcile summarized figures with the detailed ones. Testing users also have object-level security access to monthly-sales-by-region reports, but application-level security needs to be customized to prevent those users from using the drill-down functionality in Web Intelligence as they should not have permission to use this feature. This is because testing users are responsible for ensuring that reports are working properly, and not for actual figures or calculations.Data-Level Security Access
The final step is to fulfill the security requirements of the last group, the regional managers. In this step, you give them access to the monthly-sales-by-region report—but not to the complete report, just the display of specific, relevant regional data for each manager based on their region. This needs to be configured on the Universe level. There are two main approaches to implement security in a Universe:- Using the SAP Information Design Tool (IDT) security editor.
- Using enterprise database security tables, and configuring them in your Universe.
Security Best Practices
It is a good idea to get in the habit of creating a security matrix. A security matrix helps you to:- Keep track of your groups and users and their assigned rules and profiles.
- Optimize security profiles and rules creation by identifying the privileges intersection between different users and groups.
- Identify the impact of changing or modifying a specific security profile.
Security Matrix
A security matrix is a list (record) of the mapping between users and profiles and rules. I use security matrixes as my first step in defining what kind of rules will be created and to whom they should be assigned. This provides a single place to document and manage the security profiles. You can have just one security matrix mapping that shows the relationship between users and profiles, or you can create one with more details and break this relationship into two matrices. In this case, the first one could show the relationship between the users or groups and profiles (Table 2), while the second one could show the mapping between the profiles and the restriction rules (Table 3). (Table 2 is an example of a simple security matrix that shows the relationship between users and profiles.)
User/Profile |
Profile #1 |
Profile #2 |
Profile #3 |
Profile #4 |
HR users’ group |
X |
|||
Testing users’ group |
X |
|
||
Finance users’ group |
X |
|||
Regional managers |
X |
Security setting/Profile |
Profile #1 |
Profile #2 |
Profile #3 |
Profile #4 |
Monthly-sales-by-region report |
No access |
View on demand |
View on demand |
View on demand |
Drill down |
Yes |
No |
Yes |
Yes |
Row-level security |
No access |
All |
All |
Central for central regional manager; western for western regional manager, and so on. |
