Chapter 3. User and Permission Management

Like other object types in ReportServer, users and groups are organized hierarchically in trees. The user tree can include the following object types.

• Users Represent individual users of the system
• Groups Arrange users independent of the structure given by the tree
• Organisational Units Serve as folders to structure the user tree

New objects will be created in the user tree via the context menu of the folder node. When clicking on an object in the tree, the right part of the screen will display the properties of this object. The configurable properties vary with the object type.

The name and description fields are available for organisational units. Their name is displayed in the tree, the description field can include additional notes or comments. We will go into more detail explaining the tabs Permission management and User variables in the respective sections.

User objects will hold the personal data of the user. Beside the personal form of address, first and last name, they include the user name, e-mail address and, if applicable, the password. If a password has been manually entered in the Administration interface, it need not be changed by the user on the next login. The usual procedure to reset a password or set a password for the first time is to "activate" the user using the Activate button in the menu bar. One-time password is then sent by e-mail to the user's email address. The user will then be prompted to enter a new password when logging in for the first time.

The guidelines regulating the generation of new passwords, or to which the password chosen by the user has to comply, can by adapted via the configuration of the PasswordPolicy. For further information on PasswordPolicy as well as on the various authentication procedures supported by ReportServer we refer to the configuration guide.

The section Account blocking allows to inhibit individual users from accessing the system. The block can be set either manually or automatically by setting a certain expiration date. Accounts which have been blocked automatically, e.g. by exceeding the permissible number of login attempts, are unblocked and reactivated here.

User groups are mainly used in connection with the permission management, and therefore, they will be discussed in detail under this issue. Groups provide the possibility to summarize users who are not located in the same branch of the user tree, and to treat them equally when assigning rights. Beside the name and description fields, the user group configuration page has three fields to manage the group members. In the Direct Members field, individual users can be added to the group. The field Members (via groups) allows to add all members of another group to this group. The effect is identical, as if the members of the subgroup had been added manually and individually to the group. The field Members (via organisational units) eventually enables to add entire branches of the user tree to a group. Here as well it is to be interpreted that all users given in the branch are direct members of the group.

ReportServer principally distinguishes between two types of permissions. Generic rights are called those permissions which regulate the access to components or functions of ReportServer. Examples for generic rights are the basic right to login to the system, or to access the Admin section.

Beside the generic rights, object related rights can additionally be assigned. They always refer to ReportServer objects organized in tree based data structures such as datasources, reports, users, etc. Unlike generic rights, for the definition of object rights the inheritance of rights can be applied which can considerably reduce the administrative effort when dealing with large and complex user structures.

In ReportServer rights are assigned in form of Access Control Lists (ACL) and Access Control Entries (ACE). An ACL exists for each object for which the access is to be restricted that is an ACL exists for every report, datasource, folder,etc., but also for every generic right. An ACL then consists of a list of ACEs that hold the following information:

• Folk The user object which is granted the permission. This could be a user, a group, or an organisational unit.
• Access type Determines whether the permission entry expands the rights attributed by other entries, or whether it further narrows them.
• Basic rights Basic rights are assignable to all ReportServer objects. Their specific significance depends on the type of the relevant object and will be discussed in the following:

To test if a user has been granted a certain right ReportServer checks for each ACE (in the order they are defined) if the ACE applies to the user, i.e., if the user is part of the folk (i.e., if the folk is a group it is checked if the user is a member in this group, if the folk is an organisational unit, it is checked if the user is part of that sub-tree and if the folk is a user it is tested if the users are the same). If an ACE matches, the access type defines whether the right is granter or denied. This means, that even if an ACE later in the ACL grants a right, but an earlier one denies it, the right is not granted. If no ACE matches then the right is not granted. Consider the following example ACL consisting of three ACEs. The first denies the read and write right for members of group A. The second grants the read right to members of group B and the third grants the write right to members of group C.

group A        deny        read write 
group B       allow        read 
group C       allow        write

To test if a user has the write right, it would first test weather the user is in group A. If so the right is denied and no more checks are performed. In case the user is not in group A, ReportServer would move to check the second ACE to find that it doesn't say anything about the read right. It then goes to the third ACE and tests if the user is in group C. If so, the right is granted. If the user is not in group C, the right is denied as it has not been explicitly granted. This also means, that any user which is not in group B or C would not have any rights on that particular object.

Also let us stress that ACEs are inspected in the order they are defined. This means if we change the above ACL to

group A        deny        read write 
group B        allow        read 
group C        allow        write 
group A        allow        read write

then still, any user that is in group A would not be granted read or write rights, since the check would stop after the first ACE.

Generic rights are configured in the Permission management module located in the Administration module. Here, the second column holds an entry for each generic permission, for example, there is an entry for every ReportServer section for which access can be controlled via generic rights. For each of these entries a single Access Control List is filed, the entries included in this list control the access to the respective function.

