Dynamic Reporting With Role Based Security

Dynamic Reporting with Role based Security
Nature of Document: Tip or Technique Product(s): IBM Cognos BI Area of Interest: Security, Modeling, Reporting
Business Analytics
Copyright and Trademarks Licensed Materials - Property of IBM. Copyright IBM Corp. 2011 IBM, the IBM logo, and Cognos are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml While every attempt has been made to ensure that the information in this document is accurate and complete, some typographical errors or technical inaccuracies may exist. IBM does not accept responsibility for any kind of loss resulting from the use of information contained in this document. The information contained in this document is subject to change without notice. This document is maintained by the Best Practices, Product and Technology team. You can send comments, suggestions, and additions to cscogpp@ca.ibm.com. Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.
Business Analytics
Table of Contents
1 Introduction..............................................................................................................4
1.1 1.2 1.3 Purpose.....................................................................................................................4 Applicability...............................................................................................................5 Exclusions and Exceptions..........................................................................................5
2 IBM Cognos BI features for implementing Role based security.....................................6 3 Sample Case.............................................................................................................7 4 Steps to implement Role based security.....................................................................8
4.1 4.2 4.3 4.4 4.5 4.6 Implementation steps.................................................................................................8 Mapping OpenLDAP entry as IBM Cognos BI Session Parameters..................................8 Assigning OpenLDAP groups and users to Cognos Namespace groups and roles..........11 Create the Parameter Maps in Framework Manager....................................................11 Define Conditional Query Filters in Framework Manager.............................................13 Create Dynamic Reports in Report Studio..................................................................18
5 Appendix A: Resources............................................................................................24
Business Analytics
Introduction
1.1 Purpose
IBM Cognos BI is a business intelligence tool that enables creating and analyzing company wide reports, score cards and event notifications based on user request. IBM Cognos BI is built upon a single web based architecture. IBM Cognos BI allows all levels of users in a company to create reports or analyzing data easily via a web browser. In conjunction with Role based Security, IBM Cognos BI also offers dynamic reporting capability. Role based security is described as user-level security which focuses on the logical role of a user rather than the users individual identity. The IBM Cognos security model allows you to manage users as member of roles and groups. These groups and roles can be used in Security policies such as access permission for each object within the IBM Cognos portal. As shown in Figure 1, in traditional spreadsheet reporting we need to create different reports for each group and role whereas in IBM Cognos can simplify this process. since a single report format can provide different view for each groups and roles.
Figure 1: Comparison between the concept of traditional reporting (left) and that of Dynamic Reporting using IBM Cognos BI (right)
Dynamic Reporting has following advantages: Sharing company wide concept.

Reducing labor for maintaining and creating reports by sharing the same report format and data sources in many purposes. Increase data integrity. Simplify data source maintenance since each Reports does not store data themselves.
This document has been translated to English from the following DeveloperWorks article: http://www.ibm.com/developerworks/jp/data/library/cognos/j_d-openldap02/index.html
Business Analytics
Dynamic Reporting with Role based Security 1.2 Applicability

The technique outlined in this document was validated using IBM Cognos 8.4.1 BI and IBM Cognos BI version 10.
1.3 Exclusions and Exceptions

The example described in this document uses relatively small amounts of data. Using custom filters intensively might impact performance during report execution.
Business Analytics
IBM Cognos BI features for implementing Role based security
To create dynamic reports that implement Role based security we use the following IBM Cognos BI functionality. 1. Configuring a namespace In this document we set up OpenLDAP as our authentication provider and configure it as a namespace in IBM Cognos Configuration. 2. Security administration for groups and roles Groups and Roles are created in the OpenLDAP repository permissions/capabilities in the IBM Cognos Administration interface. 3. Parameter Mapping This feature is mainly used as a look up table when relationship mapping is needed between 2 items. In this example the function is used to map the account name in OpenLDAP and employee code in the data source. 4. Query Filter This is a filter applied against a Query Subject. In this example this is used for filtering the result based on the logged on user. 5. Dynamic filtering This feature allows data item expressions to change their displayed value based on a condition. In this case the current user's job types and/or roles. and assigned
Business Analytics
Sample Case
The examples described in this section were designed for the sample company Great Outdoors Co., Ltd. This sample is included in order to give a good explanation of the product features and best practices for both the business and technical side. Now we will explain the method of how to create dynamic reporting based on Role based security by using one of our sample packages, "Great Outdoors Warehouse". (Figure 2) Outline of the examples: 1. OpenLDAP is used as the directory server ( LDAP V3 compliant).

