Mastering IBM Cognos Security

Mastering IBM Cognos Security

2 of 11

Table of Contents
Namespaces, Groups, Roles and Accounts Account Object Memberships Cognos Access Permissions Access Permission Inheritance Managing IBM Cognos Capabilities and License Compliance Best Practices for Implementing IBM Cognos BI Security 3 4 6 7 8 9
Welcome
This Ebook is designed to help you understand how IBM Cognos security works and how you can best apply it to meet all of your needs. One thing to keep in mind as you go through this; Security within Cognos will work well in virtually any environment if its applied correctly, and with the understanding that security needs to be based on a model or structure that can handle both change and growth over time.

Mastering IBM Cognos Security

3 of 11

Namespaces, Groups, Roles and Accounts

Namespaces
There are at least two namespaces in every Cognos environment: the internal Cognos namespace plus external security namespace(s). The Cognos namespace is integral with the Cognos BI application. The objects it contains of security interest are Groups and Roles which can optionally be organized into Namespace Folders. (Other objects in this namespace which are not directly used in security are data sources, printers, contacts and distribution lists.) External namespaces (also called Authentication Providers) are defined in the Cognos Configuration program and can be of a variety of types, including Active Directory and LDAP among others. Once configured, the complete external security hierarchy of objects is available to Cognos consisting of Groups and Accounts organized into Namespace Folders.

Groups and Roles

Though different object types, Groups and Roles behave identically. They are containers which hold references to Accounts along with other Groups and Roles. These references are called members of the group/role. Only the Groups/Roles in the Cognos namespace can be modified to add or remove members. The external namespace Groups must be managed using the namespaces editing tool, such as the Active Directory Users and Computers program. The organization of members into the Groups/Roles is the most important factor in setting up an effective security system since they are commonly used to define permissions to Cognos content store objects.

Accounts
Authentication to the Cognos applications is performed through the external namespace. A user must provide valid credentials for an account object in the namespace to gain entry to the application. Once authenticated, the users visibilities to objects and actions that can be performed are completely controlled by the memberships of the account and the security applied to both the content store objects and capability objects (to be covered later in the series).

Mastering IBM Cognos Security

4 of 11

Account Object Memberships Cognos

A users permissions in Cognos are determined by memberships of the Account object used for authentication. But the calculation of these memberships can become complicated. Lets start with the easy one, Explicit Membership.

Implicit Membership (1st Degree)

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.

Implicit Membership (nth Degree)

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:

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.

Mastering IBM Cognos Security

5 of 11

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. Its 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.

The Problem for Cognos Administrators

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: Who are all the members of the Managers Role? Which Cognos Roles does Melisa belong to? What content can Melisa access based upon her memberships? 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. Detail information is available in the IBM Cognos Documentation: IBM Cognos Administration and Security Guide 8.4.0

Understanding Access Permission Settings on IBM Cognos objects

Permission settings on Cognos objects are use to grant or deny access or actions for specific security objects, usually Groups or Roles. There are five access permissions which are described briefly here.

Mastering IBM Cognos Security

6 of 11

Access Permissions
Read View all properties including output Create a shortcut to an object Write Modify properties of or delete an object Create objects in a container such as a package or folder Modify an objects specification in a studio: Report Studio, Query Studio, etc. Create new outputs for a report Execute Set Policy Traverse Run objects such as reports, report views, events and metrics Read and modify the security settings for an object View the contents of a container such as a package or folder

Group / Role Membership

A user assumes the combined access permissions of all the groups and roles defined for an object of which the user is a member (explicit or implicit)

Granted and Denied Access

Denied Access has precedence over Granted Access

Traverse Access
To access an object a user must have Traverse access permission on all of the ancestors of the object.

Ownership of Objects
The owner of an object has full access permissions to the object (but still requires traverse access).

System Administrators
In addition to these permissions there are other important rules which influence a users access to and available actions on an object. Users which are members the System Administrators Role in the Cognos namespace have full access permissions to all objects.

Mastering IBM Cognos Security

7 of 11

Access Permission Inheritance

Access permissions on a content store object are by default inherited by its parent. To assign different permissions on an object then check the Override the access permissions acquired from the parent entry option on the permissions form. If you want clear any overridden permissions on the descendants of an object then check the Delete the access permissions of all child entries option on the permissions form. The inheritance of security settings in Cognos makes administration easier when dealing with a large number of objects. With well thought out organization of the content store objects only a single ancestors security will need to change. However, when security is overridden at lower levels in the object hierarchy it becomes difficult to determine where these overrides exist and what impact they have. This is another case where third party software tools are useful.

Mastering IBM Cognos Security

8 of 11

Managing IBM Cognos Capabilities and License Compliance

Cognos Capabilities (Global)
Access to various functional areas and administrative tasks is controlled through the Access Permissions assigned to Capabilities, which are also known as Secured Features and Secured Functions. Examples of these include high level functions such as the authoring Studios, Administration and Scheduling, and lower level features such as Bursting and User Defined SQL.

