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.
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.
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 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:
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.
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".
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:
|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)
|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.
- 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.
- Use a separate account to test that your security matches your requirements.
- 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.
- Ensure you have a document that describes your current security concept. This will help you understand the rules and concepts behind security.
- If required, upskill your team to fully understand Cognos security. This will reduce the risk of unintentional access to sensitive data.
- 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).