One of the more misunderstood areas of Cognos Security is how object permissions are set and how they need to be managed within Cognos. In this blog article we’re going to cover both of these and also focus on how to resurrect a Content Store that may be seemingly unrecoverable once object permissions have been messed up.
All Cognos public content exists in a single hierarchy of folders and packages. Packages behave as folders as well as containing metadata. Initially all object permissions are inherited from the public root folder.
Also, every object either overrides object permissions or inherits them from the closest object with overridden permissions.
The key to making Cognos object security easy to manage is to organize content based on access requirements. This should minimize the number of folders in the hierarchy with override permissions. Overriding permissions on reporting objects should be avoided if at all possible. This rule isn’t always followed and it often leads to problems; sometimes major ones where access rules are not implemented as they should be.
Permissions can be set in the properties page of any object in Cognos Connection. This dialog contains two important options:
Understanding what these options mean is critical to successfully implementing object security in your Cognos environment(s). If you don’t get this right it can cause a lot of headaches.
Checking ‘Override the access permissions from the parent entry’ option will cause the permissions defined here to control object access. Unchecking this option will cause permissions to be inherited from the closest ancestor with overridden permissions.
What happens when checking the ‘Delete the access permissions of all child entries’ option depends upon the first option. If ‘Override’ is checked then all descendants (not just children) will inherit permissions from this object. If ‘Override’ is not checked the descendants permissions will all be inherited from this object’s closest ancestor with overridden permissions.
When ‘Delete the access permissions of all child entries’ is unchecked then descendant object permissions are unaffected.
It’s virtually impossible to examine your current public folder permission hierarchy in Cognos Connection since each object’s permission would have to be examined. A daunting task! Envisn’s NetVisn product makes this information available using its Security Audit analysis in a way that makes it easy to both understand how permissions are applied and to also make changes where necessary.
Here are the analysis options:
In the graphic below we see the output of this Audit Report. Two folders have Overridden Security. These are BI Reporting and BI Marketing.
This is helpful but we need to know which objects are inheriting these permissions. We simply go back to the Analysis page in NetVisn and include this as part of our analysis and this shows the objects inheriting these permissions as seen in the graphic below. With this information we can make any changes needed.
What should be obvious here is that you need to have a good conceptual understanding of how object permissions are applied within Cognos. Without this it’s easy to make some selections which may be difficult to undo once they’ve been made. Many Cognos environments have established rules for how object permissions are set and who is authorized to make them.
Cognos Connection makes it relatively easy to make changes in object permissions but has no means to see the impact of these changes and see your public folders permission hierarchy without looking at each individual object. That’s not possible in an environment with a large number of objects. For this you need a product like NetVisn or something similar that makes it possible to see this hierarchy laid out in a clear, simple manner.
Object permissions in Cognos need to be assigned with a clear understanding of how they are set and how inheritance is assigned based on those settings. A goal should be to minimize the number of folders with override permissions. In order to understand how override permissions have been set in an established Cognos environment you may need a tool like NetVisn to make this visible to make changes or corrections.