Employee (user)name and department are stored in the OpenLDAP repository. Accounts and groups of each department are stored in the OpenLDAP repository.
2. Salary data is stored in the reporting data sources. 3. Access to confidential human resources (HR) information is secured. 4. Six employees are part of the HR department in Asia Pacific. Of those six, the two senior executives have full access rights to HR and its confidential information. 5. Employees working in the HR department can access local HR information but confidential information, such as salary or bonus, will be secured. Only senior executives can access that information. 6. Employees outside the HR department only have access to their individual HR information.
Figure 2: Outline of sample case and IBM Cognos BI features used in this document.
Business Analytics
Steps to implement Role based security
4.1 Implementation steps

This section describes the practical steps on how to implement Role based security based on the example mentioned in the previous section. Its outline is listed below.
1. 2. 3. 4. 5.
Mapping OpenLDAP entry as IBM Cognos BI Session Parameters Assigning OpenLDAP groups and users to Cognos Namespace groups and roles Create the Parameter Maps in Framework Manager Define Conditional Query Filters in Framework Manager Create Dynamic Reports in Report Studio
4.2 Mapping OpenLDAP entry as IBM Cognos BI Session Parameters

By default OpenLDAP uses the inetorgperson.schema as a base for its user accounts. This schema lists departementNumber, employeeNumber and other entries as attributes for a user account object (Figure 3).
Figure 3: LDAP Browser : OpenLDAP Entry for user Daichi Tanaka
Business Analytics

In this example we create OpenLDAP entries that match the Great Outdoor Warehouse sample package. Under the Human Resources group, we create the Go Asia Pacific subgroup for the Asia Pacific's HR department members. This can be observed by looking at the uniqueMember attribute of this sub group. (Figure 4)
Figure 4: LDAP Browser : Member of Human Resources GO Asia Pacific Group
Before we are able to use OpenLDAP entries with IBM Cognos security, we need to set up the LDAP parameter mapping in IBM Cognos Configuration. Mapping user objects and group objects is done by setting the Account Mapping and Group Mapping on the LDAP Namespace as shown in Figure 5.
Business Analytics

In this example we are configuring the LDAP_NS Namespace. Based on the information (LDAP attributes used) from Figure 3 and Figure 4 we can match attributes as follows:
10
Figure 5 : Cognos Configuration : Namespace configuration
We can also define additional attribute mapping to the Custom Properties field. Figure 6 shows the custom attributes for departementNumber and employeeNumber which do not have an equivalent entry in the default LDAP Namespace.
Figure 6 : Cognos Configuration : Custom Properties for departementNumber and employeeNumber
Business Analytics
Dynamic Reporting with Role based Security 4.3 Assigning OpenLDAP groups and users to Cognos Namespace groups and roles
By default IBM Cognos provides a default Namespace called Cognos with predefined groups and roles. To simplify security administration tasks we can use these default groups and roles by associating them with users and groups from the OpenLDAP Namespace. You can easily add OpenLDAP users and groups to Cognos groups and roles using IBM Cognos Administration. From the Users, Groups and Roles section under the Security tab you can manage the OpenLDAP and Cognos Namespace. When you add LDAP groups as members of roles or groups in the Cognos Namespace the members of the respective OpenLDAP groups will be added as members of the associated Cognos Namespaces groups or roles as well. In this example we add the Human Resources: Go Asia Pacific OpenLDAP group to Cognos Namespace role called Consumers (Figure 7).
11
Figure 7 : IBM Cognos Administration : Assigning OpenLDAP groups to a Cognos Namespace role
4.4 Create the Parameter Maps in Framework Manager

