Sorting out IBM Cognos Security using MetaManager

[Andrew Weiss]

This article was posted on the BSP Blog located at:
http://www.bspsoftware.com/sorting-ibm-cognos-security-using-metamanager/

Sorting out IBM Cognos Security using MetaManager

Managing Security in IBM Cognos can get confusing pretty quickly.  Worst still, it can become obsolete or inaccurate over time and rooting out the issues is like an Easter Egg Hunt. It's for this reason that MetaManager has an entire bundle of modules dedicated to the task.  Let's review a few of these features here.

In this article we'll focus on these 3 common security use cases:

• Obtaining a topographical view of security soup to nuts
• Reporting on Access Rights by user
• Reviewing and Modifying Security Inheritance for Consistency

   
First let's talk Security in IBM Cognos

At the most simplest level "security" boils down to an Account being assigned Polices (such as Read access) to a piece of content.  In terms of evaluating security the question is always, what security policies does this [current] account have on this piece of content.  Getting to that answer can be abstracted though through several features in the security model. Two of these features to help develop a robust security model are Group Memberships and Policy Inheritance. Using these features requires forethought and more importantly review. Security Auditor has the review portion covered.

Group Memberships is simply creating a group of similar accounts based on some function or role that motivates having the same security. For example, I grant Ari and Eric 'Read' access to the sales reports since they are on the sales team. Now when James joins the team I have to explicitly grant him access to the same reports.  Alternatively I use group memberships by creating a Sales Group and then add Ari, Eric and James as members.  Then, instead of adding their accounts to the content I add the group.  Now, when the Sales team personnel changes all of my changes are performed once in a single place.  To complicate things a bit, not only can Accounts be members of a Group, but so can Groups.  By providing this nesting we can now build organizational structures such as in this geographical scenario.  Our sales department is broken into 3 territories: East, Central and West.  Sales personnel belong to one of these 3 groups.  Collectively these 3 groups are members of the Americas Sales group.

At this point we can begin to see the need for a Security Audit and a topographical view.  An account belongs to a group, which in turn belongs to another group which then has access to a piece of content.  But wait, it gets more complicated...

Policy Inheritance is a feature which allows you to set security policies at high levels and then have the security propagate or inherit at lower levels. We're all probably familiar with this concept from folder/file security on our own computers.  Generally speaking security should be explicit (meaning it's set) at a high Package or Folder level. By breaking up reports by their general security access not only does it become easier to create a security model, but then it becomes easy to allow the environment to evolve without inadvertently creating security holes.  When security is set at the folder level the intent is that all sub content is set to inherit the security from the parent.  By doing so new content will always use the security that's in place.

Let's revise our previous statement.  Ari has access to the Sales Leads report because.... The Sales Leads report inherits security from the Sales Reports folder, which grants Read access to the Sales group which has the East Region as a member which Ari is a member of.  Sometimes we need to see this in both directions: (a) Who has access to this report and why? (b) What does this person have access to and why?  The answer is Security Auditor.

Continue Reading at: http://www.bspsoftware.com/sorting-ibm-cognos-security-using-metamanager/