Securing Cognos Folders & Objects
When someone talks about security in Cognos Analytics, there are several things that they could be referring to. "Security" could mean making sure web traffic is encrypted with SSL or which capabilities a particular user has access to. It could also refer to what data a person is able to see. However, today I want to talk about the best practices around Cognos object security. Cognos considers anything contained in Team Content or My Content to be an object. This could be a folder, a dashboard, a report, a data module, or any of the other items that can be created through Cognos.
Let’s start with some terminology background:
Authentication Provider (also called Namespace): A separate application that Cognos connects to for user authorization (login). Several are supported such as Active Directory, OpenID, LDAP, and several others.
User Account: An individual user or service account created in the authentication provider.
Authentication Provider Groups: Created in the authentication provider containing user accounts or other security groups. Typically used across the organization for many different applications.
Cognos Namespace: Contains Cognos groups and roles including several built-in to help with initial security setup. You can also create your own Cognos groups and roles within this namespace.
Cognos Group: Contains members which can include User Accounts, Authentication Provider Groups, or other Cognos Groups
Cognos Role: Similar to Cognos Groups but can also contain other Cognos Roles
The goal of object security is to make sure people have access to the reports and dashboards that they need to see, but that they aren't able to see those that should not have access to. How do we best use the features defined above in creating a security system that does what it needs to while also being easy to understand and maintain?
Planning
The first thing in any complex problem like this is planning. It's really easy to just jump in and start creating groups and roles and setting permissions on folders, but without proper planning, it often ends with inconsistency and security that's almost impossible to maintain. My go-to in this case is usually Excel, but a flowchart could also work.
Let's go through an example. We'll start by listing all of the folders under Team Content. These are typically the different business areas within a company, which is also how security is usually broken down. For some companies with a simple security structure, that may be enough to be able to limit access to the top-level folder. Along with the folders, we can add who needs access to each folder and what they need to be able to do. It might look something like this:
After the initial pass at the top-level folders, we can consider the next level down. Are there folders within these that need to be secured differently? Depending on your folder structure, you might have an area within these for people to share their self-service reports. That folder would need Write permissions. You also might have a separate group within the top level. Take HR for instance, there could be a Payroll department that not everyone in HR should have access to. After reviewing these folders, our new spreadsheet might look like this:
This is a fairly simple example, but you can see how this could grow significantly depending on the number of groups involved and the complexity of the security structure needed. Once we get the basics of what's needed, we can then translate that into actual Cognos security groups and access permissions.
Some companies use the groups from the authentication provider directly to secure the folders. That works ok if you have limited security and a simple mapping between the groups and folders. However, I generally suggest creating a Cognos group to wrap the authentication provider group. This provides some flexibility if you have several groups that translate to the same permissions in Cognos. It also insulates you from authentication provider changes and makes it easier for testing. As a Cognos administrator, you can drop a test user into a particular group to test permissions without getting anyone else involved. Another benefit is that it lets you use your own naming conventions to make it easier to understand. Sometimes authentication provider groups can be a bit cryptic.
Now let’s translate our business requirements into actual Cognos groups and permissions. The naming conventions could be whatever works best for your organization. I like to include the business unit and type of the user. A finance user group would be called "Finance Users", and finance report authors would be in a group called "Finance Authors". These can be broken down to whatever level is needed by including extra department information. For permissions, there are four options to choose from: Read, Run, Write, and Full. Read just allows you open pre-run reports. Run is the most used and is to be able to interact with a report/dashboard. Write allows new content to be written, and Full allows permissions to be set. Administrators have Full access by default, so that permission does not need to be set. This is the spreadsheet with the new columns added for Cognos Groups and Access:
The next step is mapping the Cognos Groups from our spreadsheet to the associated authentication provider groups. This could be simple if the authentication provider groups already exist are well named, or it could be rather complex. Depending on what is available, you may need to request new security groups created in your auth provider.
Here is an example using some made up Active Directory groups:
You can see for the "Cognos General" group I'm using the four main license-based groups. (You’ll find more about setting these up in an upcoming article around capabilities.) I like to use these groups instead of a separate auth provider group because it logically makes sense that if you have a Cognos license, you should be able to access at least the base folders. That way if you don't have a license, you won't be able to see anything.
Implementation
Implementation is pretty simple now that we have everything laid out. Open the Manage panel and go under People --> Accounts and open the Cognos namespace. Here you'll see all of the out-of-the-box Cognos groups and roles. I would suggest creating a new folder for the new groups we're creating. In this case, I'll call it "PMsquare Groups". Navigate into the new folder and click on the New Group icon.
Give the group a name. Click on the three dots (action) menu after the name and go to View Members. Here you can add the auth provider group by navigating to that namespace and searching for the appropriate group name.
Once all the groups are created, we can apply them to the folders.
Open the permissions section of each of the folders, check the override box, and add the Cognos groups as defined in the spreadsheet.
As an example, the Benefits folder should something like this:
All objects within the folder will inherit these permissions, so there's no need to set them any lower. Any time an HR Author adds a new report here, the HR Benefits Users will automatically be able to run it.
Testing
The easiest way to test folder access is to have a test user for each group that's required. That way you can log in as each user and make sure they are able to do what they need. However, getting test users at a lot of companies can be difficult. Many security departments either don't want to create that many test users or don't want user accounts that don’t tie to an actual person. At minimum, we need at least two accounts. One should be an administrator or at least Full access to folders in question (presumably yours), and the other should be a user without any authentication provider groups. That way the user can easily be dropped into any of the groups we created to test their access.
When I test this, I like to have two browser windows open, so I can log in as myself and my test user. This could be either two different browser types (Chrome and Firefox for example) or by using an incognito window. NOTE: If you have a single sign-on, you may need to use the dispatcher URL to get a login page for your test user.
Use your admin account to add the test user to the first Cognos group that was created. In this case, that's "Cognos General". In your other browser, log in as that user and make sure that you can see the Calendars, Samples, and Templates folders. None of the other folders should be visible. Once that's confirmed, log out, and in the admin browser window, add the user to the "Finance Users" Cognos group. In this case, we can leave the user in "Cognos General" because all Cognos users will be included in that one. Log in as the test user again and make sure that the Finance folder is now visible. Continue down the list of Cognos groups. Remove the test user from one and add to the next. Make sure that the test user can see what they need to and are able to write reports where they should. Don't underestimate the amount of time this can take. It's a slow but important process to make sure the folder security is working exactly how you expect.
Conclusion
Comprehensive folder and object security is one of the key features that make Cognos an enterprise reporting standard. Whether you're setting up a brand new environment or working on one that has thousands of objects, make sure you take the time to document and plan. It's really easy to get lost in a web of folders and security without it. Remember to set the security at the highest folder level you can because objects contained will inherit the same security by default.
Finally, take your time testing. Security issues can be hard to track down and costly down the road. Make sure it's set up correctly the first time. If the idea of planning and implementing a detailed security plan isn't your thing, reach out. We'd be happy to provide an overall security review or take it off your hands for good with our SaaS anywhere plan.
We hope you found this article informative. Be sure to subscribe to our newsletter for data and analytics news, updates, and insights delivered directly to your inbox.