To manage the existing permissions, or to add new ones use the buttons Add/Remove. The configuration dialogue for this ACE will open by double clicking on an entry to edit its properties.

To edit generic rights (or object related rights, for that matter), beside the respective rights for the Generic Permission Management section, you require the permission "grant rights (g)" each for the object to which you want to assign permissions. In addition, you must own all the rights yourself that you want to assign.

In the following we discuss the various generic permissions. Note that the target is necessary for checking generic permissions with the haspermission terminal command described in Section 19.26. haspermission.

• Administration. The generic right Administration controls the access to the Administration module. If reading right (r) is granted the user concerned can open the Administration module. The access to Administration sub-modules must be released individually. Rights other than the reading right are not queried. Target: net.datenwerke.gf.service.genrights.AdministrationViewSecurityTarget
• User variables. The user variables right controls the access to the User variables Administration section. Reading right (r) releases the section for reading access. Writing right (w) additionally en- ables to change the configuration. Target: net.datenwerke.rs.uservariables.service.genrights.UserVariableAdminViewSecurityTarget
• User management. The generic right User management controls the visibility of the Administration sub-module for user management. Reading right is requested here, other rights will not be used. The visibility of sections in the user tree and in what way they are visible to or modifiable by a user will be controlled by the object rights in the user tree. Object rights will be discussed in detail in the following section. Target: net.datenwerke.security.service.genrights.usermanager.UserManagerAdminViewSecurityTarget
• Report management. Report management access will be controlled by the generic right report management. Reading right (r) determines whether the respective section is visible in the Administration module. The release of rights in general or detail for individual objects in the report tree will be determined by means of the object rights described in the following section. Target: net.datenwerke.rs.core.service.genrights.reportmanager.ReportManagerAdminViewSecurityTarget
• Dashboard. The generic dashboard right controls the access to the Dashboard module. If reading right is set, the module is visible and can be used in a read only fashion. This means that users can import predefined dashboards but they cannot make any changes or create custom dashboards. If additionally the write permission is granted, users can fully use the dashboard component. Target: net.datenwerke.rs.dashboard.service.dashboard.genrights.DashboardViewSecurityTarget
• Dashboard (admin). The generic right Dashboard Admin controls the access to the Dashboard Library in the Administration module. If reading right is granted the section is visible, the rights to the individual sub-trees of the Dadget library will be controlled by object rights. Target: net.datenwerke.rs.dashboard.service.dashboard.genrights.DashboardAdminSecurityTarget
• File system. The access to the File system section in the Admin module will be controlled via the generic right File system. If reading right is granted the section is visible. The effectively assigned access rights are controlled by setting the respective object right. Target: net.datenwerke.rs.fileserver.service.fileserver.genrights.FileServerManagerAdminViewSecurityTarget
• Datasinks. The datasinks generic right controls the access to the datasinks tree in the Admin module. Reading right is queried for this section to be visible in the Admin module. The actually granted access rights to single datasinks will be controlled by object rights. Target: net.datenwerke.rs.core.service.genrights.datasinks.DatasinkManagerAdminViewSecurityTarget
• Datasources. The datasources generic right controls the access to the datasources tree in the Admin module. Reading right is queried for this section to be visible in the Admin module. The actually granted access rights to single datasources will be controlled by object rights. Target: net.datenwerke.rs.core.service.genrights.datasources.DatasourceManagerAdminViewSecurityTarget
• Remote Servers. The remote servers generic right controls the access to the remote servers tree in the Admin module. Reading right is queried for this section to be visible in the Admin module. The actually granted access rights to single remote servers will be controlled by object rights. Target: net.datenwerke.rs.core.service.genrights.remoteservers.RemoteServerManagerAdminViewSecurityTarget
• Export. The generic right Export determines whether a user is allowed to export objects from a Re- portServer Admin module in the xml format (cf. Export/Import). Executing right (x) is queried. Target: net.datenwerke.rs.eximport.service.genrights.ExportSecurityTarget
• Generic permission management. Access to Generic permission management is controlled via the right Generic permission management. Reading right here controls the visibility of the respective module in the Admin section. To forward rights to individual modules the Grant rights (g) right must have been additionally assigned for the respective section. Furthermore, the user itself must hold the right that it wants to forward. Target: net.datenwerke.security.service.genrights.security.GenericSecurityTargetAdminViewSecurityTarget
• Global constants. The Global constants generic right controls the access to the section Global constants in the Administration module. Here the reading right enables to read the defined constants. For editing the global constants, write permissions are additionally required. Target: net.datenwerke.rs.globalconstants.service.globalconstants.genrights.GlobalConstantsAdminViewSecurityTarget
• Import. The generic right Import grants access to the Import module in the Administration section. The execute (x) right will be checked. Target: net.datenwerke.rs.eximport.service.genrights.ImportSecurityTarget
• License management. The generic right Import grants access to the License Management module in the Administration section. To view the license information the read (r) permission is necessary. To adapt the license information the execute (x) permission is needed. Target: net.datenwerke.rs.license.service.genrights.LicenseSecurityTarget
• ReportServer access. The ReportServer Access right controls who has access to ReportServer, i.e., on login ReportServer checks if the user has the execute (x) right. Target: net.datenwerke.rs.core.service.genrights.access.AccessRsSecurityTarget
• System Console. The generic permission System Console controls the access to the system console in the Administration module. If reading right is granted the section is visible. All system console subsections will be visible if the user has read permission on this generic permission. Note that the "System Console" is an Enterprise feature. Target: net.datenwerke.rs.adminutils.service.systemconsole.genrights.SystemConsoleSecurityTarget
• SU command. Whether the SU function can be used will be controlled via the generic right SU command. The execute right determines whether the user may use this function. Target: net.datenwerke.rs.adminutils.service.su.genrights.SuSecurityTarget
• TeamSpaces. The generic right TeamSpaces controls the permissions awarded for TeamSpaces. Here, the reading right controls the general visibility of the section. The writing right additionally enables the user to create new TeamSpaces. The delete permission allows users to delete TeamSpaces if they either own the TeamSpace or have the administration role for that particular TeamSpace. The specific Administrator permission grants a user administrative rights to all TeamSpaces, which means the user can access all TeamSpaces and has full rights in every TeamSpace. For details on TeamSpaces please refer to the ReportServer user guide. Target: net.datenwerke.rs.teamspace.service.teamspace.genrights.TeamSpaceSecurityTarget
• Terminal. The generic right Terminal controls the access to the terminal window. Here the execute (x) right will be checked. Target: net.datenwerke.rs.terminal.service.terminal.genrights.TerminalSecurityTarget
• Scheduler. The generic right Scheduler controls the access to the user components of the Scheduler module. The reading right enables users to open the Scheduler module in order to edit the orders they scheduled before. The execute right enables to schedule reports. Target: net.datenwerke.rs.scheduler.service.scheduler.genrights.SchedulingBasicSecurityTarget
• Scheduler Admin View. The generic right Scheduler Admin View enables to access the Scheduler module in the Admin section. Here, reading right enables to view the module. The execute right enables to modify scheduling entries. It further allows to change the job executor. Target: net.datenwerke.rs.scheduler.service.scheduler.genrights.SchedulingAdminSecurityTarget
• SFTP. The generic right SFTP enables to access ReportServer via SFTP. Here, execute right enables to access ReportServer via SFTP. Rights other than the execute right are not queried. Target: net.datenwerke.rs.remoteaccess.service.sftp.genrights.SftpSecurityTarget

