Mastering Ibm Cognos Security

R E V I S E D E D I T I O N
Mastering IBM Cognos Security

Mastering IBM Cognos Security 2 of 24
Table of Contents
3 Namespaces, Groups, Roles and Accounts

Welcome
4 Account Object Memberships Cognos
This Ebook is designed to help
you understand how IBM Cognos
6 Access Permissions security works and how you can
best apply it to meet all of your
needs.
7 Access Permission Inheritance
One thing to keep in mind as you
go through this; Security within
8 Managing IBM Cognos Capabilities and License Cognos will work well in virtually
Compliance any environment if it’s applied
correctly, and with the
understanding that security
10 Best Practices for Implementing IBM Cognos BI needs to be based on a model or
Security structure that can handle both
change and growth over time.
12 Appendix
Some examples of insight into the details of Cognos security in a BI environment.
All trademarks mentioned herein are the property of their respective owners. © 2015 Envisn Information Solutions. All rights reserved.
Namespaces, Groups, Roles and Accounts

Security in Cognos is composed of a just a handful of object types, but understanding these objects and how they work
together is critical in implementing a manageable and secure Cognos environment.
consisting of Groups and Accounts

Namespaces organized into Namespace Folders.
since they are commonly used to define
permissions to Cognos Content Store objects.
You need to get this right in the beginning.
There are at least two namespaces in every
Cognos environment: the internal Cognos Groups and Roles
The long term success of your Cognos security
namespace plus external security
Though different object types, Groups and model is largely based on its ability to
namespace(s).
accommodate both change and growth over
Roles behave identically. They are
time.
The Cognos namespace is integral with the containers which hold references to
Cognos BI application. The objects it Accounts along with other Groups and
contains of security interest are Groups and Roles. These references are called Accounts
Roles which can optionally be organized members of the group/role.
into Namespace Folders. (Other objects in Authentication to the Cognos applications is
this namespace which are not directly used Only the Groups/Roles in the Cognos performed through the external namespace. A
in security are data sources, printers, namespace can be modified to add or user must provide valid credentials for an
contacts and distribution lists.) remove members. account object in the namespace to gain entry to
the application.
External namespaces (also called The external namespace Groups must be
Authentication Providers) are defined in the managed using the namespace’s editing Once authenticated, the user’s visibilities to
Cognos Configuration program and can be tool, such as the Active Directory Users and objects and actions that can be performed are
of a variety of types, including Active Computers program. completely controlled by the memberships of the
Directory and LDAP among others. Once account and the security applied to both the
configured, the complete external security The organization of members into the Content Store objects and capability objects (to
hierarchy of objects is available to Cognos Groups/Roles is the most important factor in be covered later in this document).
setting up an effective security system
Account Object Memberships Cognos

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.
number of Accounts. A better way to

Explicit Membership control memberships is with Groups.
Implicit Membership
th
To illustrate this with an example, a Cognos (n Degree)
namespace Role has been created named Implicit Membership Fortunately in our example there is a group in the
‘Managers’ which will be used to provide a st
high level of access to objects in the (1 Degree) external namespace named ‘All Managers’ which
includes Finance Managers and the other
Content Store.
In this example Melisa already exists as a manager types. Adding the All Managers group
member in the external namespace group to the Cognos namespace ‘Managers’ Role ends
It is determined that a manager, Melisa
named ‘Finance Managers’. All the up with a security hierarchy like this:
Smith, requires this level of access in
Cognos administrator has to do at this point
Cognos so the Cognos administrator adds
is to add Finance Managers as a member This is obviously a better technique to manage
the Melisa Smith Account as a member of
of the Cognos namespace ‘Managers’ Role members. It relies mostly on assigning
the ‘Managers’ Role. Simple.
and this will make Melisa an implied memberships in the external namespace but
member of Managers along with all the changes there are automatically inherited into
But this soon becomes unmanageable in a
other Finance managers. Cognos security. It’s also possible to create a
real world Cognos Environment with a large
hierarchy of Roles or Groups in the Cognos
namespace if, for example, All Managers did not
exist in the external namespace.
Cognos Role External Group External Groups Members
Finance Managers Melisa Smith
Managers All Managers Sales Managers
Mfg Managers
which is capable of reporting and analysis of security group

