What happens in many environments is that although they may start out with a clear structure and plan for how security will be implemented and evolve over time, it just never seems to turn out as planned. It just gets messy! Most environments begin with a couple of hundred users and a small number of groups, and as they evolve over time, the original security structure just collapses under the weight of its own complexity.
Often it starts out without a clear understanding of how groups, roles and accounts are designed to be used. Most security is implemented in Cognos BI by simply bringing/dragging in group(s) from an existing external source. These groups contain the users who are assigned by the security team which may or may not be part of the BI team. This will cause problems due to the complexity resulting from the separation of groups to users and the direct assignment of groups to content and/or roles. Bottom line, there is no direct link available from the secure content to an actual user, as represented by the dotted line in the adjacent diagram.
Groups get connected with Cognos content and roles (shown in blue) which then compounds the difficulty of being able to easily understand which users have access to specific content and why, or even what, privileges they have for any given content. This is a critical point in the process. If you don’t get it correct here it only gets worse over time. And without an effective tool to make security totally transparent, there is no way to for Cognos administrators to validate security. This is truly a black hole and the source of endless frustration for administrators.
Even the best IBM Cognos security model is vulnerable to the two things that inevitably occur overtime; growth and change. Growth occurs naturally as new users are added to existing groups but it can also occur when new units (departments, divisions, etc.) are added to the mix. New users will likely come with their own profile definition. If there ever was a clear plan or model for security initially, it’s now gone after a few unplanned additions over time. It will become increasingly difficult to understand, manage or accommodate security with future growth.
Major changes in your Cognos security will also come as your organization changes to meet evolving business needs. This further complicates managing security in a large Cognos environment. This will get to the point where there are large amounts of orphan content, users in the wrong groups, and groups with no users in them, etc. When this happens often the only alternative is to restructure security into a new model that is flexible enough to accommodate both current and future security needs.
Designing a new security model may not be too difficult. Implementing it can be another story. Here the biggest challenge is to make sure it’s still ‘whole’ when you are done. It’s a bit like taking your car apart to fix something only to discover that after you’ve put it back together you still have parts left over. Not good.
A good way to handle a security model makeover is to begin with a complete matrix of your existing security structure. That is, assuming you can put one together. The next step is to create a new security model that reflects your current needs but can accommodate future requirements as well.
The obvious question will be: How can I plan for future needs if I don’t know what changes will be required? True enough, but with a clear understanding of how security works in Cognos BI you can go a long way to creating a security structure that will handle change over time and can avoid creating a messy security model. Some of our previous blogs on Cognos security cover this in a clear, straight forward manner. You can find these at http://www.envisn.com/envisn-cognos-blog/?Tag=Cognos+Security
Once you’ve created the new security model the next step is to do a walkthrough of what goes where. You will likely find some things that need to be addressed. Following this, your next step should be to use your test environment forthe testing and validation of the new security model. This is not something you want to take any shortcuts with. Once the testing is successfully competed you can complete the final step of implementation.
In summary, the main steps of a security makeover are:
One final point here is important. The people that administer your Cognos security really need to know your security model completely and to make sure it’s followed when adding users, groups or content. With some luck you can keep you Cognos environment from becoming messy.