License Compliance
IBM Cognos BI licenses are usually based upon (in part) access to various Features, such as Query Studio, Report Studio, Analysis Studio, PowerPlay Studio, Cognos Viewer and Administration. To monitor compliance it is necessary to determine how many Accounts have permissions to each of these features. This is where the complexity of the security hierarchy (described in Part 2 of this series) can make this task difficult. You will usually be using Groups to control access to Features so this is where good organization or a third party program able to analyze the security hierarchy would be useful.

permissions on individual Packages and Folders. Giving an Account, Group or Role permission at this level also requires permission in Global Capabilities. In the case of Folders, Capability permissions are applied to all descendants. When applied to Package objects however, the Capability permissions will be applied to all reporting objects created from that package regardless of where they reside in the Content Store. This is a useful feature that, for example, could deny access to Studios for all reports created from that package (for a specific Group), rather than denying Write access to all the individual reports. As you can see from what we have covered so far, Cognos Security can get complicated and confusing. What we will cover next are some Best Practices that will help you maintain a secure and manageable Cognos environment.

Access Permissions
Unlike other content store objects, the only Access Permissions which affect the Capabilities are Traverse and Execute. Other than that, these permissions follow the same rules described above, including Group / Role Membership, Traverse Access, and Granted and Denied Access.

Object Capabilities
Starting with IBM Cognos BI 8.3, it is possible to define Capability

Mastering IBM Cognos Security

9 of 11

Best Practices for Implementing IBM Cognos BI Security

If you have read the previous blogs in this series, or are already managing an IBM Cognos environment, you know how complex controlling user access can be. But it can all be summarized by these two goals: Secure sensitive data from unwarranted access, but allow the necessary data to be available to all business intelligence consumers. Control access to Cognos BI capabilities, both globally and package based, so that content is created and distributed by approved authors, and that Cognos license limits are respected. The best practices described here may not be the best in all environments but will hopefully help those new to Cognos BI or for those about to refactor how Cognos security is set up. in an organization of groups. Study this organization to see if it can be used to control access in Cognos, probably to content. Instead, you may be using an external security specifically for Cognos, such as Cognos Series 7. Because an account must belong to a group in Series 7 in order to be recognized by Cognos BI, you have a couple of choices: Create groups in Cognos security to organize accounts that will be used to control access in Cognos, either for capability or content, though probably the latter. Add all accounts to just a single group and manage all access using the Cognos namespace groups and roles.

Use Existing Groups

If your external security is also used in a corporate environment the chances are that the accounts are maintained

Groups or Roles
Group and role objects in the Cognos namespace behave almost identically. The difference is that groups can contain only accounts and other groups, while roles can contain accounts, groups and other roles.

Mastering IBM Cognos Security

10 of 11

Best Practices for Implementing IBM Cognos BI Security

Organizing multiple groups in a role could get complicated very quickly, but it may make sense if you use the role for broad access control and the groups for limited access. A simpler rule to follow would be to use roles to control access to capabilities, and groups to manage access to content. Payroll Managers. You will also need to manage read and write permissions to the BI reports. One method would be to create separate groups; for example, Payroll Unit Consumers and Payroll Unit Authors. In this case, both groups will be used on report security but the access permissions would be set according to how read and write permissions are aligned.

Managing Content Access

The design of security access to Cognos BI content first requires an analysis of the types of business data available. Generally data will be organized at a high level by business unit or functionality, such as order processing or finance. Data may then be classified by employee position. For example, managers would have access to payroll detail reports but clerks may only view high level reports. One solution would be to create a group for the business unit (Payroll Unit) and groups for more limited access (Payroll Managers). Managers would belong to both groups. The reports which all payroll unit employees can view would use Payroll Unit for security and limited access reports would use

Managing Capabilities
Capabilities are used in Cognos BI to control access to features and functions such as the reporting studios and administration tools. There are a number of default Cognos namespace groups that are created during the Cognos installation that have certain capabilities defined. For example, Authors and Query Users have access to Query Studio, but Authors also have access to Report Studio. It is recommended that new roles be created to manage user capabilities that match the distribution of your Cognos licenses. For example, a role could be created for power users to

Mastering IBM Cognos Security

11 of 11

Best Practices for Implementing IBM Cognos BI Security

access all studios and another role for users which only need a PowerPlay license. The advantage of organizing capabilities this way is that it makes it easier to manage your Cognos BI licensing compliance. By following many of these best practices you can establish some structure to how security is applied that will help keep order in this area as your BI environment grows and changes. Without this, you are more likely to evolve quickly into a situation where your security is complicated and difficult, or impossible, to maintain.

Envisn
www.envisn.com http://www.envisn.com/envisn-cognos-blog/ 233 Ayer Road Harvard, MA 01451 USA T: 978-779-0400 F: 978-772-0985 E: Info@Envisn.com