12 May Project Server Security explained

<Cool cold water>

I seem to spend quite a bit of time, during training courses, explaining (in some depth) how Project Server security works.  People generally understand Groups pretty easily, and then global permissions, but really struggle with the concept of categories, their relationship to groups and category permissions, and what happens is a user is a member of more than one group (and via the groups is associated to the same category twice, but with different permissions).  I’m going to use this post to try and demystify Groups, Categories, Views, Global and Category Permissions, and anything else that crops up using a set of worked examples, and I’ll try and add a few best practices.

Let’s start off with some definitions.

Groups

A group defines a role within an organisation, and the people within that role (who are members of the group) ultimately have similar or the same functionality needs.  Group names should be descriptive, eg Project Managers, Resource Managers, Administrators.

Permissions

Permissions define the functionality that a user is allowed to use in Project Server and define what the user can do to certain projects and resources.  Permissions are split into two distinct groups, the 1st group is called Global Permissions, and the 2nd group is called Category Permissions.  I’ll talk about where these permissions are applied later.

Categories

A category is a subset of the Projects, Resources and Views within the Project Server Database.  A single category might contain only Projects, Resources or Views or a combination of all three items.

User

A user is a representation of a person who logs onto the system and utilises Project Server.  Note that users are not necessarily resources, nor vice-versa.  Users should belong to a Group (or a number of Groups).

1. Setting the default functionality for Project Server

The 1st place to start with Project Server is to set the PWA Permissions within Server Settings, Manage Project Web App Permissions.  You can use this page to deny access to a particular feature or function for all Project Server users, thereby defining the totality of the functionality for the implementation.  By default all permissions are enabled, so it’s a question of disabling the relevant permissions/functionality that you do not require for the particular implementation.  Note all permissions are listed within this screen, they are grouped by “type”, and that Global Permissions are mixed with Category Permissions.

In the above screen shot I have disabled the Status Report Responses and Requests.

2. Setting Global Permissions.

Global Permissions can be associated with a user or a group.  Best practice is to associate Global Permissions with Groups only (associating Global Permissions with a user will lead to an overhead in administration).  To set the Global Permissions for a group, navigate to Server Settings, Groups.  I’m going to review the permissions for the Project Managers’ Group.  Click on the Resource Managers Group, and scroll down to the section called Global Permissions.  Review these permissions, in a default server instance they will look as follows… (note however that it’s not practical to show all permissions here, and that the two by the Status Reports indicate that these permissions have been disabled with the PWA Permissions section)

For the sake of this blog, I’m going to concentrate on a two global permissions and two category permissions in order to explain how everything works; the permissions I’ve chosen are;

Each permission can either be set to Allow; Deny; Soft Deny (neither Allow or Deny is set).  There is an order of precedence with the permissions, where a Deny will override an Allow, and an Allow overrides a Soft Deny (Deny > Allow > Soft Deny).  Note that this precedence is only relevant where a user is a member of more than one group, or a group is associated with more than one category so we can park this idea for now and we’ll return to it later.

Let’s deal with the global permissions.

For the New Project permission, the Allow check box is selected.  Assuming that the user is only a member of the Project Managers Group, then the user CAN create a new project.  This is sensible, Project Managers should be able to create projects.

For the New Resource permission, neither the Allow nor the Deny check box is selected for this permission with the Project Managers Group, so the actual permission is a soft deny.  Assuming that the user is only a member of the Project Managers Group, then the user CANNOT create a new resource.  So by default, Project Managers cannot create new users – this is sensible, only Resource Managers should be able to do that (and administrators of course, but then they can do everything).

The following graphic illustrates the relationship between a user and the group.

3. Categories

As previously stated, a category is a subset of Projects, Resources and Views within the Project Server database.  There are 5 default categories

It is worth getting to know the categories, and the data that exists therein.  For this blog, we’re going to concentrate on the My Projects category.

My Projects contains the following Projects and Resources

Note that the category My Projects is dynamic; and projects and resources will move in and out of the category based on the 3 project and 2 resource conditions set.  Also, each user on the system could have (and is likely to have) a different set of data within My Projects.

The following graphic illustrates the category as is relates to a single user.  Out of all the projects in the database, 7 are part of My Projects.

Note that we have yet to define the permissions (or rights) to the 7 projects defined in the category, just the fact that there are 7!

4 Categories and their relationship to Groups

Categories are associated with groups.

The following table details the default associations

The following graphic illustrates the association between the Project Managers’ Group and the My Projects Category

Hence a user gets access to a set of global permissions by belonging to a group, and they are then associated with a category (set of projects, resources and views) because the group is associated with the category.

5 Category Permissions and their association with a Group

Now comes the crux of permissions.  Each association between a category and a group also brings with it the ability to define any of 22 category permissions to the resources or projects in the category, for that group only.

The two category Permissions that we will concentrate on are;

For the Delete Project category permission, the Allow check box is selected (this is the default setting for the Project Managers’ Group and the My Projects category). Assuming that the user is only a member of the Project Managers’ Group, then the user CAN delete any projects within the user’s My Projects category. Depending on your process, this might be sensible.

For the Edit Enterprise Resource Data category permission, a soft deny condition is set.  Assuming that the user is only a member of the Project Managers’ Group, then the user CANNOT edit any of the enterprise resources within the the user’s My Projects category.

The following graphic illustrates the association between the Project Managers’ Group, the My Projects Category and the Category Permissions applied to the My Projects category when associated with the Project Managers’ Group.

So far so good, given the permissions we’ve looked at, our user can create projects but not resources, and within the projects he has access to (My Projects), he can delete those projects, but he cannot edit any resource data.

6. Let’s begin to get complex

Remember, there are 21 category permissions and 60+ global permissions in total.  Each resource can belong to more than one group, each group can be associated with more than one category, each category can be associated with more than one group, and each category can have a different set of permissions when associated with each group.  So that means the My Projects category, which is associated with the Project Managers, Resource Managers and Team Leads groups, can have different category permissions for each group.  Let’s take our simple example above, dealing with 2 category and 2 global permissions, and associate another category to the group.

The projects within each category will have a different set of permissions (as shown by the blue/red colour outlining the categories above).  Any Project which is a member of both categories will inherit the permissions from both categories, where a Deny will override an Allow, and an Allow overrides a Soft Deny (Deny > Allow > Soft Deny). Note that this precedence is now relevant for the projects which are a member of both categories.

We can build on this complexity further because each user can also belong to multiple groups, each group can have different global and category permissions, and each group can be associated with multiple categories (as previously stated).

7.  Views

Each view can be associated with a category, so now that you understand categories contain a set of data, the view allows you to see the data the as per the defined view.  For example, I might have a category called Finance, associated with all projects (My Organisation), which I have associated the Cost views only.  I would then create a Finance group, associated with the Finance category, and then only members of the Finance group would be able to use the Cost views.

8. Best Practices.

It’s easy to get confused with tracking Project Permissions.  Here are some tips to keep it easy

1. If possible, utilise the standard permissions built in the box.

2. Modify the standard permissions, and then document it!  I have a nicely formatted and colour coded spreadsheet that tells me exactly what I’ve changed.

3. Do not apply permissions or associate categories directly with resources.

Enjoy,  Ben.