An Introduction to Security Implementations in the SAP BusinessObjects BI Platform

Security is one of the hottest topics in the IT domain. Any organization has its own information and services that should be governed through implementing enterprise-security models. This ensures that only allowed users have access to the right information, and maintains data confidentiality.

The SAP BusinessObjects BI platform 4.x has a complete, robust security model to facilitate security assignments on different levels. I start by explaining the different security levels available in the SAP BusinessObjects BI platform 4.x (object level, application level, and Universe level).

Configuring security on the object level allows you to control access to different objects stored in the SAP BusinessObjects BI repository, such as reports, dashboards, Universes, and so on. Configuring application-level security allows you to control which application features can be accessed by end users, such as edit, refresh, and drill-down. Configuring security profiles in the Universe enforces the implemented security rules on all BI artifacts and documents based on this Universe, such as Web Intelligence reports, Crystal Reports, dashboards, SAP BusinessObjects Lumia visualizations, SAP BusinessObjects Design Studio dashboards, and mobile BI documents (reports and dashboards).

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)

The first step is to access the BI Launch Pad using the following URL: https://<Server Name>:<Port Number>/BOE/BI. The server name is your SAP BusinessObjects server name or IP address, while the port number is the configured port (the default is 8080).

Using the CMC, you can do all the administration and BusinessObjects server configuration tasks, such as:

• 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

Next, access the CMC using this URL: https://<Server Name>:<Port Number>/BOE/CMC. A screenprint of the CMC interface is shown in Figure 1.

Figure 1

The landing page of the Central Management Console

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

1. HR users – They should not have access to this report because it is not related to HR. 
2. 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.
3. 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.
4. 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.

In the following section, I provide a brief overview of the different types of security-level access offered in SAP BusinessObjects BI platform 4.x and how they help build a security model to fulfill the above-outlined business case. (The Universe-security level details are covered in the second and third parts of my series of articles.)

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. 

Table 1
A brief overview of the five predefined security-access levels

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

For the business case in this scenario, object-level security can be used to fulfill the requirements related to HR users and testing users. In this example, I assign no-access rights (security level) to HR users to prevent them from accessing the monthly-sales-by-region report, and assign view-on-demand access to the testing users group to give them access to the monthly-sales-by-region report and the ability to refresh. Object-level security does not fulfill the access needs of the finance department and regional manager user groups. Something more advanced is required to give these users access: application-level security.

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.

Using data-level security level (also known as row-level security), you can apply some filtering mechanism that will be enforced based on the logged-in user. In this example, you can create two data-level access security profiles. The first one is to filter retrieved information and display only central-region-related data. This profile will be assigned to the central region manager. The second one filters only western-region information and will be assigned to the western regional manager. Both managers (central region and western region) have access to the reports, monthly-sales-by-region, but each sees only information related to his or her specific region. Data-level security detects the current logged-in user and assigns each manager the appropriate security profile to display the right information.

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

Table 2
Security matrix example 1 (users or groups with security profiles)

Table 3
Security matrix example 2 (security profiles with security settings)

You may notice that you can merge profiles #3 and #4 by creating another row-level security rule for the finance department that enables them to display all the regions’ information. As you can see, all the other security settings are the same for profiles #3 and #4. This is one of the main advantages of using a security matrix—it helps you to see the overall security picture and enables you to optimize your security assignments.