The Problem for Cognos Administrators hierarchies such as NetVisn.
While Group hierarchies ease the maintenance of security in
Cognos, it also causes the loss of visibility in Cognos Understanding Access Permission
Administration to the members of the embedded Groups. It will be
difficult for the Cognos administrator to answer these questions:
Settings on IBM Cognos Objects
Permission settings on Cognos objects are used to grant or deny
Who are all the members of the Managers Role? access or actions for specific security objects, usually Groups or
Roles. There are five access permissions which are described
Which Cognos Roles does Melisa belong to? briefly here.
What content can Melisa access based upon her memberships?
Detail information is available in the IBM Cognos Documentation:
The only current possibility of answering these is with some IBM Cognos Administration and Security Guide 8.4.0
complex Cognos SDK programming or with third party software
Figure 1 shows an
example of how a simple
view of how groups and
accounts can be part of
other groups.
This can be helpful in seeing

how they relate to each
other.
Click to see detailed view >

Access Permissions
Read View all properties including output
Traverse Access
Create a shortcut to an object
Write Modify properties of or delete an object To access an object a user must have Traverse access permission
on all of the ancestors of the object.
Create objects in a container such as a package or
folder
Ownership of Objects
Modify an object’s specification in a studio: Report
Studio, Query Studio, etc. The owner of an object has full access permissions to the object (but
Create new outputs for a report still requires traverse access).
Execute Run objects such as reports, report views, events and
metrics System Administrators
Set Policy Read and modify the security settings for an object Users which are members the System Administrators Role in the
Traverse View the contents of a container such as a package Cognos namespace have full access permissions to all objects in the
or folder Content Store.
In addition to these permissions there are other important rules which Figure 2 shows the permissions applied
influence a user’s access to and available actions on an object. to the folder labeled BI Sales.
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. Click to see detailed view >
Access Permission Inheritance

Access permissions on a Content Store object are by default The inheritance of security settings in Cognos makes administration
inherited by its parent. To assign different permissions on an easier when dealing with a large number of objects. With well
object then check the ‘Override the access permissions acquired thought out organization of the Content Store objects only a single
from the parent entry’ option on the permissions form. ancestor’s security will need to change.
If you want to clear any overridden permissions on the However, when security is overridden at lower levels in the object
descendants of an object then check the ‘Delete the access hierarchy it becomes difficult to determine where these overrides
permissions of all child entries’ option on the permissions form. exist and what impact they have. This is another case where third
party software tools can be very helpful in finding where this
occurs.
Figure 3 shows an
example of this. Write
access is denied to
Duncan Reilly’s account
for the report labeled
Customer. Finding this
within Cognos itself
could be difficult.
Managing IBM Cognos Capabilities and License Compliance

This is where the complexity of the security hierarchy can make this
Cognos Capabilities (Global) task difficult. You will usually be using Groups to control access to
Access to various functional areas and administrative tasks is Features so this is where good organization or a third party
controlled through the Access Permissions assigned to program able to analyze the security hierarchy would be useful.
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 Figure 4 shows that the 13 people that have access
lower level features such as Bursting and User Defined SQL. to Analysis Studio within the 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.
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.
Object Capabilities
Starting with IBM Cognos BI 8.3, it is possible to define Capability
permissions on individual Packages and Folders. Giving an
Account, Group or Role permission at this level also requires
permission in Global Capabilities. As you can see from what we have covered
so far, Cognos Security can get
In the case of Folders, Capability permissions are applied to all
descendants. complicated and confusing.
When applied to Package objects however, the Capability

