ReportServer comes with a very powerful and flexible permission system based on Access Control Lists. This flexibility can, however, also be a bit overwhelming and with this tutorial we want to provide a gentle introduction into working with permissions. This tutorial is meant as an addition to the description of permissions in the Administration Guide.
ReportServer organizes users (as most other objects) in a hierarchical structure, the user tree. This allows you to organize users, for example, along the structure of your company: use folders and subfolders for departments and sub-departments and place users into their department folder. Folders within the user tree are also called Organizational Units or OU for short.
Once we have fixed the structure in which we organize users we can start configuring the permissions. For example, we can grant permissions directly to individual users (this is usually not advisable) or you can grant permissions to OUs in which case the permissions are granted to all the users that are within the OU. Note that a user is in the OU if its parent is the OU (i.e., the user is a child node) or if it is a descendant of the OU. For example, all users are within the User Root OU. Thus, if you want to grant a permission to every user, you could grant the permission to the User Root OU.
Besides granting permissions to users or OUs you can also grant permissions to Groups. Groups allow you to directly group users by adding them to a group. Then if you grant permissions to a group, all users within the group will inherit these permissions. When looking at a group configuration you might note that groups can not only contain users but also groups or even OUs. The easiest way to think about this is the following:
From a security management perspective, the terms Group and Role basically refer to the very same thing. The difference is the perspective. A group puts the focus on the members (grouping together members that have something in common). An example could be the group of department heads. When talking about roles the focus is usually on a set of permissions which are grouped together. An example of a role could be a report designer.
When a system provides a role-based security system the roles are usually predefined and the configuration requires you to assign roles to users. ReportServer is does not have a role-based permission system. Instead it allows you to grant permissions to groups, OUs or even to individual users. This, however, means that you can easily simulate a role-based permission system in ReportServer. All that you need to do is to set up groups for the roles that you want to have in your system and then assign roles to users by adding users to those groups.
On a fresh installation of ReportServer you will note a folder within the user manager labeled DEFAULT_ROLES. This folder contains two pre-configured groups that can be used as the basis for a more elaborate role-based permission configuration.
The two default roles that are setup on installation are called Administrators and Users. As the name suggest the Administrators role (note that we speak of a role instead of a group now since we put the focus on the permissions rather than the members) grants full access to the system. That is, any user that is assigned the role (i.e., any user that is a member of the group Administrators) has full access to ReportServer. The Users role on the other hand assigns basic permissions that a "normal" user would need. These include access to the dashboard and teamspace module as well as the permissions to log on to the system and execute reports. We'll have a look at all the different permissions next.
In ReportServer 3.0.1 the role Users is missing the execute permission on the generic security target ReportServer Access. This permission is necessary to login.
So far we have discussed how to organize users in OUs and groups. What we have not yet talked about are how to actually grant (or revoke) permissions.
When discussing ReportServer permissions we need to distinguish between two kinds of permissions: object permissions and generic permissions. An object permission is a permission to access a specific object where an object could be a report or file or datasource or even a user or OU. Object permissions are configured within the corresponding "object trees". That is, permissions on reports are configured within the "report tree" which you can access in the report management module. Generic permission, on the other hand, allow to provide access to specific functionality. For example, a user can have the (generic) permission to access the dashboard module. Generic permissions are configured within the Permissions module of the administration. Let us look at these first (see screenshot on the right).
When opening the (Generic) Permissions module you will see about 20 different permission targets on the left, such as,
The Administration target, for example, controls access to the administration module. Each of the permission targets consists of a single access control list (ACL) which in turn consists of zero or more access control entries (ACEs). In the above screenshot we see that the ACL consists of three ACEs:
| # | Folk | Access Type | Rights |
| 1 | Administrators | rwxdg | |
| 2 | IT | r-x-- | |
| 3 | Admin, Demo | r-x-- |
Each ACE consists of a folk (this is the object to which the permissions are granted/revoked, i.e., a user, group or OU), an Access Type this denotes whether the ACE grants or revokes access and a set of rights.
In the example, the ACE is for the group Administrators it is of type grant/allow (instead of revoke/deny) and it grants all rights: rwxdg. Here rwxdg is short for read, write, execute, delete, grant. The second ACE is for the OU IT and the third ACE is for user Admin, Demo.
As stated in the Administration Guide what is needed in order to use the Administration Module is read access on the Administration target. So how does ReportServer determine whether a user has read access? Let's consider a slightly different set of ACLs.
| # | Folk | Access Type | Rights |
| 1 | Doe, John | -wxdg | |
| 2 | Administrators | rwxdg |
We have a user John Doe and a group Administrators. Let us further assume that John Doe is also member of the Administrators group. The ACL in the example consists of two ACEs, the first one being directly for John, the second for the Administrators group. Note that the two ACEs are of different type: the first is a revoke ACE while the second a grant ACE.
In order to determine whether user John Doe has read access for the ACL ReportServer would proceed as follows. It would check each ACE in turn. For each ACE it checks whether the user in question (i.e., John Doe) matches the ACE's folk. So in our example, the first ACE would be a match. If so, it checks whether the asked for right is part of the ACEs set of rights. If this is the case it decides that the user has the permission in case the ACE is a grant ACE and it decides that the user does not have the permission in case it is a revoke ACE. Now in the example, the first ACE does not specify the read right so ReportServer would continue with the second ACE. Again it would check the folk and find that John Doe is part of the group Administrators. Furthermore the ACE specifies the read permission and, thus, ReportServer determines that the read right is granted. In other words, John Doe has read access.
What about write access? Here ReportServer would find that the first ACE matches John Doe and sets the write right and as the ACE is a revoke ACE ReportServer would rule that John does not have write access. Note that the second ACE is irrelevant in this case because the first matching ACE decides.
There is a final case that we have not yet considered and this is what ReportServer decides in case no ACE matches. In this case ReportServer takes the conservative road and denies access, that is, if no explicit access is granted, access is denied.
The Users role is granted permissions for the following generic targets:
The Administrators role is granted permissions for all the generic targets.
Now that we have covered generic permissions lets turn to object permissions. Object permissions are used to control access to objects stored in the object trees:
Each object within a tree (i.e., each folder and each report, each user, OU or group, etc.) has an attached ACL controlling the acces to that particular object.
ACEs for object permissions are similar to ACEs in generic permissions with one exception: you can leverage the hierarchical setup of objects and define whether ACEs are inherited by child objects. This allows you to also manage complex setups of permissions. Consider the example given in the screenshot of the Confidential folder. The setup here is:
| # | Folk | Access Type | Inheritance | Rights |
| 1 | Administrators | rwxdg | ||
| 1 | User Root | rwxdg |
| # | Folk | Access Type | Inheritance | Rights |
| 1 | Administrators | rwxdg | ||
| 1 | Users | r-x-- | ||
| 1 | ClassicModelCars | r-x-- |
When checking whether a user has x-access (where x is either read, write, execute, delete, grant) on an object, ReportServer will go through the list of ACEs in sequential order starting with the ACEs that are specified at the object and then the ACEs which it inherits. In the example one can see that one of the top-level folders has some ACEs that are marked to be inherited by child folders. Thus, we have the inherited ACEs given access to users in the groups Administrators and Users, as well as the OU ClassicModelCars. Now for the confidential folder we wanted to revoke the access and only grant access to users in the Administrators group. Thus, two ACEs were specified at the object directly, the first one granting the access for any member of the Administrators group and the second revoking access for anybody else. Consequently the inherited ACEs will never be taken into consideration on this folder since the first two ACEs will be able to decide for any user whether it has access or not (every user is in the OU User Root).
Finally, let us quickly establish the permissions that are set for the two default roles in a fresh installation of ReportServer. The Administrators role is, again, granted access to any object. For this the permissions on each root folder in each tree are set. The Users role is granted permissions for the following generic targets:
So much for the introduction to ReportServer's permission system. For further information see the Administration Guide.
