28 Sep 2017 OBIEE Security Dashboard
As a reporting tool, OBIEE handles an organization’s critical data in the form of Reports and Dashboards. Considering the criticality of data, it is crucial to have robust security measures in place as part of the OBIEE implementation framework.
The roles and responsibilities of business users change frequently due to changes in their respective job roles or in their business’s organizational hierarchy. As part of maintaining data security, it is mandatory to review the entire access map for users across all catalogues and dashboards on a regular basis to ensure that there is no data leakage by any unauthorized user. This blog explains the idea of having a separate dashboard to accomplish this objective.
The following are benefits of having a separate security dashboard.
| • | Provides a 360-degree overview of user access to OBIEE catalogues and dashboards |
| • | Fetches complete access details of any particular business user |
| • | Fetches the list of catalogs, users and AD groups (If applicable) mapped to any application role |
1. Business Value
From the business point of view, it is crucial to have the user access control maintained meticulously. To achieve this, the auditors and business focal points for any subject area should review the entire access map of users across all catalogues and dashboard in their respective subject area on a regular basis to ensure there is no data leakage.
Below are some of the requirements from business focal points or auditors, in order to review security access in BI on a regular basis.
| • | List of users having access to any corporate dashboards like HR, Finance, Purchasing, Procurement etc |
| • | BI catalogs or data access for a given business user |
| • | List of users, catalogs or AD groups mapped to an application role |
OBIEE does not have any inbuilt solutions to fetch the above information on a regular basis. In order to retrieve this information, we will have to check the permissions granted to the required BI catalogs. A user can be granted access to BI catalogs through various means, such as by directly mapping to the catalog (not a good practice), by mapping the user directly to an application role that in turn is granted permission to access the catalog, or by adding the user to the AD group, which is mapped to an application role. There are even scenarios where an application role is mapped to another application role. In such cases, it is necessary to loop through application roles and extract the users granted access to the catalogs. In short, it becomes a tedious and time-consuming manual task when there are multiple catalogs involved.
This blog provides a high-level overview on consolidating this information in the form of a dashboard to help make security information easily accessible by both auditors and business focal points at any point in time.
2. Solution Overview
The following are the three levels where we can implement security in OBIEE:
| • | Object level – Deals with access restrictions to various OBIEE catalogues/objects for different application roles/ users |
| • | Data level (Row level) – At this level, users have access to reports, but they see different sets of data within these reports based on their authorization to view data |
| • | User Level Security – At this level, the goal of the authentication configuration is to get confirmation on the identity of the user based on the credentials provided |
To build a security dashboard we have to consolidate the security information from aforementioned levels into a data model for reporting. As part of data integration process, we have consolidated the information from Application Roles, Oracle BI Presentation catalogues and the active directory into a consolidated security master table. The final fact table for the data model fetches the data from the security master table. Below is the high level architecture of this solution.
Figure 1: Architecture of a BI Security Dashboard Project
As shown below in the dashboard, the ‘Dashboards’ tab comprises the first section of the security dashboard. This section provides access details from the dashboard(s) page perspective. Dashboards are grouped into different categories, enabling users to select the required dashboard category.
Figure 2: Dashboard Page of the Security Dashboard
The ‘Analysis’ tab provides access details related to standard reports created in BI. All standard reports, which are developed, based on business requirements and accessed by users for their job purpose, are kept in a separate folder – ‘Standard Reports’ in our environment. Under Standard reports folder, there are several sub-folders created for categorizing reports developed for respective subject areas. By clicking on any standard report, we can easily get the list of application roles mapped to it, along with the users mapped in those Application Roles.
Figure 3: Analysis Page of the Security Dashboard
The ‘Users’ tab provides access-related details for a particular user in BI. The dashboard prompt allows the selecting of a specific user whose BI access needs to be analysed. On selection, basic user details are displayed, like their name, organization, location, employment type, job title etc.
Figure 4: Page of the Security Dashboard
Conclusion
The Security Dashboard project is one of the best solutions for providing a comprehensive overview of user access in OBIEE. Its implementation promises to ease the task of maintaining data security in any organization.
If you liked our solution stay tuned, in our next article, we will show how to extract this data from Active directory. Meanwhile you can always contact us if you want to know more about the Security Dashboard project.
