...

Securing the IBM Cognos 8 BI Environment Proven Practice

by user

on
Category: Documents
1

views

Report

Comments

Transcript

Securing the IBM Cognos 8 BI Environment Proven Practice
Proven Practice
Securing the IBM Cognos 8 BI
Environment
Product(s): IBM Cognos 8 BI
Area of Interest: Security
Securing the IBM Cognos 8 BI Environment
2
Copyright
Copyright © 2008 Cognos ULC (formerly Cognos Incorporated). Cognos ULC
is an IBM Company. While every attempt has been made to ensure that the
information in this document is accurate and complete, some typographical
errors or technical inaccuracies may exist. Cognos does not accept
responsibility for any kind of loss resulting from the use of information
contained in this document. This document shows the publication date. The
information contained in this document is subject to change without notice.
Any improvements or changes to the information contained in this document
will be documented in subsequent editions. This document contains
proprietary information of Cognos. All rights are reserved. No part of this
document may be copied, photocopied, reproduced, stored in a retrieval
system, transmitted in any form or by any means, or translated into another
language without the prior written consent of Cognos. Cognos and the
Cognos logo are trademarks of Cognos ULC (formerly Cognos Incorporated)
in the United States and/or other countries. IBM and the IBM logo are
trademarks of International Business Machines Corporation in the United
States, or other countries, or both. All other names are trademarks or
registered trademarks of their respective companies. Information about
Cognos products can be found at www.cognos.com
This document is maintained by the Best Practices, Product and Technology
team. You can send comments, suggestions, and additions to
[email protected] .
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
3
Contents
1
INTRODUCTION ............................................................................................ 4
1.1
1.2
PURPOSE ............................................................................................................4
APPLICABILITY .....................................................................................................4
2
COGNOS CONFIGURATION ........................................................................... 4
2.1
2.1.1
2.1.2
2.1.3
2.1.4
2.2
2.2.1
2.3
SECURE INSTALLATION ...........................................................................................4
Service Account .................................................................................................4
Temporary Files.................................................................................................5
Encrypting Temporary Files.................................................................................5
Restricting Access to Cognos Connection ..............................................................5
AUTHENTICATION PROVIDERS ...................................................................................6
LDAP................................................................................................................6
COGNOS APPLICATION FIREWALL ...............................................................................7
3
COGNOS CONNECTION ................................................................................. 8
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6
3.3
3.3.1
3.3.2
3.3.3
3.3.4
3.4
3.4.1
3.4.2
USERS, GROUPS AND ROLES .....................................................................................8
Terminology......................................................................................................8
System Administrators Role ................................................................................8
User Maintenance ............................................................................................ 10
Role Naming ................................................................................................... 11
PERMISSIONS..................................................................................................... 12
Permissions and Permitted Actions..................................................................... 12
Access Permissions for Users ............................................................................ 13
Access Permissions for Users ............................................................................ 13
Granted and Denied Access .............................................................................. 13
Parent Child Permissions .................................................................................. 14
Deleting Groups and Roles................................................................................ 14
CAPABILITIES ..................................................................................................... 14
Overview ........................................................................................................ 15
Detailed Errors ................................................................................................ 15
User Defined SQL ............................................................................................ 16
HTML Items in Report ...................................................................................... 17
COGNOS NAMESPACE............................................................................................ 18
Built-In Entries ................................................................................................ 19
Predefined Entries ........................................................................................... 20
4
FRAMEWORK MANAGER ............................................................................. 21
4.1
4.1.1
4.1.2
4.1.3
4.2
ADD OR REMOVE OBJECT SECURITY .......................................................................... 21
Scope of Object Security .................................................................................. 22
Steps to Add Object-Based Security ................................................................... 23
Steps to Remove Object-Based Security ............................................................. 23
ADD PACKAGE SECURITY ....................................................................................... 24
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
4
1
Introduction
1.1
Purpose
This document provides a set of proven practices, to be taken into
consideration when securing the IBM Cognos 8 BI reporting environment. The
recommendations are designed to be as generic as possible, so that they will
benefit the majority of installations, but special consideration must be taken
to ensure that they meet the requirements set out for your deployment.
The intended audience for this white paper are IBM Cognos administrators,
who will be responsible for designing the IBM Cognos 8 architecture and/or
developing the project. The contents are not end user relevant as most of the
recommendations need to be implemented prior to end user roll out.
1.2
Applicability
Although written with both Windows and UNIX servers in mind, the document
examples are Windows based. All techniques and recommendations are
independent of the operating system.
2
Cognos Configuration
2.1
Secure Installation
2.1.1
Service Account
Once installed, IBM Cognos 8, in most cases, will require that a Windows
service be started. To help facilitate network printing, as well as some other
protocols, like Kerberos authentication, the IBM Cognos 8 service should be
started with a named network user account. This account should have
sufficient rights to the local machine to start the service.
To start the IBM Cognos 8 service using a named network account, follow
these steps:
- Open the Windows Control Panel
- Launch ‘Services’, under Administrative Tools
- From the list, double-click on the IBM Cognos 8 service
- On the Log On tab, change the ‘Log on as’ option from ‘Local System
Account’ to ‘This account’
- Browse for the desired user and enter the password
- Press the Ok button
- If the IBM Cognos 8 service is running, it will have to be restarted for
this change to take affect.
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
5
2.1.2
Temporary Files
Like most products, IBM Cognos 8 utilizes temporary files during the course
of ordinary reporting functions. By default, temporary files are written to the
<cognos8_install>\temp folder. This directory is a configurable parameter
that can be modified in Cognos Configuration, as part of the Environment
group properties section. To restrict the access to the temporary files found in
this directory, it is suggested that OS file permissions be set to only allow the
user account, used to start IBM Cognos 8, full control to the directory. All
other accounts should be denied access.
2.1.3
Encrypting Temporary Files
If recently viewed reports contain sensitive data, then extra precaution should
be taken when dealing with temporary files. IBM Cognos 8 offers the ability
to encrypt these temporary files, so that they are unable to be viewed by
unauthorized consumers. The setting to enable temporary file encryption is
found as part of the Environment group properties section. The value should
be set to ‘True’ to enable this feature.
2.1.4
Restricting Access to Cognos Connection
When an external authentication source is added to the IBM Cognos 8
configuration, it is implied that all users in that source will have access to
Cognos Connection. This of course is not always the case within a business.
Now with IBM Cognos 8, the ability exists to restrict access to the Cognos
Connection portal and allow only members of the built-in Cognos namespace
to view the content. By setting the value to ‘True’, the user logging in must
be explicitly part of a group with the Cognos namespace, or a member of a
group in the external authentication source that is a member of a Cognos
group. For more information regarding the Cognos namespace, consult
section 3.4.
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
6
2.2
Authentication Providers
IBM Cognos 8 allows system administrators to leverage various existing
corporate authentication providers. Because of this fact, each provider
interface provided by IBM Cognos 8, may each contain their own set of
recommendations. This next section is divided by authentication provider
type.
2.2.1
LDAP
Once a user has been authenticated to gain access to the Cognos Connection
portal, a user account reference (CAMID) is stored in the content store
database. This CAMID, is partly made up of the value returned from the
attribute mapped to the ‘Unique identifier’ property, in Cognos Configuration.
By default, this property is mapped to ‘dn’ (Distinguished Name). All LDAP
providers will have a value associated to the dn attribute, so this ensures that
all LDAP providers will have a valid attribute on which to base the unique
identifier. This practice however, does not ensure that user accounts are truly
unique. Consider the following scenario.
Company ABC purchased IBM Cognos 8 BI and has successfully rolled out the
product to their user base. An LDAP provider was used to connect to the
corporate Sun One directory server. Because the default IBM Cognos 8 LDAP
provider interface works out of the box with Sun One, no additional
configuration modifications were made, thus their unique identifier was set to
dn.
Vice President of North American Sales, John Q. Smith, a frequent user of
IBM Cognos 8 BI, has been storing sensitive sales and forecasting reports in
his ‘My Folders’ portion of the Cognos Connection portal. Because of the
corporate naming convention of ‘last name, first initial ’, his network user
account is SMITHJ and was created in the North America user folder. This
gives John Q. Smith a dn of:
Uid=SMITHJ, cn=North America, dc=Company ABC, dc=com
So far, business as usual. However, John Smith decides to take a position
with another company, so his user account is removed from the corporate
LDAP hierarchy. A few months later, entry level manager, John X. Smith, is
hired. Based on the naming conventions at Company ABC, John X. Smith
receives a network account of SMITHJ, because it is available. . This gives
John X. Smith a dn of:
Uid=SMITHJ, cn=North America, dc=Company ABC, dc=com
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
7
When John X. Smith logs into Cognos Connection and goes to save a report
to his ‘My Folders’ for the first time, he notices that his folder is filled with
reports containing sensitive data. The reason that this happened, is because
the unique identifier was based on an attribute that MAY not be unique over
time, as demonstrated in the previous example. The only way to ensure that
this type of scenario does not occur, is to use an attribute that is truly unique,
for the unique identifier property. Each LDAP source will have it’s own
attribute, nsuniqueid for Sun One and objectGUID for Active Directory, for
example, that will always have unique values.
Of course, a solid security infrastructure built within Company ABC would
have not allowed for two SMITHJ accounts to have been created, but making
this simple configuration change will add an extra level of security for your
deployment.
NOTE: The attribute mapping must be changed BEFORE applying object
security in the portal and/or allowing users to access IBM Cognos 8. If the
attribute mapping is an afterthought, and is changed later on, all object
security will be nullified and the users will not see their personal content. This
is because, a new CAMID will be created for each user logging in based on
the new attribute for unique identifier, thus creating, in essence, a NEW user
account in the content store. It is also important to note that the attribute
used must be an attribute available for all objects, such as groups,
folders and users. If the selected attribute only exists for users, some objects
will not appear in Cognos Connection when administering the namespace.
2.3
Cognos Application Firewall
Cognos Application Firewall (CAF) is a tool designed to supplement the
existing IBM Cognos 8 security infrastructure. By default, this supplemental
security is enabled. Cognos Application Firewall acts as a smart proxy for the
IBM Cognos 8 product gateways and dispatchers. HTTP and XML requests are
analyzed, modified, and validated before the gateways or dispatchers process
them, and before they are sent to the requesting client or service.
CAF works to protect the IBM Cognos 8 products from processing malicious
data. The most common forms of malicious data are buffer overflows and
cross-site scripting attacks (XSS links), either through script injection in valid
pages or redirection to other web sites.
To ensure that the IBM Cognos 8 solution is as secure as possible, CAF
should NEVER be disabled in a production environment.
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
8
3
Cognos Connection
3.1
Users, Groups and Roles
Users, groups and roles are created for authentication and authorization
purposes. In IBM Cognos 8, you can leverage users, groups and roles created
in third-party authentication providers, and groups and roles created in the
Cognos namespace.
3.1.1
Terminology
In an effort to provide a brief introduction to the various objects that make
up the Cognos Connection security, this section offers a high level description
of the IBM Cognos 8 security objects.
USERS – A user entry is created and maintained in a third-party
authentication provider to uniquely identify a human or computer account.
You cannot create user entries in IBM Cognos 8, as all user entry
management is handled through the various third-party authentication
provider interfaces. The user object is represented by the
icon.
GROUPS – Groups represent collections of users, and other groups, that
perform similar tasks, or have similar status in an organization. Example of
groups ( ) are Employees, Developers or Sales. Group membership is part
of the users’ basic identity. When users log on, they cannot select a group
they want to use for a session. They always log on with all the permissions
associated with the groups to which they belong.
ROLES – Roles ( ) differ from groups in several ways. Members of roles
can be user, groups and other roles. Role membership is not part of the
users’ basic identity.
3.1.2
System Administrators Role
After the successful installation and configuration of IBM Cognos 8, one of the
first steps should be to restrict access to the administrative functions in
Cognos Connection. By default, the ‘Everyone’ group is a member of the
‘System Administrators’ role. This grants ALL users, authenticated or
anonymous, complete access to all aspects of the IBM Cognos 8 portal. In a
multi authentication provider environment, it is good practice to either
designate a couple of accounts as administrators from each provider, or
create accounts in all the providers, for a select few, so that they have access
to all of the namespaces. This recommendation is not applicable if each
namespace will maintain their own distinct set of reports and packages.
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
9
This practice discusses user accounts, but if an administrative group already
exists inside of the authentication source, then this group can be added as a
System Administrator, giving all members of the group full administrative
privileges.
To add an administrative account to the ‘System Administrators’ role, the
following steps can be taken:
- From Cognos Connection, click on the Tools -> Directory link
-
Select the ‘Users, Groups, and Roles tab, if it is not displayed by
default.
-
Click on the link to the Cognos namespace.
This will
display all of the built-in users, groups and roles that are included by
default with the Cognos namespace.
Click on the Set properties icon for the ‘System Administrators’ role
-
-
On the ‘Members’ tab, click on the ‘Add…’ link
Browse the desired namespace to locate the user to be added as a
system administrator. Make sure that the ‘Show users in the list’ check
box is selected
Once the user account has been located, press the arrow icon to add
-
the user to the list of system administrators
Press ‘Ok’
Repeat if necessary
There should now be multiple members of the ‘System Administrators’ role;
the user accounts that were added in the previous steps, and the ‘Everyone’
group. The final part of this process will be to remove the ‘Everyone’ group
from the members list.
- Select the check box beside the ‘Everyone’ group
- Click on the ‘Remove’ link
For more information regarding the Cognos namespace, please consult
section 3.4 of this document.
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
10
3.1.3
User Maintenance
IBM Cognos 8 stores it’s user profiles, and their associated content, in the
content store. In an environment where there are many users, this could
potentially consume quite a bit of space. Users being removed from
authentication sources, is an everyday occurrence at most companies, so why
keep outdated user profiles and content in the content store.
The following best practice assumes that the user profile is deleted in IBM
Cognos 8, PRIOR to removing the user account from the authentication
source.
- From Cognos Connection, click on the Tools -> Directory link
- Select the ‘Users, Groups, and Roles tab, if it is not displayed by
default
- Click on the namespace containing the user account to be deleted
- Locate the user whose profile that needs to be deleted. Use the
‘Search’ feature if the namespace hierarchy is deep and/or the
-
location of the user account is unknown
In the ‘Actions’ column, click the ‘More…’ link
-
Click on the link to delete the profile.
Click ‘Ok’ to confirm the deletion of the user profile
In most environments, the ability to proactively delete a user account may
not be a reality. Fortunately, IBM Cognos 8 provides a mechanism to
synchronize the content store with the underlying user accounts in external
namespaces.
- From Cognos Connection, click on the Tools ->
Content
Administration
- Click on the down arrow on the ‘New Content Maintenance’ button
-
and select ‘New Consistency Check’ link
Enter a name and an optional description and/or screen tip, click
‘Next’
Select the external namespace(s) to be verified by the consistency
check, click ‘Next’
Choose the ‘Run now or at a later time’ radio button and click ‘Finish’
Keep the default ‘Now’ radio button selected and then choose to
either ‘Find only’ or ‘Find and fix’ any inconsistencies
Press the ‘Run’ button
The process will run a consistency check to verify that the content store and
users in the external namespace(s) are synchronized. If any users are no
longer in the namespace, but in the content store, a message will be
displayed like the one below.
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
11
It would be a good practice to create a recurring task to execute this process.
More information on this topic can be found in the ‘Administration and
Security Guide’ found as part of the IBM Cognos 8 product documentation.
3.1.4
Role Naming
To help organize roles, which can become very abundant in a large
deployment, it is recommended to create folders to allow for a logical
separation of the roles. These folder names then assume part of the distinct
name of the role. For instance, two folders could be created and within each
of these folders, a role could be created both having the same name. To
illustrate the previous example, two folders were created within the Cognos
namespace, called ‘Roles East’ and ‘Roles West’. In each folder, a role called
‘Data Administrators’ was created.
Directory > Cognos > Roles East > Data Administrators
Directory > Cognos > Roles West > Data Administrators
Two roles with the same name were permitted because the name of the
parent folder becomes part of the search path (CAMID) for each object.
CAMID(":Roles East:Data Administrators")
CAMID(":Roles West:Data Administrators")
Although this type of naming convention works, and is supported within IBM
Cognos 8, it is not a recommended approach. This technique can easily lead
to mistakes when setting object security as the objects appear to be the
same when displayed in the list of members. If the person applying security
was not aware of the two distinct groups, incorrect access could be granted,
or denied, to an object. As you can see by the following screen capture, there
is no way to properly identify, at a glance, which object is which.
If the deployment absolutely requires roles of the same name to be created,
there is a way via a tool tip, to help identify which role is which. Simply hover
the mouse over the ellipsis (…) and the tool tip will display the full path to the
object.
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
12
3.2
Permissions
With IBM Cognos 8, you can secure Cognos Connection content by setting
permissions on the objects. These access permissions can be set for users,
groups and roles and they also dictate which actions they are able to perform
on the content object. Access permissions can come from both the Cognos
namespace and external namespaces.
3.2.1
Permissions and Permitted Actions
Permissions
Icon
Action
Read
View all of the properties of an entry, including report specification,
report output and other report properties.
Write
Modify properties of an item.
Also allows creation of shortcuts to the entry.
Delete an entry.
Create entries in a container, package or folder for example.
Modify the report specification for reports created in Report and
Query Studio.
Create new outputs for a report.
Execute
Process an entry.
•
For entries such as reports, agents, metrics, the user can
run the entry.
•
For data sources, connections and signons, the entries
can be used to retrieve data from a provider. The user
cannot read the database information directly. The report
server can access the database on behalf of the user to
process a request. Cognos 8 verifies whether users have
execute permissions for an entry before they can use the
entry.
Note: Users must have execute permissions for the account they
use with the run as the owner report option.
Set Policy
Read and modify security settings for an entry.
Traverse
View the contents of a container entry, such as a package or a
folder, and view general properties of the container itself without
full access to the content.
Note: Users can view the general properties of the entries for
which they have any type of access. The general properties include
name, description, creation date, and so on, which are common to
all entries.
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
13
3.2.2
Access Permissions for Users
Users must have at least traverse permissions for the parent entries of the
entries they want to access. The parent entries include container objects such
as folders, packages, groups, roles, and namespaces. Permissions for users are
based on permissions set for individual user accounts and for the namespaces,
groups, and roles to which the users belong. Permissions are also affected by the
membership and ownership properties of the entry. IBM Cognos 8 supports
combined access permissions. When users who belong to more than one group
log on, they have the combined permissions of all the groups to which they
belong. This is important to remember, especially when you are denying
access.
To perform specific actions, each user, group, or role needs the right
combination of access permissions granted for the entry, its parent entry, and its
source and target entry. The following table lists permissions required for
specific actions.
3.2.3
Action
Permissions required
Add an
entry
Write permissions for a parent entry
Query the
entry
properties
Read permissions for an entry
View the
children of
the entry
Traverse permissions for an entry
Update an
entry
Write permissions for an entry
Delete an
entry
Write permissions for an entry, and write permissions for a parent entry
Copy an
entry
Read permissions for an entry and any child entries, traverse permissions for all of
the children, and write and traverse permissions for the target parent entry
Move an
entry
Read and write permissions for an entry, write permissions for both the source
parent entry and the target parent entry, and traverse permissions for the target
parent entry
Access Permissions for Users
If the user is an owner of an entry, the user has full access rights for the
entry. This ensures that users can always access and modify the entries they
own. By default, the owner of the entry is the user who creates the entry.
However, any other user who has set policy permissions for the entry can take
ownership of the entry.
3.2.4
Granted and Denied Access
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
14
You can grant access or deny access to entries. Denied access has
precedence over granted access. When you deny specific users or groups
access to an entry, you replace other security policies that grant access to the
entry. If the grant and deny permissions are in conflict, access to the entry is
always denied. For example, a user belongs to two groups. One group has
access granted to a report and the other group has access denied to the
same report. Access to this report is denied for the user. Deny access only
when it is really required. Typically, it is a better administrative practice to
grant permissions than to deny them.
3.2.5
Parent Child Permissions
Access permissions are acquired from parent entries. If access permissions
are not defined, the entry acquires permissions from its parent entry. You can
replace parent permissions by defining permissions for the child entry.
Objects that exist only as children of other objects always acquire permissions
from their parents. Examples of such objects are report specifications and
report outputs. They are visible through the SDK. You cannot set permissions
specifically for those objects.
3.2.6
Deleting Groups and Roles
When you delete a Cognos group or role, access permissions based on it are
also deleted. You cannot restore them by creating a new group or role with
the same name because this entry has a different internal ID. If your groups
or roles are created by authentication providers, check how your
authentication provider deals with such situations. Typically, you cannot
recreate access permissions if they are based on IDs but you can if they are
based on names.
3.3
Capabilities
IBM Cognos 8 provides security administrators various mechanisms to design
a security scheme within Cognos Connection. Methods such as different types
of authentication providers, object security with granularity down to the user
account, etc. One other aspect to the Cognos 8 security is the use of predefined capabilities. IBM Cognos 8 can be a powerful reporting solution so
special care must be taken when deciding what features should be made
available to the entire user community.
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
15
The following section highlights a few capabilities that should be secured
prior to allowing users to access the system. These capabilities do have a
default membership, so there is some level of restriction around them.
However, the default membership is very generic and should be reviewed to
ensure that it suits the needs of your solution.
3.3.1
Overview
From the IBM Cognos 8 documentation:
The Capabilities tool controls access to Cognos 8 secured functions
,
, such as
such as Administration and Query Studio, and secured features
User Defined SQL and Bursting. Content Manager reads the users’
permissions at logon time. Depending on the permissions, users can access
specific tools, such as Directory, Deployment, Cognos Query Studio, or
Cognos Report Studio, and perform specific actions, such as creating new
reports or changing the SQL statements.
Users can see a list of the secured functions and features available to them in
the portal, in Preferences, on the Personal tab, in the Capabilities section.
When a content store is initialized, the initial permissions for the secured
functions and features are created. The permissions define which of the
predefined and built-in Cognos groups and roles have access to which
secured functions and features, and the types of access. If the initial
permissions do not meet your requirements, you can change the permissions.
However, ensure that the initial settings are modified first.
When a report is run that has the run as owner property set to true, the
permissions of the owner are used, and not the permissions of the user who
submitted the request.
3.3.2
Detailed Errors
IBM Cognos Reportnet saw the introduction of a CAF enabled feature called
SecureError. This feature, when enabled, allowed error messages to be
masked from the end user, by writing all error details to the crnserver.log file.
Details such as server names were thus hidden from the general user
population providing an extra level of security. This however presented
challenges for report creators or power users, because, in most cases, they
would need to contact the system administrator to get the details about any
error messages that were encountered during development.
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
16
With IBM Cognos 8, the SecureError feature is now a capability, called
‘Detailed Errors’ that can be granted to specific groups, roles or named users.
This now takes the burden off of the system administrator and enables report
creators to be more productive.
To add membership to the ‘Detailed Errors’ capability:
- From Cognos Connection, click on the Tools -> Capabilities link
- Click on the Set properties icon for the ‘Detailed Errors’ capability
-
Select the ‘Permissions’ tab
The default membership should be
-
-
Click on the ‘Add…’ link
Browse the desired namespace to locate the user(s), roles or groups
to be added to the ‘Detailed Errors’ capability. Make sure that the
‘Show users in the list’ check box is selected
Once the user, group or role account has been located, press the
-
arrow icon to add the user to the list
Press ‘Ok’
Repeat if necessary
Once the ‘Detailed Errors’ membership has been established, members will
see more verbose error messages. Non members will still need to consult an
administrator who has access to the logs directory on the IBM Cognos 8
server, and they will see errors in the browser similar to the following:
3.3.3
User Defined SQL
This capability is defined in the IBM Cognos 8 documentation as:
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
17
Users can edit the SQL statements directly in the query specification and run
the query specifications that contain the edited SQL statements.
Note: Restrictions on who can use this feature are not enforced in
Framework Manager. For example, a Framework Manager user who does not
have User Defined SQL rights in Cognos Connection can still create a query
subject and use manually created SQL queries to search a database.
To add membership to the ‘User Defined SQL’ capability:
- From Cognos Connection, click on the Tools -> Capabilities link
- Click on the ‘Report Studio’ secured function to expose the sub menu.
3.3.4
-
Click on the Set properties icon for the ‘User Defined SQL’ capability
-
Select the ‘Permissions’ tab
The default membership should be
-
-
Click on the ‘Add…’ link
Browse the desired namespace to locate the user(s), roles or groups
to be added to the ‘User Defined SQL’ capability. Make sure that the
‘Show users in the list’ check box is selected
Once the user, group or role account has been located, press the
-
arrow icon to add the user to the list
Press ‘Ok’
Repeat if necessary
HTML Items in Report
This capability is defined in the IBM Cognos 8 documentation as:
Users can use the button, HTMLItem, and hyperlink elements of the report
specification when authoring reports.
To add membership to the ‘HTML Items in Report’ capability:
- From Cognos Connection, click on the Tools -> Capabilities link
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
18
-
Click on the ‘Report Studio’ secured function to expose the sub menu.
-
Click on the Set properties icon for the ‘HTML Item in Report’
capability
Select the ‘Permissions’ tab
The default membership should be
-
-
3.4
-
Click on the ‘Add…’ link
Browse the desired namespace to locate the user(s), roles or groups
to be added to the ‘HTML Items in Report’ capability. Make sure that
the ‘Show users in the list’ check box is selected
Once the user, group or role account has been located, press the
-
arrow icon to add the user to the list
Press ‘Ok’
Repeat if necessary
Cognos Namespace
IBM Cognos 8 provides a built-in namespace, called the Cognos namespace,
which contains a pre-defined set of users, groups and roles. This namespace
is not tied to an external authentication source and cannot be deleted,
however it may be renamed. In fact, some users and groups may be
removed, while others remain part of core functionality and cannot be
deleted. It is suggested that groups and / or roles be created within the
Cognos namespace, and these groups and roles be used to secure the
content objects.
Once objects are secured against the groups and / or roles in the Cognos
namespace, third party groups and users can be added to the appropriate
Cognos groups and roles. This is a best practice to help minimize the
administration overhead when new users are added or removed from the
underlying security source. When objects are secured against the Cognos
namespace, a user can be added or removed from the Cognos group, which
will change access permissions to all content objects that leverage that
Cognos group. If the Cognos namespace is not used, when a user’s
permissions change in the security source, every object that references that
user object would have to be modified. This could be a daunting task if there
are hundreds of reports within Cognos Connection.
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
19
Use of the Cognos namespace will also prove valuable when moving from one
environment to another. If the Cognos namespace is leveraged, the
underlying security sources can change without impacting the object
permissions. The new users and groups would have to be reassigned to the
appropriate Cognos namespace groups and roles, but the object security
would not have to be reapplied.
3.4.1
Built-In Entries
The built-in entries include the ‘Anonymous’ user account, the groups ‘All
Authenticated Users’, ‘Everyone’, and the role ‘System Administrators’. You
cannot delete the built-in entries. They appear in both secured and nonsecured environments.
Anonymous
This entry represents a user account shared by members of the general
public who can access IBM Cognos 8 without being prompted for
authentication. For example, this type of access is useful when distributing an
online catalog.
Anonymous users can see only those entries for which access permissions are
not set, or are set specifically for this account or for the Everyone group.
You can disable the Anonymous user account by changing the configuration
parameters in the configuration tool.
All Authenticated Users
This group represents users who are authenticated by authentication
providers. The membership of this group is maintained by the product and
cannot be viewed or altered.
You cannot deploy this group. (see the section Including Cognos Groups
and Roles in the Deployment Planning section of the IBM Cognos 8
Administration and Security Guide)
Everyone
This group represents all authenticated users and the Anonymous user
account. The membership of the group is maintained by the product and
cannot be viewed or altered.
You can use the Everyone group to set default security quickly. For
example, to secure a report, you grant read, write or execute permissions to
the report for the Everyone group. After this security is in place, you can
grant access to the report to other users, groups, or roles and remove the
Everyone group from the security policy for this report. Then only users,
groups and roles that have been specified have access granted to the report.
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
20
You can use the Everyone group to apply security during deployment, but
you cannot deploy the group itself. see the section Including Cognos
Groups and Roles in the Deployment Planning section of the IBM Cognos 8
Administration and Security Guide)
System Administrators
This is a special role. Members of this role are considered root users or super
users. They may access and modify any object in the content store,
regardless of the any security policies set for the object. Only members of the
System Administrators role can modify the membership to this role.
The System Administrators role cannot be empty. If you do not want to
use System Administrators, you can create an empty group in the Cognos
namespace or in your authentication provider, and add this group to the
membership of the System Administrators role.
When this role is created during the content store initialization, the group
Everyone is included in its membership. See section 3.1.2 ‘System
Administrators Group’ in this document for more information.
This role can be deployed.
3.4.2
Predefined Entries
The predefined entries include ten Cognos roles. Each of these roles is similar
to any other Cognos role. You can adapt them to your need or delete them.
When the predefined roles are created during the content store initialization,
the group Everyone is member of Consumers, Query Users, and
Authors. If you want to use the predefined roles, we recommend that you
modify their initial membership immediately after installing and configuring
IBM Cognos 8.
The predefined roles include the following.
Role
Description
Consumers
Members can read and execute public content, such as
reports
Query Users
Members have the same access permissions as
Consumers. They can also use Query Studio
Authors
Members have the same access permissions as Query
Users. They can use Report Studio and save public
content, such as reports and report outputs
Report
Administrators
Members can administer the public content, for which
they have full access. They can also use Report and
Query studio
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
21
4
Server
Administrators
Members can administer servers, dispatchers and jobs
Directory
Administrators
Members can administer the contents of namespaces. In
the Cognos namespace, they administer groups,
accounts, contacts, distribution lists, data sources and
printers
Metrics
Administrators
Members can administer Metric packages and tasks in
Cognos Connection
Metrics Authors
Members can create and edit scorecard applications in
Metric Studio
Metrics Users
Members can monitor performance in Metric Studio
Portal
Administrators
Members can administer the Cognos portlets and third
party portlets in Cognos Connection. This includes
importing and customizing portlets, defining portlet
styles, and setting access permissions for portlets
Framework Manager
This section regarding security in Framework Manager was taken from the
IBM Cognos 8 documentation, from the Framework Manager User Guide. For
more information regarding securing Framework Manager content, please
consult the product documentation.
4.1
Add or Remove Object Security
Metadata security can be applied directly to objects in a project. When you
add object-based security, you apply a specific user, group, or role directly to
the object. You choose to make the object visible to selected users or groups.
If you do not set object-based security, all objects in your project are visible
to everyone who has access to the package. When you apply security to one
object, all objects in the model will also have security applied to them. They
will not be visible to anyone. Once you set security for one object, you need
to set it for all objects.
You can make every object in a main project namespace visible to selected
users, groups or roles, except relationships. For example, in your project, you
may have a Salary query subject. You can make the Salary query subject
visible to the Managers group, and keep it hidden from everyone else.
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
22
If a user is a member of multiple user groups and an object is visible to one
user group and denied to the other, the user will no thave access to the
object. For example, Jane belongs to two user groups: Sales and Marketing.
The Sales group has access to the Products and Sales query subjects, and
denied access to the Sales Forecast query subject. The Marketing group has
access to Products, Sales and Sales Forecast query subjects. Jane will not
have access to Sales Forecast.
When you secure an object, a package is automatically created in Framework
Manager. The package name consists of an underscore (_) and the name if
the secured object. These object-based packages are visible in the Explorer.
You can use this package to see which objects in the project are included,
hidden, or excluded from a specific user group.
Every time you include that object in a package, and publish it for report
authors, the same security rules apply for that object. When you publish a
package that contains secured objects, the visible objects for users are the
intersection of the package definition and the object security settings. If
object-based security is not used, security to a package remains unchanged.
4.1.1
Scope of Object Security
The security you specify for an object is passed to shortcuts that reference
the secured object. If you have a shortcut to a secured object, only users
with permissions to see the secured object will be able to see the shortcut in
the published package.
If a model query subject, calculation, or filter references a secured object, the
object’s security is not passed to the model query subject, calculation, or
filter.
When you create a package containing the shortcut, the secured object does
not need to be included in the package.
For example, only sales manager are allowed to see the Sales Target query
subject. You create a shortcut to Sales Target. When you package the model,
you include the shortcut but not the Sales Target query subject. Sales
managers are the only ones able to see the shortcut in the published
package.
Tips
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
23
•
•
•
•
•
•
4.1.2
Steps to Add Object-Based Security
•
•
•
•
A
4.1.3
To see a list of the object-based packages, double-click the Packages
folder. The list appears in the Explorer view. To see which objects are
secured against that specific object-based package, right-click the
package, and click Explore Packages.
To determine if the object-based security is set in the model, right-click
the package, and click Explore Packages. Click the Roles Explorer
tab. If object-based security was set, you see a package for the Everyone
role.
To determine which objects are explicitly secured in the model, look at
the object’s icon in the Project Viewer. The top left corner of the icon is
marked with an overlay.
To find all objects that were explicitly secured under a given object, select
the object and, from the Tools menu, click Find All Secured Objects.
To remove all object-based security for a user, group, or role, delete the
package for the user, group, or role.
To completely remove object-based security from the model, delete the
package for the Everyone role.
Right-click the object you want to secure, and click Specify Object
Security
Tip: More than one object can be selected before the right-click
Select the users, groups, or roles you want to change. Or, click the Add
button to add new users, groups, or roles.
Specify security rights for each user, group, or role by doing one of the
following:
o To deny access to a user, group, or role, select the Deny check
box next to the name for the user, group or role. Deny takes
precedence over Allow.
o To grant access to a user, group, or role, select the Allow check
box.
Tip: To allow everyone to see all objects unless specifically denied access,
select the Allow check box for the Everyone role.
Click Ok.
list of new and updated object-based packages appears.
Steps to Remove Object-Based Security
•
•
•
Right-click the secured object and click Specify Security Rights.
Remove security rights by clearing both the Allow and Deny check
boxes for all users, groups, or roles.
Click Ok.
Cognos Proprietary Information
Securing the IBM Cognos 8 BI Environment
24
A list of new and updated object-based packages appears.
4.2
Add Package Security
You can define metadata security when you create and publish packages in
Framework Manager. You can also define metadata security after creating the
package.
A package is a secured subset of a project. A package can be published and
can be included in other packages.
You can add entries that were created in both third-party authentication
providers and IBM Cognos 8 as members of a Cognos group.
You can organize your security by specifying which users, groups, or roles
have access to certain parts of the published model.
To add metadata security:
• Decide whether the objects can be selected, unselected, or hidden in
the package.
• Add users, groups, or roles to the package.
• Decide which users will have administrative access to a package.
When you apply administrative access to a package, you give access to the
user or users who are responsible for:
• Republishing a package in Framework Manager to the IBM Cognos 8
server.
• Ensuring that no reports are impacted when a Framework Manager
package is republished to the server.
Steps
• Right-click the package you want and click Edit Package Access.
• If you want to create, add, or remove a user, group, or role, click the
User Access tab.
• If you want to grant administrative access to a user, group, or role,
click the Administrator Access tab.
• Click Ok.
Cognos Proprietary Information
Fly UP