By Rick Ryan, Envisn, Inc.
What’s really frustrating to Cognos administrators is that when you need the answer to a question on security, you need the answer right now, not a day or two later. With the pain level this high there’s lots of motivation to set the bar high in terms of making the security metadata totally transparent and easy to work with.
This subject has to be approached the same way as any of the data used by Cognos. Break it down into its lowest levels while retaining relationships to all of the key dimensions used within the application; Objects, accounts, locations, etc.
There were three main things we wanted to be able to do:
Based on prior experience with Cognos security this could be expected to be a major challenge, with pain playing a key role. But in many respects simply by following the original goals that we set for Cognos’ metadata the payoff was big. Because here’s the thing; When you have the right architecture for capturing and storing all the metadata, getting the results you need isn’t a big deal. Sure, you have to design logical layouts and forms that best exemplify the data, but everything you need is there to work with.
Going back to some of the basic questions we started with, we see in Figure 1 the security profile for Melissa Smith. This shows that she has access to a total of 1707 objects within the Content Store. This can easily be expanded to show the detail for each group in the summary here along with any additional data needed.
Figure 2 shows all of the groups and roles that Melissa Smith belongs to in this Cognos environment.
The Audit Monitor shows all of the changes to all objects in real time. This is driven by effectively using all of the Cognos security metadata as well. Here Figure 3 shows a partial listing of security changes made for the past 30 days. This capability not only enables one to have a full record of all security changes across the environment but also to be able to see who made each change.
Inherited and overridden security both pose challenges in terms of capture because of how it cascades through hierarchies. But we have managed to do it here in Figure 4 which shows a partial listing of overridden security in our Cognos environment. This information is helpful in determining why an individual may not have access to one or more objects they believe should be available to them.
Being able to see who the members and expanded members are of different groups or roles is difficult or impossible in Cognos. In Figure 5 we see a partial listing of all of the roles within our Cognos environment. This simple view makes it easy to see how they relate to each other and where they overlap.
These examples show just a few of the things you can do with the Cognos metadata around the security dimension. In the end it’s just basic reporting and analysis.
A major learning from developing this ability for to analyze and report on every aspect of Cognos security is that this capability is ideal for those situations where a Cognos administrator is challenged to clean up a security model that has been distorted over time by additions and changes that are inconsistent or just plain wrong.