Microsoft SQL Server 2005 Reporting Services

To continue with the file system analogy, one has to ask what are we actually putting limits on? The answer is who can read, write, and execute on objects within the file system. A cursory glance at Table 18.1 gives a similar perspective. By securing a report item, you are actually putting limits on what actions can be taken using that item. The actions are called tasks in SSRS.

SSRS comes with 25 different tasks. Tasks cannot be added to or taken away from. Table 18.1 has already mentioned the names of a few tasks, such as View Reports and Manage Reports .

Tasks themselves actually encompass a set of underlying permissions. For example, the Manage Folders task actually gives the end user the ability to create, delete, update, and modify a folder and its properties. If a user visits the Report Manager without the permissions to Manage Folders, none of the buttons or UI elements will be enabled.

The underlying permissions are nice to know about, but not very practical, as task is the lowest level of assignment. To get assigned permissions to complete an operation, the permissions have to be implemented into a task. The task or tasks have to then be placed in a role to be performed. Hence, if the View Models task is not included in a role, or the role is not included in a role assignment, users cannot view report models.

Tasks themselves come in two different categories, as follows :

• Item-level tasks Tasks that act on an item in the Report Server catalog, such as folders, models, reports, and resources

• System-level tasks Tasks that can be performed on objects that are not in the catalog but are global in scope, such as site settings and shared schedules

As you might have already guessed, the role is the central tenet of role-based security. Roles are collections of tasks. SSRS comes with a few predefined roles, but administrators can also create roles to suit their needs. A single role can only contain one of the two task types, that is, either item-level tasks or system-level tasks. Because of this, there are item-level roles and system-level roles. A role is only active when it is assigned to a user.

When a user tries to perform an action, the Report Server checks what permissions are required to perform that action. The required permissions are expressed in the roles required for access. It then checks to make sure that the user requesting the action has sufficient privileges to perform that action. Again, the easiest way is to check if the user is either a member of the specified role, or if the roles contain the required tasks and, hence, permissions.