Security Permissions in TCR 2.x

Transcription

1 Security Permissions in TCR 2.x Dan Krissell November 10, 2011 Contents Overview... 2 Authentication... 2 Authorization... 2 Where do I find my users and groups to assign access?... 3 How to implement security permissions... 4 Set the system administrator... 4 Using predefined roles... 5 Assigning permissions directly to users an groups... 6

2 Overview This paper describes how to configure security permissions in TCR 2.x If you have questions or comments, please post them to the TCR message board. Authentication During installation, Tivoli Common Reporting is configured to use the Federated Repository, which is required for authentication to work successfully in Tivoli Common Reporting. When installing Tivoli Common Reporting, the Federated Repository is configured to use Internal File Repository. This repository contains users and groups and is built into Tivoli Common Reporting. It does not require the users or groups to exist anywhere outside Tivoli Common Reporting. For finding users and groups with the reporting portlet, see section "Where do I find my users and groups to assign access?" below. Users and groups in the File Repository are managed under the Users and Groups navigation item in the console: After the installation, you can add an LDAP or Active Directory into Tivoli Common Reporting Federated Repository as an additional source. This step is required for multi system installation of TCR. TIP: Be sure to plug LDAP or Active Directory into the TCR console's federated repository. Users and groups in the federated repository are the only users and groups visible to the reporting portlet. Authorization Authorization to common reporting navigation items in the console is controlled with the tcrportaloperator role. You can manage this role by accessing Users and Groups > User Roles or Users

3 and Groups > Group Roles in the navigation. Any assignments that you make in this area will have no effect on the reporting artifacts. Authorization to the reporting artifacts is performed completely within the Common Reporting pane. This reporting portlet contains reporting-related roles to which users or groups can be mapped. In this portlet, you can also directly assign access to users and groups. The predefined roles in portlet are optional to use. You can either assign users and groups to these roles, create new roles, or simply assign permissions directly to groups and users. The predefined roles are automatically assigned the proper permissions on the reporting objects. Where do I find my users and groups to assign access? From various places within the reporting portlet when assigning permissions, there are two security namespaces. For a single system TCR installation, they are Cognos and VMMProvider: For a distributed TCR installation, VMMProvider is not installed and instead replaced with the namespace chosen by the end user when configuring LDAP. VMMProvider contains all the uers and groups from the federated repository. Use the search link to find users and groups:

4 TIP: In TCR 2.1, if you have a large repository and VMMProvider is not returning all the groups, update the following properties file to disable returning all groups and users. This means administrators will use the search feature to find the groups and users: <install>\..\tipv2\profiles\tipprofile\installedapps\tipcell\ibm Cognos 8.ear\p2pd.war\WEB- INF\lib\VMMprovider.properties The default starting in TCR the default is to not return all groups and users, requiring the administrator to use the search function. TIP: Be sure you are logged in with administrator ID when setting permissions, otherwise you may not see the user and groups are expecting. How to implement security permissions We will describe two approaches of setting permissions on reporting objects. 1. Using the predefined roles (Preferred route) 2. Assigning permissions directly to users and groups Predefined roles should be the option used unless a use case dictates otherwise. In either case, you must first the system administrator must be set. This step is described below. Set the system administrator All users are system administrators by default in order for TCR to work out of the box. You must add your system administrator users or groups and remove everyone. This is detailed at: /ug_cra_i_specifysecuritysettingsafterinstallation.html#specifysecuritysettingsafterinstallation

5 Using predefined roles TCR comes with reporting roles already defined. These roles are defined here: /ug_cra_i_predefinedentries.html#predefinedentries What makes these roles easy to use is that all reporting objects by default have the predefined roles set properly on them. You only need to add users and groups to the roles. To use the predefined roles, remove everyone from all the predefined roles that they exists in, then add your users and groups to the roles. This procedure is described here: /ug_cra_i_specifysecuritysettingsafterinstallation.html#specifysecuritysettingsafterinstallation For example, Launch the Administration UI in reporting: Click the security tab, and under Users, Groups, and Roles, click Cognos: For each role listed, click the properties and remove everyone if it's listed under the members:

6 Click Add and add users and groups where applicable. As mentioned previously the users and groups are in the VMMProvider (or the LDAP provider you created on a distributed TCR installation). Examples of adding users: Users in the Consumer role will have permissions to run and view reports, but no permissions to author reports, or administrator privileges. Reader role users can view reports, with minimal access to anything else Authors can author in both Query Studio and Report Studio. Query Users can author in Query Studio and also consume reports See the link prior in the document for a full list of the predefined roles. Assigning permissions directly to users an groups This is not the preferred method, but for some use cases it's required. An example use case for wanting to assign users or groups directly to reporting objects is if one group will have access to a certain report package, and other groups should not see the reports at all. The predefined roles, talked about in the prior section in this document, are still the preferred method to control the capabilities such as launching Report Studio, but will not be used for report, folder, or package permissions. For controlling access to reports, folders, and packages, the permissions will be updated directly on the objects.

7 With the administrative user, open the properties of any reporting object. The permissions tab lists the access. Click the help link for information on the permission type. There you can add users and groups and assign permissions to them. For example, below tipadmin has authority to save reports in this folder and delete them. where group1 users cannot but they can still run the reports. Other users will not see the folder at all: