by Gary Larsen - Envisn, Inc.
If you manage an IBM Cognos environment you know that security can get complicated very quickly. By carefully organizing content in hierarchies and using security inheritance you may find this task a bit easier. Here are some ideas which may be helpful in your environment.
On the properties page of every object in Cognos is a permissions tab which begins with this option:
When this option is checked, the security defined on this properties page will immediately affect the security on all descendant objects unless they also override access permissions.
One of the advantages of inherited security is that a new object (report, query, job, etc.) automatically acquires security from an ancestor. The same is true if an object changes folder locations.
On the same properties page is the follow option:
If you take the caption of this option literally you would assume the purpose would be to clear all the security overrides for the immediate children. In fact, this option will clear the security overrides of all ancestor entries!
This can be a quick method to re-initialize the security hierarchy at points in the content tree but be aware that security overrides located deep in the hierarchy will be removed. There is no need to ‘blast’ your security settings as this is done automatically.
Think of how Cognos users require access to reports and the data they contain. For a particular report here would be the common permissions:
The current preference in applying security in Cognos is to use Cognos namespace groups for content security and Cognos namespace roles for capability permissions, although it is not uncommon to see externals groups and roles being used also.
When creating groups for content security it’s helpful to understand the various business domains that use Cognos and how that will impact access to content. You will know how this is defined in your environment, but this may be by business division, geographic area, department, etc.
A useful strategy in naming groups would be to include both the domain segment name and the type of access. For example:
Division1 Read, Division1 Exe, Division1 Write
And also groups for global access:
Global Read, Global Exe, Global Write
This will be helpful when setting the permissions for a folder containing content related to a specific domain:
Make your environment easier to manage by combining a group naming convention which implies content permission, and using security inheritance so that access permissions are maintained only in key locations of the content hierarchy. Implementing a consistent, clear naming convention significantly minimizes confusion and errors which can occur in managing IBM Cognos security across your environment.
Image by purpleslog