permissions will be applied to all reporting objects created from What we will cover next are some Best
that package regardless of where they reside in the Content Store. Practices that will help you maintain a
This is a useful feature that, for example, could deny access to secure and manageable Cognos
Studios for all reports created from that package (for a specific
Group), rather than denying Write access to all the individual environment.
reports.
Best Practices for Implementing IBM Cognos BI Security

If you are already managing an IBM Cognos environment, you Create groups in Cognos security to organize accounts that will
know how complex controlling user access can be. But it can all be used to control access in Cognos, either for capability or
be summarized by these two goals: content, though probably the latter.
Secure sensitive data from unwarranted access, but allow the Add all accounts to just a single group and manage all access
necessary data to be available to all business intelligence using the Cognos namespace groups and roles.
consumers.
Groups or Roles
Control access to Cognos BI capabilities, both globally and
package based, so that content is created and distributed by Group and role objects in the Cognos namespace behave almost
approved authors, and that Cognos license limits are respected. identically. The difference is that groups can contain only accounts
and other groups, while roles can contain accounts, groups and
The best practices described here may not be the best in all other roles.
environments but will hopefully help those new to Cognos BI or for
those about to refactor how Cognos security is set up.
Group Role
Use Existing Groups Account Group Account Group Role
If your external security is also used in a corporate environment
it is likely that the accounts are maintained in an organization of
groups. Study this organization to see if it can be used to control Organizing multiple groups in a role could get complicated very
access in Cognos, probably to content. quickly, but it may make sense if you use the role for broad access
control and the groups for limited access.
Instead, you may be using an external security specifically for
Cognos, such as Cognos Series 7. Because an account must A simpler rule to follow would be to use roles to control access to
belong to a group in Series 7 in order to be recognized by Cognos capabilities, and groups to manage access to content.
BI, you have a couple of choices:
Managing Content Access

The design of security access to Cognos BI content first requires Managing Capabilities
an analysis of the types of business data available. Generally data
will be organized at a high level by business unit or functionality, Capabilities are used in Cognos BI to control access to features
such as order processing or finance. Data may then be classified and functions such as the reporting studios and administration
by employee position. For example, managers would have access tools. There are a number of default Cognos namespace groups
to payroll detail reports but clerks may only view high level reports. that are created during the Cognos installation that have certain
capabilities defined. For example, Authors and Query Users have
One solution would be to create a group for the business unit access to Query Studio, but Authors also have access to Report
(Payroll Unit) and groups for more limited access (Payroll Studio.
Managers). Managers would belong to both groups. The reports
which all payroll unit employees can view would use Payroll Unit for It is recommended that new roles be created to manage user
security and limited access reports would use Payroll Managers. capabilities that match the distribution of your Cognos licenses.
For example, a role could be created for power users to access all
You will also need to manage read and write permissions to the BI studios and another role for users which only need a PowerPlay
reports. One method would be to create separate groups; for license.
example, Payroll Unit Consumers and Payroll Unit Authors. In this
case, both groups will be used on report security but the access The advantage of organizing capabilities this way is that it makes it
permissions would be set according to how read and write easier to manage your Cognos BI licensing compliance.
permissions are aligned.
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.
Appendix
Figure 1 shows an example of how a simple view of how groups and accounts can be part of other groups. This can be helpful in seeing
how they relate to each other.
< Return to Article
Figure 2 shows the permissions applied to the folder labeled BI Sales.
< Return to Article
Figure 3 shows an example of this. Write access is denied to Duncan Reilly’s account for the report labeled Customer. Finding
this within Cognos itself could be difficult.
< Return to Article
Figure 4 shows that the 13 people that have access to Analysis Studio within the Cognos environment.
< Return to Article
Security Profile – Account
Figure 5A – Shows a security profile of a security object –

