Securing the IBM Cognos 8 BI Environment

Transcription

1 Proven Practice Securing the IBM Cognos 8 BI Environment Product(s): IBM Cognos 8 BI Area of Interest: Security

2 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 This document is maintained by the Best Practices, Product and Technology team. You can send comments, suggestions, and additions to cscogpp@ca.ibm.com.

3 3 Contents 1 INTRODUCTION PURPOSE APPLICABILITY COGNOS CONFIGURATION SECURE INSTALLATION...4 Service Account Temporary Files...5 Encrypting Temporary Files Restricting Access to Cognos Connection AUTHENTICATION PROVIDERS LDAP COGNOS APPLICATION FIREWALL COGNOS CONNECTION USERS, GROUPS AND ROLES Terminology System Administrators Role User Maintenance Role Naming PERMISSIONS Permissions and Permitted Actions Access Permissions for Users Access Permissions for Users Granted and Denied Access Parent Child Permissions...14 Deleting Groups and Roles CAPABILITIES...14 Overview Detailed Errors User Defined SQL...16 HTML Items in Report COGNOS NAMESPACE Built-In Entries Predefined Entries FRAMEWORK MANAGER ADD OR REMOVE OBJECT SECURITY Scope of Object Security Steps to Add Object-Based Security Steps to Remove Object-Based Security ADD PACKAGE SECURITY...24

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

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

6 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 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

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

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

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

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

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

12 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 Permissions and Permitted Actions Permissions Icon Action Read Write Execute Set Policy View all of the properties of an entry, including report specification, report output and other report properties. Also allows creation of shortcuts to the entry. Modify properties of an item. 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. 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. 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.

13 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. Action Add an entry Query the entry properties View the children of the entry Update an entry Delete an entry Copy an entry Move an entry Permissions required Write permissions for a parent entry Read permissions for an entry Traverse permissions for an entry Write permissions for an entry Write permissions for an entry, and write permissions for a parent 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 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 Granted and Denied Access

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

15 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 Overview From the IBM Cognos 8 documentation: The Capabilities tool controls access to Cognos 8 secured functions, such as Administration and Query Studio, and secured features, such as 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 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.

16 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: User Defined SQL This capability is defined in the IBM Cognos 8 documentation as:

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

18 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 - 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 3.4 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.

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

20 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 System Administrators Group in this document for more information. This role can be deployed 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 Consumers Query Users Authors Report Administrators Description Members can read and execute public content, such as reports Members have the same access permissions as Consumers. They can also use Query Studio Members have the same access permissions as Query Users. They can use Report Studio and save public content, such as reports and report outputs Members can administer the public content, for which they have full access. They can also use Report and Query studio

21 21 Server Administrators Directory Administrators Metrics Administrators Metrics Authors Metrics Users Portal Administrators Members can administer servers, dispatchers and jobs Members can administer the contents of namespaces. In the Cognos namespace, they administer groups, accounts, contacts, distribution lists, data sources and printers Members can administer Metric packages and tasks in Cognos Connection Members can create and edit scorecard applications in Metric Studio Members can monitor performance in Metric Studio 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 4 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.

22 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 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

23 23 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 Steps to Add Object-Based Security 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. A 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.

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