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.

1. Obtaining a topographical view of security soup to nuts (Users  –> Groups –> Content)

Security Auditor scans the entire content store and records the users, groups and content, and then records the group membership and security inheritance.  This snapshot of information is stored into a central database to report on from MetaManager™ and from Cognos (or other systems).  By resolving all of the objects and their linkage and recording a timestamp we can do some pretty impressive things.  We can easily (and graphically) draw a line from user to content with all of the memberships and inheritance in between. Another exciting option is to focus on a specific account, group or piece of content and review that over several snapshots to see how and when security evolved. Below are a couple of screenshots, but for the real deal download the trial version of MetaManager™.  It will let you create a snapshot and then report on the current user.  Or request a fully functional trial to report on all users.

2. Reporting on Access Rights by content or by user

While Security Auditor is useful for obtaining a full picture of the security model, sometimes our needs are a little bit more specific.  Often times we need to provide information to others about security access.  Canned Reports and Content Documenter have these needs covered by documenting general information alongside group memberships and access rights.  With respect to memberships these modules will document the members of a group, but they will also document the inverse which is “Member Of”.  So for example when documenting the East group we’ll see that Ari is a member, but also when documenting Ari we’ll see that Ari is a Member Of the East group.  For Access Rights the user’s content will be displayed as a treeview (in PDF) with Policy information along side.  In addition there is an indication of whether the Policies are inherited or explicit. These modules support output to PDF, HTML, XML, Native Microsoft Excel an even to a SQL Server or Oracle Database (DB2 in progress).

Our final topic is reviewing Security Inheritance. It’s all well and good setting security at the folder/package level, but as soon as someone ticks the Override Security box your hard word goes to waste. Fortunately in MetaManager™ there’s an answer for that.

In any portal tree throughout the product you can right click on a report, folder, etc and choose the option Security Inheritance. The Security Inheritance viewer/editor will show a treeview of the portal tree with items in grey indicating that they inherit security and normal text where they override security. Now you can quickly determine if security is set at the proper level and inheriting down as expected. In addition to viewing this information there are two options for making changes. First is to reset the policies to inherit on the current item. This is used to fix a specific piece of content and reset the policies to inherit. The other and more power option is to reset all descendents to inherit. By choosing this option (presumably on a folder with explicit security) you’ll set all children and decedents to inherit from the current item. This is by far the quickest and easiest way to enforce a good clean security inheritance policy.