user Duncan Reilly. It shows his memberships in the Cognos
environment and a summary of all the objects that he has
access to.
This analysis also provides the detail on all 1,580 objects that
Duncan Reilly has access to. An example of this organized by
folder is shown in figure 5B.
Security Profile – Account
Figure 5B – We can also see the detail for all of the 1,580 objects
organized by folder.
Here is the detail of the 54 objects in the BI Reporting folder that

Duncan Reilly has access to along with his permissions on each object.
Security Profile – Role
Figure 6A – Shows a security profile of a security

object – BI Marketing Everyone.
This shows the memberships of this role in Cognos

along with a summary of all the objects that this role
has access to.
This analysis also provides the detail on all 1,565

objects that BI Marketing Everyone has access to.
An example of this organized by folder is shown in
figure 6B.
Security Profile – Role
Figure 6B – Shows the detail of the 29 objects in the BI

Reporting folder that BI Marketing Everyone has access to along
with permissions on each object.
Security Documentation by Object
Figure 7 – Shows the security for the folder

BI Sales.
Being able to toggle between seeing security

for this folder by Role or Account can be
helpful.
Cognos Security Editor
Figure 8A – Having a tool with a built in Security Editor for Cognos can greatly simplify the process of managing security.
And drag and drop capability to manage

changes or additions/deletions in a single
step versus up to 10 or more steps in
Cognos.
Here we see this being dome by adding

three new members to the group Cap
Authors.
Figure 8B – Remove a Role with a simple click.
But also check impact at the account

level before saving the changes.
Figure 8C – Use context menu to create new security objects

and organize the security hierarchy.
Being able to update and modify your Security Model to manage

change and growth is essential to its longevity.
Contact Envisn
© Envisn Information Solutions

www.envisn.com
Learn more about managing
Cognos Security with NetVisn at 233 Ayer Road
www.envisn.com/netvisn Harvard, MA 01451
USA
T: 978-779-0400
F: 978-772-0985
E: info@envisn.com
If you have any questions or would like more

information on any of our other BI products for
Cognos, please don't hesitate to contact us.

Mastering Ibm Cognos Security

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Mastering Ibm Cognos Security

Загружено:

Авторское право:

Доступные форматы

R E V I S E D E D I T I O N

Mastering IBM Cognos Security

3 Namespaces, Groups, Roles and Accounts

Namespaces, Groups, Roles and Accounts

consisting of Groups and Accounts

Account Object Memberships Cognos

number of Accounts. A better way to

which is capable of reporting and analysis of security group

This can be helpful in seeing

Click to see detailed view >

Click to see detailed view >

Group / Role Membership

Granted and Denied Access

Access Permission Inheritance

Click to see detailed view >

Managing IBM Cognos Capabilities and License Compliance

To monitor compliance it is necessary to determine how many

When applied to Package objects however, the Capability

Best Practices for Implementing IBM Cognos BI Security

Managing Content Access

< Return to Article

Figure 2 shows the permissions applied to the folder labeled BI Sales.

< Return to Article

< Return to Article

< Return to Article

Security Profile – Account

Figure 5A – Shows a security profile of a security object –

Security Profile – Account

Here is the detail of the 54 objects in the BI Reporting folder that

Security Profile – Role

Figure 6A – Shows a security profile of a security

This shows the memberships of this role in Cognos

This analysis also provides the detail on all 1,565

Security Profile – Role

Figure 6B – Shows the detail of the 29 objects in the BI

Security Documentation by Object

Figure 7 – Shows the security for the folder

Being able to toggle between seeing security

Cognos Security Editor

And drag and drop capability to manage

Here we see this being dome by adding

Cognos Security Editor

Figure 8B – Remove a Role with a simple click.

But also check impact at the account

Cognos Security Editor

Figure 8C – Use context menu to create new security objects

Being able to update and modify your Security Model to manage

© Envisn Information Solutions

If you have any questions or would like more

Вам также может понравиться