LDAP Authentication in Cognos 8

Using Cognos Series 7 Authentication with Cognos 8 BI: Common pitfalls to look out for.

Owais Bashir Ahmed Dated: 22nd June 2007

LDAP Authentication in Cognos 8

Abstract: This short article discusses some precautions we need to take when designing and deploying Cognos Security using LDAP/Cognos Series 7 Authentication.
Security in Cognos Environment is a very important design decision and early planning and awareness of deployment and integration related issues with correct selective removal of such design flaws can help reduce the total time of deployment. This article presents some common traps that security designers can fall into when using LDAP/Cognos Series 7 in combination with Cognos 8 BI. It aims at providing an elimination checklist to avoid such design flaws. Using an established LDAP Server in conjunction with Cognos Series 7 Authentication has been made easy with Cognos 8 BI. The configuration is made even easier with a few simple steps in Cognos Configuration. However there are some early design decisions that need to be taken into account much before you begin development and integration of security to your reporting solution. These standards if not followed could lead to rework and repeated code deployments from one environment to the other e.g. while moving your tested solution from a testing environment to a production one. The functionality might well be all fine but security might completely fail!

LDAP Authentication in Cognos 8

Set up Cognos Series 7 Authentication in a standalone environment To set up Cognos Series 7 Authentication all we need is: A preexisting Namespace in an established LDAP server.

1. In Cognos Connection Directory Administration tool you may have to add

Everyone group to a System Administrator and/or Directory Administrator till the time you have shifted Authentication to Cognos Series 7(as explained below) and then remove Everyone from the list and include instead only designated users/user classes into System and Directory Administrators. 2. Open up Cognos Configuration. 3. At the beginning the Configuration has only Cognos Authentication mode

LDAP Authentication in Cognos 8

4. To add the Series 7 Authentication, right click Authentication and add new resource

LDAP Authentication in Cognos 8

5. Select Cognos Series 7 and name the Authentication source as Cognos Series 7

LDAP Authentication in Cognos 8

6. Enter the information for the Namespace ID, Host, port and other information.

LDAP Authentication in Cognos 8

7. Under SecurityCognosAuthentication node set the Allow Anonymous

Access to False.

8. Save the configuration and restart the service. You are now ready to: a. Have authentication done by the LDAP Server (Host:Port specified). b. Authorization is still done by Cognos Namespace, so after your LDAP authentication is working you would need to add users and user classes from Cognos ConnectionDirectory Administration to relevant Cognos Groups. The configuration is done and you are ready. But this is not all!!

LDAP Authentication in Cognos 8

A) You need to have the same internal ids across environments for Security to work:

Suppose you have one LDAP server (LDAP1) for development environment where your modelers create the framework manager model, the report authors create the reports and unit test reports. The IT folks having set up LDAP1, the system admin of the development server creates Users classes and create users directly in the development LDAP using Cognos Series 7 Access Manager Administration tool. The modelers set up the data and object security inside the framework manager and publish the package for the reports developers to create the reports. The report developers create reports and then login as various users created by the system admin to test the security. The security works fine and all seems to be ok. But then as the time comes to deploy the package and reports from this development environment to test environment (which is expected to have same hierarchy of user classes and users), the security fails. The reason for this is CAMIDs, which Cognos uses to recognize objects and is particularly important for security. If this other environment doesnt have the same LDAP as the one for development, security filtering will not work, even though the same user classes and hierarchy is same for LDAP server of development environment (LDAP1) and LDAP server of test environment(LDAP2). When a user class or user is created manually in the access manager Cognos assigns an internal Id. So users and groups created individually and independently in LDAP1 and LDAP2 will not share common ids. Runtime security filtering will fail in test environment. To prevent this from happening, the user classes and users in LDAP server of development server have not to be created independently from the LDAP server of test server but by exporting the LAE file from test server and importing the LAE file in the development environment using Access Manager. This ensures that CAMIDs are same. Only once this step is done can the System Administer release the system for the modelers to define security on objects and data. The approach is therefore: Export LAE File from Test Server LDAP2Import LAE File into LDAP1Create Security filters in Framework ManagerPublish PackageCreate ReportsExport Content to Test Server Extending the same concept to Production Scenario: Export LAE File from Production Server LDAP3Import LAE file into LDAP2 and LDAP1 Create Security filters in Framework Manager ..

LDAP Authentication in Cognos 8

B) For security filtering you need to have one group(user class) for each combination of dimensional elements required for filtering :
Suppose you have two hierarchies:- A product and a demography. The product hierarchy has a level Product Group and Demography has a level Cluster(consisting of a group of countries). Examples of elements of Product Group are: Hypnotics, Antibiotics, Sedatives,etc Examples of elements of Cluster are: Middle East, Japan, Australasia, etc The business requirements needs security filtering based on combination of Product Group and Cluster only. The design decision that a modeler/System administrator might face is whether: Approach A 1. To create one User Class per Product Group. So user classes created might be clsHypnotics, clsAntibiotics, clsSedatives,etc 2. To create one User Class per Cluster. So user classes created might be clsMiddleEast, clsJapan, clsAustralasia,etc 3. Add individual users to required Product Group and Cluster Group required. 4. Thus the no. of User Classes that would be required => M+N where M = no. of distinct elements of Product Group. N= no. of distinct elements of Cluster 5. So if John is required to be seeing data of only Middle East Sales of Antibiotics, he would be added to clsAntibiotics and clsMiddleEast Approach B 1. To create one User Class per combination of valid Product Group Cluster combination. In other words create a combination group. Some examples of user classes would be clsHyponotics_Japan, clsAntibiotics_MiddleEast, etc 2. Add individual users to required Combination group. 3. Thus the maximum no. of User Classes that would be required => M*N where M = no. of distinct elements of Product Group. N= no. of distinct elements of Cluster 4. So if John is required to be seeing data of only Middle East Sales of Antibiotics, he would be added to clsAntibiotics_MiddleEast From an instant it is obvious that Approach A is better in terms of ease of maintenance. However by design Cognos applies an OR filtering and not AND filtering. So if we follow approach A, and John wishes to execute a sales report, the data that he would see is Product Group = Antibiotics OR Cluster = MiddleEast This is not what was intended. John was expected to see the MiddleEast and Antibiotics data only. Or in other words the filter that should have been applied should have been Product Group = Antibiotics AND Cluster = MiddleEast This behavior is achievable only if designers apply approach B.

C) Namespace IDs should be same across environment :

LDAP Authentication in Cognos 8

This is an extension of the item A) above. There are cases when the LAE export from final target environment and import to the development environment is done correctly before the security implementation in the model is begun but the namespace Ids are not the same across the environments. Just like the internal ids, the Namespace ID should be same in the target Configuration environment and the one where security is implemented. In the below example if Namespace ID is not Cognos S7 in target configuration then security will not work after deployment