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.

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

Ownership of Entries

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

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