While there is widespread recognition of the value that dashboards generate, there is also an incipient apprehension that they are not secure. Walk through some ways you can validate the security in dashboards using Xcelsius as an example, while maintaining the user-friendliness that is expected in a dashboard.
Key Concept
Dashboards visually communicate information that is usually hidden in large data warehouses or operational and transactional data stores in transactional systems. The primary purpose of a dashboard is to provide the ability to draw quick and accurate conclusions that eventually translate into effective decision making.
One of the images that a dashboard conjures is that of a free-for-all — that everyone can access all the information on a dashboard. This is not true. You can ensure security in your dashboards. Here are some of the most common questions I hear on this topic:
- Is it true that everyone has access to dashboards?
- Can we restrict access to dashboards?
- Do we need to implement SAP BusinessObjects GRC solutions to provide access to the relevant users?
- How easy is it to administer security for dashboard users?
I’ll provide you with an understanding of security as it relates to dashboards by answering these and other questions. You can use numerous dashboarding applications within your SAP landscape, but I’ll use Xcelsius as an example because of its current prevalence in the SAP community.
Note
It is important to understand a bit of technology here. A compiled Xcelsius dashboard generates a file with the .swf extension. This file format works with Macromedia Flash Player and allows the dashboard file to be embedded in different media and generated from these media. As can be inferred, the only prerequisite for viewing dashboards off various media is the availability of Macromedia Flash Player in the system in which it is generated.
Security Implications of Publishing Dashboards
Dashboards are published in a variety of media. Given the kind of information that dashboards are designed to convey (such as financial key performance indicators [KPIs]), it is important that there is adequate security built around these dashboards. The good news is that you can control access to dashboards and it does not have to be a free-for-all. Let’s peek into some of the most common media to which Xcelsius dashboards are published and understand how you can build security.
Dashboards in SAP NetWeaver Portal
Publishing dashboards to SAP NetWeaver Portal is one of the most common ways that dashboards are made available to consumers across an enterprise. Because dashboards are starting to play an increasingly important role in organizations’ enterprise performance management (EPM) strategies, access to these dashboards is a critical consideration. Figure 1 shows an SAP NetWeaver Portal with embedded Xcelsius dashboards.

Figure 1
An Xcelsius dashboard in SAP NetWeaver Portal
When a dashboard is embedded in a portal, it becomes part of the portal’s content and therefore general security rules apply to the access to the portal and dashboard content:
- Authorization: Because a dashboard is part of the content available to users, you can regulate access to this content using role-based security. In other words, users have access to only those dashboards (or KPIs or content) that their role in the organization entails. They are likely to require two types of roles: a portals role (that controls access to various areas in the portal) and then a conventional back-end role that regulates access to the actual information. As an example, consider that you have access to a certain KPI on a dashboard and you want to drill down to the back-end SAP transaction system (such as SAP ERP Central Component 6.0) that contains the detailed information. Your back-end role determines if you have the authorization to do so and if so, what level of detail you can view.
- Authentication: You can do this in several ways and even within an enterprise, it is normal to have a mix of authentication mechanisms. One that has gained popularity in recent years is single sign-on (SSO). Basically, your user credentials are stored in a central repository and you need to sign on just once instead of individually to different systems and applications. If you are not authenticated as a portal user, you cannot access any dashboards.
Dashboards in PDF Documents
Embedding dashboards in PDF documents is another popular way of publishing dashboards. It is important to note that when you embed an Xcelsius dashboard in a PDF, it is treated as a regular PDF document. You can apply security to such dashboards using Adobe’s security framework for PDF documents. The following are the key security features that you can implement:
- Digital signatures
- Password protection that allows access to a dashboard document only upon providing the correct password
- Document encryption (based on security certificates) that identifies the user and controls whether the user can browse it
- Copying restriction
- Printing restriction
It is fairly easy to set up some of these basic features from the Adobe Reader main menu as you are publishing your dashboard. Figure 2 illustrates the starting point for this activity. Once you click Document, you see the relevant menu that contains the individual activities that enables you to add security to your dashboard.

Figure 2
Imparting security on dashboards embedded in PDFs
Dashboards in Microsoft Office Applications
Dashboards are often published to Microsoft Word documents or Microsoft PowerPoint slides, which are sent as email attachments. You cannot selectively apply security to dashboards (and their individual components) embedded in Microsoft Office documents. You can set up security for the entire document using permissions that restrict unauthorized users from forwarding, editing, and copying the file. To do that, you need to install a piece of Microsoft Windows software on your machine called Windows Rights Management. A component of this software is Information Rights Management. You need to use this feature to set up the permissions based on your requirements.
Pre-Building Security in Dashboards
At this time you must be wondering if it is possible to build some degree of security into Xcelsius dashboards when you are designing the dashboard. Of course, this is the responsibility of the dashboard developer and not the user. However, consider a scenario in which a basic dashboard (containing many components and KPIs) is sent out via email to a small number of users. The components each user should be able to access is known in advance, so it would be convenient if the dashboard developer could hide those components that the user should not be able to view. This is possible in Xcelsius, although you have to understand that is not one of its noteworthy features as compared to its flexibility and end-user focus. Its direct security offerings are minimal and the only way you can achieve some amount of security is by using a more indirect method.
The technique to achieve this is called dynamic visibility. Dynamic visibility lets you display or conceal a particular object or group of objects. Figure 3 shows the area you would do this in Xcelsius. When you design a dashboard, you have various components. Each component has a key. When you highlight a particular component in the designer screen and go to Attributes, you see a screen similar to the one shown in Figure 3. You then need to click the Behavior option. In this example, I deleted the key — there is nothing in the Key field. By deleting the key for that particular component, I have ensured that this component is no longer displayed. You can carry out a similar exercise with the rest of the components for each user and save each of these views as separate .swf files.

Figure 3
Controlling visibility to components
Note
See the following SAP Notes for more information:
- SAP Note 1375620: How is security handled at the Xcelsius application level?
- SAP Note 1206400: Flash file not visible in PowerPoint slide
- SAP Note 1358390: Xcelsius data does not display data when QAAWS does not have Full Control
- SAP Note 1357289: Export to PowerPoint 2007 does not write .ppt file or results in blank presentation
Anurag Barua
Anurag Barua is an independent SAP advisor. He has 23 years of experience in conceiving, designing, managing, and implementing complex software solutions, including more than 17 years of experience with SAP applications. He has been associated with several SAP implementations in various capacities. His core SAP competencies include FI and Controlling FI/CO, logistics, SAP BW, SAP BusinessObjects, Enterprise Performance Management, SAP Solution Manager, Governance, Risk, and Compliance (GRC), and project management. He is a frequent speaker at SAPinsider conferences and contributes to several publications. He holds a BS in computer science and an MBA in finance. He is a PMI-certified PMP, a Certified Scrum Master (CSM), and is ITIL V3F certified.
You may contact the author at Anurag.barua@gmail.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.