As described in the previous blog of our Mastering Cognos Security series, Cognos security consists of Groups and Roles which are basically containers holding references (as members) of other Groups, Roles and Accounts.
A user’s permissions in Cognos are determined by memberships of the Account object used for authentication. But the calculation of these memberships can become complicated. Let’s start with the easy one, Explicit Membership.
. To illustrate this with an example, a Cognos namespace Role has been created named ‘Managers’ which will be used to provide a high level of access to objects in the content store.
It is determined that a manager, Melisa Smith, requires this level of access in Cognos so the Cognos administrator adds the Melisa Smith Account as a member of the ‘Managers’ Role. Simple.
But this soon becomes unmanageable in a real world Cognos Environment with a large number of Accounts. A better way to control memberships is with Groups.
(A series of blogs on understanding and managing security in the IBM Cognos environment)
As described in the previous blog of this series, Cognos security consists of Groups and Roles which are basically containers holding references (as members) of other Groups, Roles and Accounts.
A user’s permissions in Cognos are determined by memberships of the Account object used for authentication. But the calculation of these memberships can become complicated. Let’s start with the easy one, Explicit Membership.
In this example Melisa already exists as a member in the external namespace group named ‘Finance Managers’. All the Cognos administrator has to do at this point is to add Finance Managers as a member of the Cognos namespace ‘Managers’ Role and this will make Melisa an implied member of Managers along with all the other Finance managers.
But the goal of this example is for all managers to be members of the ‘Managers’ Role.
Fortunately in our example there is a group in the external namespace named ‘All Managers’ which includes Finance Managers and the other manager types. Adding the All Managers group to the Cognos namespace ‘Managers’ Role ends up with a security hierarchy like this:
This is obviously a better technique to manage members. It relies mostly on assigning memberships in the external namespace but changes there are automatically inherited into Cognos security. It’s also possible to create a hierarchy of Roles or Groups in the Cognos namespace if, for example, All Managers did not exist in the external namespace.
While Group hierarchies ease the maintenance of security in Cognos, it also causes the loss of visibility in Cognos Administration to the members of the embedded Groups. It will be difficult for the Cognos administrator to answer these questions:
The only current possibility of answering these is with some complex Cognos SDK programming or with third party software which is capable of reporting and analysis of security group hierarchies such as NetVisn.
The next part of this series will examine the permission settings available on content in the IBM Cognos content store.
In this example Melisa already exists as a member in the external namespace group named ‘Finance Managers’. All the Cognos administrator has to do at this point is to add Finance Managers as a member of the Cognos namespace ‘Managers’ Role and this will make Melisa an implied member of Managers along with all the other Finance managers.
But the goal of this example is for all managers to be members of the ‘Managers’ Role.
The next part of this series will examine the permission settings available on content in the IBM Cognos content store.