Relationships Between Roles, Tasks, and Users

Relationships Between Roles, Tasks , and Users

The relationship between items that need to be secured, roles, and users is called a policy. The policy is what is responsible for mapping out the minimum set of permissions required for securing a report item. An individual policy is a mapping of users or groups (principals) with a required role needed for access. Each item in the catalog can have multiple policies defined; however, no single item can have two policies that apply to the same principal.

For example, suppose you have a user named George and you need to grant George access to view reports in the Adventure Works folder. To do so, you specified that George can have the Browser role. After doing this, you created a policy. The policy can be modified by granting more roles to George, hence increasing George's permissions to, for example, Content Manager; however, you cannot create a second policy with George. What you can do is create a group, for example "Adventure Works Content Managers," and place George in that group. You can then give the group the role of Content Manager.

So, in the end, what are George's permissions? Well, because roles are really nothing more then a collection of tasks, George can perform all the tasks that Content Managers and Browsers can perform. This is why the policies are called additive.

By this point, you are probably thinking that security is a lot of trouble. If every item can have a policy, and polices are additive, granting permissions can quickly get out of hand. The thing to remember here is that just because you can do something doesn't mean that you should.

When you apply a policy to a folder, or some other items, you are, by default, applying the same policy to children of that folder/item. This makes it easy to change and apply policies. The recommended best practice is to secure folders within the Report Server catalog. By securing the folder, administrators are securing everything within that folder. This is the same model used in NTFS. Every child item of a folder automatically inherits the parent folder's permissions. Whenever an item's permissions need to change, just break the inheritance and SSRS starts a new policy with that item.