Access Permissions and Credentials

You use access permissions and credentials to secure your organization's data. You specify which users and groups have access to a specific report or other content in IBM® Cognos® software. You also specify the actions they can perform on the content.

When you set access permissions, you can reference both authentication provider users, groups, and roles and Cognos groups and roles. However, if you plan to deploy your application in the future, we recommend that you use only the Cognos groups and roles to set up access to entries in IBM Cognos software to simplify the process.

Permissions and Permitted Actions

The following table describes the access permissions that you can grant or deny.

Table 1. Permissions and permitted actions
Permissions	Icons	Permitted Actions
Read		View all the properties of an entry, including the report specification, report output, and so on, which are properties of a report. Create a shortcut to an entry.
Write		Modify properties of an entry. Delete an entry. Create entries in a container, such as a package or a folder. Modify the report specification for reports created in Report Studio and Query Studio. Create new outputs for a report.
Execute		Process an entry. For entries such as reports, agents, and metrics, the user can run the entry. For data sources, connections, and signons, the entries can be used to retrieve data from a data provider. The user cannot read the database information directly. The report server can access the database information on behalf of the user to process a request. IBM Cognos software verifies whether users have execute permissions for an entry before they can use the entry. For credentials, users can permit someone else to use their credentials. Note: Users must have execute permissions for the account they use with the run as the owner report option.
Set policy		Read and modify the 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.

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

Tip: To ensure that a user or group can run reports from a package, but not open the package in an IBM Cognos studio, grant the user or group execute and traverse permissions on the package. Users also require read permissions on the package to launch studios.

Access Permissions Required for Actions

To perform specific actions, each user, group, or role needs the correct 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.

Table 2. Access permissions required for actions
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

Permissions and permitted actions for Cognos Workspace reports

Cognos Workspace users can or cannot perform actions, depending on their permissions and combinations of permissions for a report, report part, report folder, or workspace objects. The owner of an object is automatically granted read, write, traverse, and execute permissions. If an object is disabled, you must be granted write access in order to see and edit it.

For reports, users with the following access permissions and combinations of permissions can perform the following actions:

Table 3. Report access permissions and permitted actions
Permissions	Permitted actions
Read	Users can view the report in the content pane. Users cannot expand the report to show the report parts. Users cannot drag the report.
Read and Traverse	Users can view the report in the content pane. Users cannot expand the report to show the report parts. If saved output exists, users can drag the report onto the canvas and view the saved output. If saved output does not exist, users cannot drag the report. If they attempt this action, users see the error message in the widget:`The content cannot be displayed. It may have been deleted or you may not have sufficient privileges.` Users can view saved output in the workspace. Users cannot run a live report in a workspace. If they attempt this action, users see the error message: `RSV-CM-0006. The user does not have execute permission on this report.`
Execute	Users can view the report in the content pane. Users cannot expand the report to show the report parts. Users can execute the report, but interactions are not available. Interactions are not available if: a report is dragged to the canvas if a user with execute permissions saves a report, and other users open the report if a user with execute permissions opens a workspace created by other users When saved output cannot be viewed in a workspace, users see the error message: `The content cannot be displayed. It may have been deleted or you may not have sufficient privileges.`
Read and execute	Users can view the report in the content pane. Users can expand the report to show the report parts. Users can execute the report and interactions are available. In the content pane, users cannot save report changes. If users add the report to the workspace and save it, report changes can be saved. If the report is added to the workspace by a person who is not the report owner, that user cannot save changes. The user sees the error message: `The content cannot be saved. You do not have sufficient privileges.`
Read, execute, traverse	Users can view the report in the content pane. Users can expand the report to show the report parts. In the content pane, users can execute the report and interactions are available. Users can add the report to the canvas as either live or saved output. The type of report that is added depends on the default action specified in the report's properties.
Read, write, execute, traverse	Users can view the report in the content pane. Users can expand the report to show the report parts. Users can add the report to the workspace. Users can execute the report and interactions are available. Users can change and save the report. Users can add the report to the canvas as either live or saved output. The type of report that is added depends on the default action specified in the report's properties.
Read, execute, set policy	Users can view the report in the content pane. Users can expand the report to show the report parts. Users can execute the report and interactions are available. In the content pane, users cannot save report changes. If users drag the report to the workspace and save it, report changes can be saved. This action creates a copy of the report. The copied workspace report inherits the permissions from the original report when the user has the set policy permission.

For report parts, users with the following access permissions and combinations of permissions can perform the following actions:

Table 4. Report part access permissions and permitted actions
Permissions	Permitted actions
Read and execute	Users can view the report. Users can expand the report to show the report parts. Users can drag the report part onto the canvas and can execute the report part.

For folders, users with the following access permissions and combinations of permissions can perform the following actions:

Table 5. Folder access permissions and permitted actions
Permissions	Permitted actions
Read	Users can view the folder in the content pane and can read folder properties. Users cannot drag the folder onto the canvas. Users cannot expand the folder to show the contents. Users cannot save workspace objects in this folder.
Traverse	Users can drag the folder onto the canvas. Users can expand the folder to show the contents. Users cannot save workspace objects in this folder.
Write and traverse	Users can drag the folder onto the canvas. Users can expand the folder to show the contents. Users can save workspace objects in this folder.

For workspaces, users with the following access permissions and combinations of permissions can perform the following actions:

Table 6. Workspace access permissions and permitted actions
Permissions	Permitted actions
Read	Users can view the workspace. Users cannot open the workspace.
Read and traverse	Users can open the workspace. With the Traverse permission, users can view the workspace widgets.
Read, write, and traverse	Users can view, open, and save the workspace.

Ownership of Entries

If the user is an owner of an entry, the user has full access permissions 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

You can grant access or deny access to entries. An icon that represents the type of access appears next to the entry name on the Permissions tab. For example, when a group has execute permissions for a report, this icon Execute permissions granted icon appears next to the group name on the Permissions tab for the report. When a group has execute permissions denied for a report, this icon Execute permissions denied icon appears next to the group name.

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 and 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 Software Development Kit. You cannot set permissions specifically for those objects.

Permissions and Deployment

If you are an administrator who is deploying to a target environment, see Deployment.

Capabilities Permissions

If you are an administrator, you set access to the secured functions and features by granting execute permissions for specified namespaces, users, groups, or roles. For more information, see Secured Functions and Features.

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

Accessing Entries Associated with Data Sources Secured Against Multiple Namespaces

Data sources in IBM Cognos software can be secured against multiple namespaces. In some environments, the namespace used to secure the data source is not the primary namespace used for access to IBM Cognos Connection. When you try to access an entry, such as a report, a query, or an analysis, that is associated with a data source secured against multiple namespaces, and you are not logged on to all of the required namespaces, a prompt for authentication appears. You must log on to the namespace before you can access the entry.

When single signon (SSO) is enabled, the prompt for authentication does not appear. You are automatically logged on to the namespace.

This functionality applies to IBM Cognos Viewer only. If a similar situation occurs in an IBM Cognos studio, you must quit your task and log on to all the namespaces that you want to use in the current session.