By Gary Larsen - Envisn, Inc.
(A series of blogs on understanding and managing security in the IBM Cognos environment)
If you have read the previous blogs in our Cognos Security series, or are already managing an IBM Cognos environment, you know how complex controlling user access can be. But it can all be summarized by these two goals:
The best practices described here may not be the best in all environments but will hopefully help those new to Cognos BI or for those about to refactor how Cognos security is set up.
There are no set rules for the weighty task of implementing IBM Cognos BI security, so any feedback or alternative suggestions anyone can provide here is very much welcome!
If your external security is also used in a corporate environment the chances are that the accounts are maintained in an organization of groups. Study this organization to see if it can be used to control access in Cognos, probably to content.
Instead, you may be using an external security specifically for Cognos, such as Cognos Series 7. Because an account must belong to a group in Series 7 in order to be recognized by Cognos Series 7 BI, you have a couple of choices:
Group and role objects in the Cognos namespace behave almost identically. The difference is that groups can contain only accounts and other groups, while roles can contain accounts, groups and other roles.
Organizing multiple groups in a role could get complicated very quickly, but it may make sense if you use the role for broad access control and the groups for limited access.
A simpler rule to follow would be to use roles to control access to capabilities, and groups to manage access to content.
The design of security access to Cognos BI content first requires an analysis of the types of business data available. Generally data will be organized at a high level by business unit or functionality, such as order processing or finance. Data may then be classified by employee position. For example, managers would have access to payroll detail reports but clerks may only view high level reports.
One solution would be to create a group for the business unit (Payroll Unit) and groups for more limited access (Payroll Managers). Managers would belong to both groups. The reports which all payroll unit employees can view would use Payroll Unit for security and limited access reports would use Payroll Managers.
You will also need to manage read and write permissions to the BI reports. One method would be to create separate groups; for example, Payroll Unit Consumers and Payroll Unit Authors. In this case, both groups will be used on report security but the access permissions would be set according to how read and write permissions are aligned.
Capabilities are used in Cognos BI to control access to features and functions such as the reporting studios and administration tools. There are a number of default Cognos namespace groups that are created during the Cognos installation that have certain capabilities defined. For example, Authors and Query Users have access to Query Studio, but Authors also have access to Report Studio.
I would recommend that new roles be created to manage user capabilities that match the distribution of your Cognos licenses. For example, a role could be created for power users to access all studios and another role for users which only need a PowerPlay license.
The advantage of organizing capabilities this way is that it makes it easier to manage your Cognos BI licensing compliance.