Lockdown Cognos Security
Date: 13/01/2017

By Peter Fritzsche

Having seen all kinds of different Cognos installations of various sizes and complexity, I know that when it comes to security, there is always room for improvement.

Gaining a comprehensive understanding of security is critical. In this article I provide an overview of the different aspects of security in IBM Cognos 10 and share best practices. It should help you determine how robust your current setup is and identify core considerations.

The Common Core

There is no lack of reasons why security matters. And although no two environments are alike, when security is concerned, the same core issues come up again and again.

Auditing security is no easy task

Knowing exactly who has access to which data and which Cognos Studios can be time intensive and is critically important when it comes to license validation.

Initial setup

If the initial setup is not done properly, future maintenance to achieve the required security can be very painful and time intensive.

Data Access Strategy

The more sensitive the date is (eg., personal health or financial information) the more important it is to ensure that only permitted users are able to access it.

Usability

Cognos users often have more capabilities than they are trained or licensed for. There are certain steps which make life easier for users and safer for the company.

Development environment

Development or test environments often provide access to the same data sources. Knowing a URL is often enough to get access when security is not setup properly.

Lack of training

It is common for the infrastructure team to be in charge of administering the Cognos environments. A critical mistake I come to observe is not upskilling these resources on security aspects. This can lead to security loop-holes and major license compliance issues.

Some Basics You Should Know

Cognos Authentication is always managed using a third party Authentication provider like Active Directory. In Cognos Configuration the connection details of the third party provider are configured and all user details (password, email etc.,) are stored and managed within the third party system.

The diagram below shows different options for third party provider:

Active Directory.png

Most companies already have a "Company Directory" in place. Once connected to Cognos all users can re-use their existing login credentials to access Cognos.

This means that when you start the Cognos service the first time, the complete "Company Directory" has access to Cognos at the same time, which emphasises the importance of the initial security setup.

Initial Setup

Let's pinpoint some important steps in the initial security setup. This is not intending to be a complete checklist with required configuration. For more information on setup click here: Initial Security Setup

By default, the Group "Everyone" is part of the following Roles: "System Administrator", "Consumers", "Query Users" and "Authors". Remove this Group from these Roles. Ensure that you always have at least one user in the Role "System Administrator".

Cognos Namespace.png

To allow only authenticated users to access Cognos you have to change the settings in Cognos Configuration from True to False. This requires a restart of the Cognos service. It can be useful to leave a "backdoor" open by adding the user "Anonymous" to the Role "System Administrator". This will provide an option to access the system with Administrator rights by changing the settings shown in the diagram above. This will be helpful in case of a corrupt or missing connection to the third party provider.

Groups vs Roles

There is not much difference in the function of Roles and Groups. We do however recommend to be consistent where to use Roles, and where to use Groups. For documentation and more details: Groups and Roles

To keep it simple we generally use Roles for functional security, and Groups for data security.

How to Use Roles

Predefined Roles are created after installation and once the Cognos Service is started the first time. Each Role has predefined access rights.

A complete list of all Roles and permissions are available here: Predefined Roles.

These access rights are ONLY functional access rights. You still need to think about data access rights. This will be discussed in the 'Data Access Strategy' section below.

Most likely the predefined Roles will not match your exact access requirements. Use them as a starting point but create your own company Roles.

When creating customised Roles, using the following rules might help to reduce complexity and future maintenance:

  • Ideally each user should be in only one (functional) Role
  • It should be possible to map each Role to a license entitlement
  • Keep all the existing Cognos Roles and create a new folder for your customised Roles
  • Use the Cognos Roles as a starting point, by adding the customised Roles to the Cognos Roles.

Sample of customised (functional) Roles:

Functional Roles.png

Corp_Administrators Access to configuration, security, administration and monitoring tools
Corp_Developers Access to development tools such as Framework Manager or Powerplay Transformer
Corp-Authors Users who can develop more advanced reports and queries using prompts and filters, typically Report Studio
Corp_PowerUser In addition to the rights a Consumer has PowerUsers have acces sto Query Studio, Cognos Workspace Advanced
Corp_Consumers Users who only need to run a report or query to obtain the information they require. Consumers can also use Cognos Workspace to view Dashboards


In the sample above the customised Roles are all based on Cognos Roles with some modifications in the capabilities of each Role.

Data Access Strategy

Once you have defined your functional access strategy it is important to setup your data access strategy. This is a very broad topic with additional aspects like:

  • Modelling data level security in Framework Manager
  • Managing security in TM1
  • Setup security in Transformer by using Custom Views

We will not go into detail here but wherever security is modelled (FM, TM1, Transformer) the integrated and best practice approach is to use Groups or Roles to grant data access. Some guidelines to reduce complexity and future maintenance.

  • Avoid using individual users when applying security to folders or other objects - use Groups instead (as shown in the sample above).
  • Try to keep it simple - don't apply complex security logic unless it's mandatory (often the business wants to have all levels of security and in the end everyone is in the Group where they can see all data)
  • Document your data security to monitor who has access to what objects
  • Re-use existing Groups (from your third party) if they meet your requirements

Customised Group Sample (data/object security)

Customised Group Sample.png

Finance_All_Read Users of this Group have read access to content related to Finance. 'All' represents that there is no restriction within Finance.
Finance_All_Write Users of this Group have the same rights as Finance_All_Read, but also have the ability to write. Write permission enables users to modify, create or delete objects (typically Report Authors have write permission).
Finance_BU_01_Read Users of this Group have the rights to see Finance data for Business Unit 01. "Read access" means the users are typically consuming data.
Finance_BU_02_Read Users of this Group have the rights to see Finance data for Business Unit 02. Security will be additive, meaning if a user is in Group BU_01 and BU_02, the user will see data for both Business Units.


Once the functional and data access strategy is in place it will be easy to apply the concept to your environment and hopefully reduce a lot of future maintenance.

Additional Recommendations

  1. Create a report based on the content store or use a third party tool to document your current security. This saves time and provides you with a good overview of your existing environment.
  2. Use a separate account to test that your security matches your requirements.
  3. Use security to improve user usability. Configure your environment so that users only have access to what they really need. Remove the rest by modifying the Role capabilities and limiting access to folders which are not required.
  4. Ensure you have a document that describes your current security concept. This will help you understand the rules and concepts behind security.
  5. If required, upskill your team to fully understand Cognos security. This will reduce the risk of unintentional access to sensitive data.
  6. Ensure your Cognos environment is "Audit Ready". If a license audit reveals that your security setup doesn't comply with your license entitlements, IBM can re-license your environment, even retroactively (charges apply).
Although this is only the tip of the iceberg, I hope this article provides some actionable insights. For more information on Cognos Security or to discuss how Cornerstone can help optimise your security concept, contact us for a Health Check on 1300 841 048 or reach us online.