Users, groups, roles

[hoapq]

I read IBM Cognos Administration :
1. When I create a new role, I will add the role name and set list members of the role. After that in the tab Permission, I can add other groups, roles and set access permissions for each entries of this role.
I want to ask a role why when I set permission for a role I have to add other groups or roles and set permission for each role.

2.  The guide said: "You create Cognos groups and roles when you cannot create groups or roles in your authentication provider"
=> Is it better to create group in authentication provider rather than in Cognos and why ?

3. In the public folder, I create some folders name "Department A", "Department B". I want user from each department only have right to access their folder. In addition, in a department, only some user have rights to write and read while others users have right to execute, traverser. What should I design roles and groups effectively.

Thanks for your help.

[g.congnos]

3. You can set the right in the folder propreties. I Suggest you to
- create two different roles: the first role can to write and read and the second one can execute and traverse;
- create the group for each department;
- set the filter for each group in the framework;
- add the group into the role;
- add the users into the group;
- add the group into the folder properties.

[MMcBride]

2.  The guide said: "You create Cognos groups and roles when you cannot create groups or roles in your authentication provider"
=> Is it better to create group in authentication provider rather than in Cognos and why ?

It depends...
When I used Access Manager my company only primarily kept the groups within Cognos Connections, We then needed to map the users to the groups and every time a user was added we would have to create the user within Access Manager and then make sure that user was added to all of the Appropriate groups within Cognos Connections.

Now that we leverage Active Directory as our Authentication provider we want 100% of our groups to be managed by the security team so within Cognos we only map AD Groups to Cognos Groups. This way if a user requests access to Cognos once they are added to the correct AD Group they have everything they need.

So from a management perspective putting them in AD groups is much easier for the Cognos team to support, we just manage the groups.

However, we also have an Enterprise License (PVU Based) for our Consumers so from a Cognos Perspective we don't have to worry about how many people have access.
If we had Named Seat Licenses I would want the Cognos team that is concerned with making sure we are compliant to manage what groups individual users have access to.

So... PVU licensing I think Security Provider is better
but... Seat Licensing managing each individual user within Cognos is an easy way to ensure you stay valid on your licensing.

But this is nothing more than my personal opinion I am sure there are Pro's and Con's for both sides.

[CognosPaul]

There's are licensing and efficiency considerations.

Let's take two of my clients.

The first is a very small shop with 30 active users. Everyone can see almost everything, with the exception of a few sensitive fields that only certain employees can see. The users are not very technically advanced, and the remote IT support has an SLA of 2 days for non urgent issues (such as making changes to Active Directory). In this case it is significantly easier for me, as the Cognos administrator, to handle security by creating the poweruser group in Cognos and manually adding the users. So far I've had to make changes to that group twice in three years.

The second client is fairly large. Many offices throughout the country, 1000+ users, security is handled by project, then by org hierarchy. They have multiple distributed environments (certain types of data are not legally allowed to be on the same server as others), and the Cognos admin team is kept very busy. In this case, the admins will create generic "project users" groups in Cognos and in Active Directory. The AD group is assigned to the Cognos group. This allows the project managers (who are not Cognos Administrators) to handle the security through Active Directory. They assign each user to the Project Users group in AD, and that user will immediately have access to the project. Unlike with MMcBride the client does not have a PVU license. They have another AD group that has a master list of exactly who can use Cognos. I don't maintain it, and I don't know who does.

On another note, I have another client that bought another company and just kept on maintaining the other companies AD. So they have two authentication providers for their Cognos. Handling the security by them was the same as with the second client, each AD instance had the "Project Users" group created and added to the Cognos "Project Users" group.

Ultimately it boils down to the size of your organization, how many licenses you have, and how much trouble you want to put your admins through. Do you have multiple projects? Make them manage the project security. Got less than 100 employees with a churn rate of 1 per decade? Well, whichever method is easiest.

[hoapq]

when I edit the permission of a role, it allows me to choose : Override the access permissions acquired from the parent entry.
For example : with Consumer role, I can override:
- All authenticated users : read, Traverse
- Consumers : read, Execute, Traverse
- Directory Administrators : read, Write, Execute, Set Policy, Traverse

why does consumers role have to include All authenticated users and Directory Administrators in their list parents? What rights does a user have if they are Directory Administrators or All authenticated users or Consumers