One of the most challenging aspects of establishing any enterprise business intelligence platform is the design and implementation of a security model that is flexible and extensible enough to meet the needs of your business while also remaining simple enough to administer and maintain. Every organization is unique in how they operate, so a structure that best suits one may not necessarily be appropriate for another. Because of these fundamental differences, there is unfortunately, no single archetype for business intelligence security. There are however a few proven guidelines which if followed, will help to ensure that whichever solution you arrive at will work in harmony with your IBM Cognos 8 environment.
Centralization
Unlike prior generations of enterprise business intelligence software, IBM Cognos 8 lacks any form of local or proprietary method of authentication. These responsibilities have thankfully been off-loaded to the enterprise authentication provider of your choosing (LDAP, Active Directory, Siteminder, etc.). Once authentication is performed by the 3rd party resource, group and role based authorization is applied from within Cognos 8. Out of the box, Cognos is configured with a standard set of application based groups and roles that assign capabilities to the various studios and other aspects of IBM Cognos 8 in a manner that aligns closely with the typical software licensing model.
At this point it is tempting to begin mapping users from your external directory directly to default roles within the Cognos namespace, and creating new groups and roles to organize users in ways that satisfy the requirements of your security model (by function, region, business unit, etc). If you have ventured down this path, then you can likely attest that while it may be a near term fix, it quickly becomes cumbersome to manage. The IBM Cognos directory lacks many of the creature comforts of the fully featured directory service management interface and therefore if your organization’s IT policies permit, you are almost always better served to manage group and role membership for your BI security model from within your directory service itself. Providers such as Microsoft’s Active Directory allow for delegation of management to specific users, and offer a management console simple enough for almost anyone to use. The key to this approach is understanding that moving your BI security model into your directory service does not equate to an increased burden on dedicated information security resources within your organization.
There are multiple benefits to this approach. As was mentioned, it completely centralizes the administration and maintenance of your BI security architecture to a single point, and it enables those tasks to be done in the most effective manner possible (natively within directory service itself). If you operate multiple IBM Cognos 8 environments, you can quickly and easily mirror the same security model across all of them. You can also take this approach one step further and rather than map your custom groups and roles from your directory service directly into IBM Cognos 8, you can decouple your security model from the application by creating matching groups and roles within the built in namespace, and then performing one to one mapping from your directory to these place-holder objects. This technique, while adding some overhead, will make your IBM Cognos 8 environment agnostic to its underlying authentication provider and enable flexibility to more easily change the resource in the future if the need arises.
Consolidation
Even if you have selected a single primary authentication provider for IBM Cognos 8 and proceeded to centralize on this platform as described above, it is likely you may encounter additional heterogeneous security providers that exist only to handle authorization duties for specific data sources. For example, your data warehouse may have its own proprietary set of security tables, utilize built in security or Series 7 Cognos customers hoping to migrate their PowerCubes into IBM Cognos 8 might feel tethered to their legacy Access Manager Namespace. The value of centralizing your security model for the ease of management quickly degrades when levied with the notion of making changes in triplicate across these additional security providers and the need to consolidate becomes very apparent.
IBM Cognos 8 can enable this sort of consolidation by utilizing features from various components of its application architecture. You can leverage your groups and roles from the IBM Cognos 8 namespace to apply data level security from within Framework Manager, or even pass a user’s single sign on credentials straight through to the database. In addition, the latest version of IBM Cognos 8 Transformer fully supports the use of the Cognos namespace for data level security within your cubes. To facilitate this process, the Ironside Group has developed a methodology and set of tools to help you through the process of migrating your old Access Manager Namespace to IBM Cognos 8.
Integration
Sometimes there isn’t an out-of-the-box, fully consolidated or centralized solution to suit the needs of your specific organization, but it doesn’t mean you should have to compromise on your requirements or change your usage pattern to seemingly meet the needs of your technology investment. Your business intelligence platform should conform to your business needs and not the contrary. Stay tuned for a future article that addresses a few of the more unorthodox security integration challenges that are likely to arise in the real world.
Categories:
Cognos security
,
Cognos Tutorial
0 Comments