A Parameter Map is a collection of key-value pairs and is presented as a two column table which works like a look-up table. To make it function properly, a Parameter Map should have a unique key for every key-value pair. A Parameter Map cannot accept data containing a quotation mark in the value. By right-clicking the Parameter Maps entry in the Project Viewer pane you are presented with a context menu that allows you to create a Parameter Map. (Figure 8)
Business Analytics
12
Figure 8 : Framework Manager : Creating Parameter Map in Framework Manager
In the Parameter Map definition window (Figure 9), you can add new keys and their values by clicking New Key. To edit and delete it you can use the Edit and Delete buttons. Clear Map button allows you to delete all keys and values on this Parameter Map. With the Export File button you can export the key-value pairs as a CSV file that can, after editing, be imported again by using the Import File button.
Business Analytics

In this example, we created a Parameter Map named All_EmpKey. The keys, the OpenLDAP user account, are mapped to their corresponding Employee Key values. (Figure 9)
13
Figure 9 : Framework Manager : Parameter Map Definition to map OpenLDAP user accounts to Employee Key
4.5 Define Conditional Query Filters in Framework Manager

We can use Query Subject filters to restrict user access to the data source. To allow a user to retrieve only specific data based on their logon information, we can use the following expression in the Query Subject filter.
[Business view].[Query Item]=#sq($ALL_EmpKey{$account.personalInfo.userName})#
For example, Figure 10 shows the query result of Employee by position-department by using the Test Sample button when no filter was set for this Query Subject.
Business Analytics
14
Figure 10 : Framework Manager : Employee by position-department Query Subject
Allowing users to query information only related to their logon account, we define the following Query Filter: (Figure 11)
[Business view].[Employee by region].[Employee key]=#sq($ALL_EmpKey{$account.personalInfo.userName})#
Business Analytics
15
Figure 11 : Framework Manager : Filter definition to allow users to query information related to their logon account
EmployeeKey 4032
User Account ayamada
User Name Akemi Yamada
Position Non HR Staff
With this Query Filter in place the macro will match the user logon information, used as keys in the ALL_EmpKey Parameter Map, and substitute this for its value. This results in the associated Employee Key value being passed to the query definition. As shown in Figure 12, the Test tab displays only information related to the currently logged in user ayamada. This means the result of the Query Filter is [Employee key] =4032.
Figure 12 : Framework Manager : Query result for account ayamada
Business Analytics

We can define multiple conditions in a single Query Filter definition by using Boolean expressions. When defining a filter condition with multiple data items we need to convert if..then..else and case.. expressions to and..or expressions since these cannot return a Boolean result. In this example we allow members of the HR departments to retrieve all HR data of their respective country. Users from other departments are only allowed to retrieve their personal HR data. In the other words, we set the filter as below. 1. Use Country_Code for HR group
2.
16
Use EmpKey for NonHR group
To achieve this scenario we can use following conditional Query Filter.

