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

2Dynamic Reporting with Role based Security

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 [email protected].

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

http://www.ibm.com/legal/copytrade.shtml

mailto:[email protected]


Table of Contents1 Introduction..............................................................................................................4

1.1 Purpose.....................................................................................................................41.2 Applicability...............................................................................................................51.3 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 Implementation steps.................................................................................................84.2 Mapping OpenLDAP entry as IBM Cognos BI Session Parameters..................................84.3 Assigning OpenLDAP groups and users to Cognos Namespace groups and roles..........114.4 Create the Parameter Maps in Framework Manager....................................................114.5 Define Conditional Query Filters in Framework Manager.............................................134.6 Create Dynamic Reports in Report Studio..................................................................18

5 Appendix A: Resources............................................................................................24

Business Analytics


1 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 user’s 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

http://www.ibm.com/developerworks/jp/data/library/cognos/j_d-openldap02/index.html


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


2 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 and assigned 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.

Business Analytics


3 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


4 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. Mapping OpenLDAP entry as IBM Cognos BI Session Parameters

2. Assigning OpenLDAP groups and users to Cognos Namespace groups and roles

3. Create the Parameter Maps in Framework Manager

4. Define Conditional Query Filters in Framework Manager

5. 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:

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


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 Namespace’s 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).

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


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)

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


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


Figure 11 : Framework Manager : Filter definition to allow users to query information related to their logon account

EmployeeKey User Account User Name Position4032 ayamada Akemi Yamada 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. Use EmpKey for NonHR group

To achieve this scenario we can use following conditional Query Filter.

If (logon user’s 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 “non-HR”. 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


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 Akemi’s EmpKey and only returns one record. However if we logon as HR staff member “dtanaka” the Query Subject is filtered by Tanaka Daichi’s country code and returns all records for Japan.

EmployeeKey User Account User Name Position4032 ayamada Akemi Yamada Non HR Staff4960 dtanaka Daichi Tanaka HR Vice President

Figure 15 : Framework Manager : Query Result for logon account of ayamada

Business Analytics


Figure 16 : Framework Manager : Query Result for logon account of dtanaka

4.6 Create Dynamic Reports in Report StudioReport 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)#

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


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 ('*****')

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


Figure 22 : Report Viewer : Report result for ayamada

Figure 23 : Report Viewer : Report result for akato

Business Analytics


Figure 24 : Report Viewer : Report result for dtanaka

Business Analytics


5 Appendix A: Resources1. IBM Cognos BI Administration and Security Guide

2. IBM Cognos BI Installation and Configuration Guide

3. Framework Manager User Guide

4. Leveraging multi-valued LDAP attributes as Session Parameters

http://www.ibm.com/developerworks/data/library/cognos/page120.html

5. Configuring Framework Manager Row Level Security against LDAP


6. OpenLDAP Software 2.4 Administrator's Guide

http://www.OpenLDAP.org/doc/admin24/OpenLDAP-Admin-Guide.pdf

Business Analytics

http://www.OpenLDAP.org/doc/admin24/OpenLDAP-Admin-Guide.pdf



dynamic reporting with role based security

Documents