Besides generic rights, rights can be assigned at a fine granular level down to specific objects (such as, reports, datasources, users, etc.). For such object related rights also ACLs are used. The management of object related rights can be found at the object in question, that is for a report, go to the report management module and access the report. The permission management view can be accessed via the tab Permission management.

Besides the ACE fields that are also available for generic rights, you can take advantage of the hierarchical structure of objects for object related rights. That is, you can decide if an ACE only applies to the object, whether it is inherited by all its descendants, or whether it applies to the current object and is inherited by all descendants.

Object rights can be assigned in the areas Reportmanager, Dashboard Library, Datasources, File System, and User management. In general, the right to read (r) allows users to see (resp. select) the object, the right to write (w) allows to make changes and the right to delete (d) allows users to remove the object. The execute (x) right controls whether a user can execute a report (resp. ReportServer Script). Note that it is not necessary to have read rights to execute. Finally, the grant rights (g) right gives a user the permission to grant rights to other users. Note that users can only grant rights that they themselves hold. Furthermore, they must have read rights for the folk (user, organisational unit or group) to whom they want to grant the right.

To check if a user holds an object related right, ReportServer first checks all ACEs that are assigned at the object in question and which apply to that object. If a decision cannot be made, ReportServer goes on to the parent object and there checks all ACEs which are marked to be inherited by descendants. This process is continued until a decision can be made or the root node has been processed. By default rights ar not granted. We consider the following example:

Object A
+--- Object B
+------ Object C

In the example we consider three objects A, B, and C. Object B is a direct descendant (child) of object A, and object C is a child of B. To test a right on Object C, ReportServer first checks the ACEs defined at C (which also apply to C and in the order they are defined). If no conclusive decision can be made, ReportServer goes on to object B and there checks all ACEs that are marked to be inherited by descendants. If again, no conclusive decision can be made, ReportServer goes on to A. If also here no decision is made, ReportServer will deny the acess.

If a user is given read access for a folder (or any other object) but does not have read access for one of the parents of that object, then ReportServer will display the object as a virtual root in the topmost level.