If (logon users group = nonHR then [employee key] = EmpKey Else [Country Code] = Country_Code
Figure 13 : Framework Manager : Parameter Map for HR_Country
The Parameter Map HR_Country provides a list of HR staff members. The logon account is used as the key and their Country Code is used as the respective value (Figure 13,14). Logon accounts which are not listed in this Parameter Map will be assigned to a default value of nonHR. Using this Parameter Map, we can use the following and..or expression as the Filter Definition.
(#sq($HR_Country{$account.personalInfo.userName})#='nonHR' and [Business view]. [Employee by region].[Employee key]=#sq($ALL_EmpKey{$account.personalInfo.userName})#) or (#sq($HR_Country{$account.personalInfo.userName})# <>'nonHR' and [Business view]. [Employee by region].[Country code] = #sq($HR_Country{$account.personalInfo.userName})#)
Business Analytics
17
Figure 14 : Framework Manager : Filter Definition for multiple conditions
As shown in Figure 15 and Figure 16 the results for this Query Subject differs depending on the logged in user account. When we logon as the regular staff member ayamada the Query Subject is filtered by Yamada Akemis EmpKey and only returns one record. However if we logon as HR staff member dtanaka the Query Subject is filtered by Tanaka Daichis country code and returns all records for Japan.
EmployeeKey 4032 4960 User Account ayamada dtanaka User Name Akemi Yamada Daichi Tanaka Position Non HR Staff HR Vice President
Figure 15 : Framework Manager : Query Result for logon account of ayamada
Business Analytics
18
Figure 16 : Framework Manager : Query Result for logon account of dtanaka
4.6 Create Dynamic Reports in Report Studio

Report Studio allows us to use Parameter Maps and Session Parameters to create dynamic reports and queries. The list of available Session Parameters for the currently logged in user can also be found in Framework Manager by selecting Project -> Session Parameters. (Figure 17)
Figure 17 : Framework Manager : Session Parameters
To create dynamic Data Items we will use the same macro syntax which was used in Framework Manager to create the dynamic Query Subject filter.
Business Analytics

As shown in Figure 18, we can create a Data Item with following Expression Definition in Report Studio to display the logon account information on a report:
#sq($account.personalInfo.userName)#
19
Figure 18 : Report Studio : How to use logon information in Report Studio
In order to find out whether the HR Staff member is an Executive or Regular Staff member, we use the Parameter Map Position Code. It looks up the position code value for the respective logon account. In this example we use 2000 as the default value of this Parameter Map (Figure 19). Note: Executives have position codes smaller than 2000.
Business Analytics
20
Figure 19 : Framework Manager : Parameter Map PositionCode
To display the logged in user's position we can use the following conditional expression in the Data Item Expression referring to the Parameter Map Position Code (Figure 20).
if (#$PositionCode{$account.personalInfo.userName}# < 2000) then ('Executive') else ('Regular Employee')
Figure 20 : Report Studio : Conditional Expression for displaying Position information
Business Analytics

In this example we allowed all HR staff members to retrieve all HR information related to their country. But we also want to restrict access to confidential information such as salary and bonus to Executives only. We can use conditional expressions in a Data Item to mask confidential information replacing these with specific characters. In this example we mask salary with ***** to hide this information from non executive users. To do this, we can use following conditional expression for each Data Item (Figure 21):
If ((#$PositionCode{$account.personalInfo.userName}#<2000) or (#$account.parameters.employeeNumber# = [Employee key])) then ('US$ ' + cast([Employee summary (query)].[Employee summary fact].[Salary], varchar(10))) else ('*****')
21
Figure 21 : Report Studio : Masking confidential Salary Information
As shown in Figure 22, 23 and 24, the results displayed in this report will change dynamically depending on the user account used for report execution. For example, when a nonHR account such as ayamada executes this report it displays only the HR information of Akemi Yamada. When we use an HR staff member such as akato all HR information for Japan will be displayed but the information related to the Salary is masked. We can only display Salary when executive accounts such as dkato execute the report.
Business Analytics
22
Figure 22 : Report Viewer : Report result for ayamada
Figure 23 : Report Viewer : Report result for akato
Business Analytics
23
Figure 24 : Report Viewer : Report result for dtanaka
Business Analytics
24
Appendix A: Resources
1. 2. 3. 4.
IBM Cognos BI Administration and Security Guide IBM Cognos BI Installation and Configuration Guide Framework Manager User Guide Leveraging multi-valued LDAP attributes as Session Parameters http://www.ibm.com/developerworks/data/library/cognos/page120.html Configuring Framework Manager Row Level Security against LDAP http://www.ibm.com/developerworks/data/library/cognos/page30.html OpenLDAP Software 2.4 Administrator's Guide http://www.OpenLDAP.org/doc/admin24/OpenLDAP-Admin-Guide.pdf
5.
6.
Business Analytics

Dynamic Reporting With Role Based Security

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dynamic Reporting With Role Based Security

Uploaded by

Copyright:

Available Formats

Dynamic Reporting with Role based Security