Introduction

Cognos comes with a lot of built-in groups and roles that are difficult to manage from a security standpoint and do not always cater to the needs of every organization.  PMsquare recommends an intersection approach of capabilities and functional group security to create a flexible and maintainable model for Cognos security.  Although this requires starting from square one, the environment will be easier to administer, maintain and on-board new groups.

Clean up Existing Cognos Security

• Remove all groups and roles within Cognos namespace except, All Authenticated Users, Anonymous, System Administrator and Everyone.

• Ensure that Everyone is not a member of the All Authenticated Users, Anonymous or System Administration

• Disable anonymous access

• Require users to be part of the authenticated namespace in Cognos Configuration

• Implement Single Sign on to improve experience for the user

• Create separate data source sign on for each group requiring access

• Allows data sources to be secured for different groups and allows additional visibility into activities

Define Capabilities and Functional Groups

Cognos access should be determined by two things, the capability level a user is assigned to and the functional group they are part of.  Within the Cognos namespace in the Administration > Security pane, create a folder called, “Capabilities” and a folder called “Functional Groups.”  Each user will belong to one Capability group and one Functional Group.

Capabilities

The Capabilities group an individual user belongs to will define which tools they have access to from the Launch Menu (ie: Query Studio, Report Studio, Workspace, etc.). The Capabilities folder will contain a group for each level of access in your organization. The number of different groups depends on how you want to allocate access within your organization.  The following illustrates a simple example of different groups and their corresponding roles:

After deciding on the different levels of access, navigate to the capabilities section of Cognos administration and define what permissions each level has for a given capability. For example, you may give only give Advanced Report Developers and Administrators the Schedules capability, whereas all levels may have access to the Mobile capability. 

Functional Groups

The Functional groups define what content users are able to access. Ideally this is able to be secured at a folder level.  Some examples of functional groups would be:

• Finance

• Accounting

• Human Resources

• Marketing

After creating your different functional groups, edit the permissions on the public folders based on which groups should have access. The available options are Read, Write, Execute, Set Policy and Traverse. Below is a breakdown of the different permissions.

Special Cognos Security Scenarios

1. To give users the ability to see a report schedule, view “My Activities and Schedules” from the My Area > Options menu, and the ability to run a report in the background with options

• Schedule top level capability execute and traverse but all sub capabilities just traverse

1. Often times we encounter requests from clients who want to give their users Workspace Advance but not Workspace or Report Studio. This is a good starting point for new developers so they can start with a more simplistic tool without information overload.

• User Interface Profile Settings

  • Execute and Traverse for the Express User Interface Profile

  • No permissions on the Professional User Interface Profile

• Capability Settings

  • Execute and Traverse on the Report Studio capability

  • No permissions on the Executive Dashboard capability

  • Execute and Traverse on the Use Advanced Dashboard features (sub capability of Executive Dashboard)

  • Execute and Traverse on the Use Interactive Dashboard features (sub capability of Executive Dashboard)

1. To disable the ability to write SQL in reports, but maintain the ability to execute any reports already existing that have custom SQL

• Very inconvenient but not possible in versions prior to 10.2.2. One work around is to execute the report with therun as owner option checked.

1. Enable a user to traverse a folder but not see it. This frequently comes up when packages reside within a restricted Administration folder. Users need to be able to execute reports against the packages, but shouldn’t see the admin folder.

• Edit the system.xml file to re-define the traverse permission within the visible parameter. By removing the snippet of code: permissions("traverse") users are able to traverse the Administration folder to Packages, but they won’t see it!

1. Instead of hardcoding filters, utilize parameter maps in your Framework Model. These can be dynamic, based on environment session parameters. If you’re utilizing a customizable LDAP for security, you can also add custom environment session parameters. These are defined on the LDAP side and incorporated into Cognos via Cognos Configuration. The following are examples of custom LDAP security providers:

• Microsoft Active Directory

• Sun Java System Server

Conclusion

I hope you found this article on Cognos security smarts useful.  In summary, there are a multiple ways to customize security and even more critical factors to consider when establishing security parameters.  Each environment requires a unique security scheme with varying degrees of flexibility and customization.  A key consideration is that sometimes more is well, more.  Taking a one-size-fits-all approach to Cognos security is an unnecessary risk.  If you haven’t already, be sure to subscribe to the PMsquare Journal for more technical articles and updates delivered directly to your inbox.

Next Steps

If you have any questions or would like PMsquare to provide guidance and support for your analytics solution, contact us today.