By Paul Hausser, Envisn, Inc.
This blog focuses on the biggest issues in the area of Cognos security as seen by Cognos administrators. It was collected informally from a series of questions responded to over the past 14 months.
• Using an outdated security model. If your current security model cannot effectively handle change and growth you have a real problem. Every organization experiences these at different rates but change and growth are always there.
• Inconsistent use of groups and roles across the environment. Groups and roles behave almost identically but they are different. Groups can contain only accounts and other groups, while roles can contain accounts, groups and other roles. A simple rule to follow is to use roles to control access to capabilities and groups to manage access to content. Another rule to follow is to minimize creating new groups wherever possible.
• Too many people administering security. This is a recipe for disaster. Why? Because even if you have clear rules for assigning security they may not be clearly understood or followed. Which is why this area needs to be a balance between giving developers and others the ability to assign security as needed, but also limiting it to only that which is operationally necessary (damage control). It will usually be apparent when you’ve lost control in this area.
• No tools to manage Cognos security. Wouldn’t you like to be the one that discovers problems with your Cognos security? You need the ability to analyze, validate and view security and capabilities assignments quickly and easily. Testing your own security on a regular basis for compliance with standards should be part of what you do on a regular basis.
But Cognos security is inherently complex, especially in the area of inherited security. Trying to view this within Cognos itself is difficult and tedious at best, and often impossible. This is because you’re forced to look at it by how it’s assigned in Cognos Connection. But trying to trace the thread of inherited security within Cognos through multiple layers is virtually impossible. A third party software tool like NetVisn or a similar product can make it a lot easier to see all the dimensions of security and to validate settings as well.
• Access Permissions. While easily understood within the context of the matrix in Cognos Connection their impact is less so. Access permissions on a Content Store object are by default automatically inherited from its parent. Security settings inheritance in Cognos makes administration easier when dealing with large numbers of objects. The problem arises when security is overridden at lower levels making it difficult to determine where these overrides exist and their impact. Most of this can be avoided by a well thought out organization of your Content Store objects minimizing the need for single object securing changes.
© Envisn, Inc. 2016 All Rights Reserved.