Reporting Services Security Model

Role-based authorization is not a new concept. It is a proven mechanism that is implemented in a variety of ways. One of the most common, everyday items that uses role-based authorization is the file system. If your PC's file system is based on NTFS, you have the ability to place access control lists (ACLs) on certain folders. ACLs specify users or groups of users (generically called principals), permissions to read, write, or execute items within a folder, or the folder itself. If a folder does not have ACLs placed on it, the folder then simply inherits its permissions from the parent folder. The administrator of the computer can, of course, change access to certain folders, but is not allowed to place himself in the access pool.

Drawing from the file system's paradigm, the SSRS security models it very similarly. Within SSRS, there are a fixed number of predefined roles, which can be assigned to users. These roles are used to give permissions to execute certain tasks on folders or other report items. Examples of some of the built-in roles include Browser, Content Manager, and System Administrator.

When SSRS installs , it sets up the local administrator pool with the System Administrator and Content Manager roles.

This is the absolute minimum security that can be applied. SSRS requires that at least one principal, a valid user or group , be assigned to the System Administrator role, and likewise to the Content Manager role. This ensures that the Report Server cannot be locked out from the outside.

There are no users added. Users cannot interact with the Report Server until someone in the local Administrators group assigns them to either one of the predefined roles, or a custom role.

When the time comes to start adding users, administrators have the choice to add users to a certain role, or to many roles. Users can even have different permissions on different report items. For example, a user might be a Content Manager, which allows the user to publish reports , in one folder, yet only be a Browser (read only) in another folder.

As mentioned in the chapter introduction, SSRS uses Windows authentication by default. The list of valid users and groups rests in the hand of the authentication services. When a user or group (referred to as a principal from this point forward) is added to a role, the principal is validated against the authenticating authority.

On a Report Server, authentication through the Windows security extension (default method) is performed by IIS. The user and group accounts that you specify in role assignments are created and managed through Active Directory.

If a customer security extension is used, it is up to the extension to validate the principal.