Using Project Server Security

Article
05/05/2014

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Microsoft Office Project Server 2007 has a very rich security model, which because of its complexity can initially seem confusing to developers and administrators. Project Server 2007 enables you to create security categories with permissions on projects, resources, and views. The purpose of this article is to clarify the types of permissions and how they operate with users, groups, categories, and security templates. (The content of this article was contributed by Phil Smail, Microsoft Corporation.)

An administrator can make changes in Project Server security using Project Web Access, or a developer can create an application using the Project Server Interface (PSI) to customize and automate repetitive processes for an organization. Following are the basics of using Project Server security:

Plan the groups, security categories, and security templates your organization needs.
Create or modify security categories for the organization. Categories are the main security objects that tie together users and their permissions on Project Server entities.
Create security templates for the organization.
Apply security categories and global permissions to groups, and assign users to one or more groups.
Assign user or group permissions to Project Server entities (business objects) such as projects, resources, and views.
When a user logs on, Project Server grants permissions based on the sum of all assigned user permissions and groups to which the user belongs. In all cases, Deny overrides Allow.

Note
Project Server 2007 does not allow setting permissions on individual custom fields.

Types of Permissions

The series of diagrams in Figures 1 through 9 all use the same style to illustrate security concepts.

Figure 1. Basic components of Project Server security

Basic components of Project Server security

The triangle in Figure 1 represents a user who is allowed or denied the permissions specified in the lower area. The rectangle represents a security category that contains project and resource objects. Category permissions are subtly different from global permissions in Project Server 2007.

Category Permissions

Category permissions are applied to categories and the objects within those categories, such as projects and resources. If a user has the Delete Project permission on Project A, that user has permission to delete Project A—provided the user, or a group to which the user belongs, hasn't been denied Delete Project permission on that project in another category.

Category permissions affect only the user rights for entities that are contained in the category. In Figure 2 for example, if you give Steve Masters the Delete Project permission on the New Projects category, the category does nothing unless you assign projects to it, as shown in Figure 3.

Figure 2. Delete Project permission has no effect because category has no projects

Delete Project permission has no effect

Figure 3. Steve now has permission to delete Project 1 and Project 2

Steve has permission to delete Project 1 and 2

You can apply security categories to individual users and to user groups such as Project Managers.

Global Permissions

Global permissions are set for the entire Project Server environment and are not tied to a particular category. Because they are not tied to a category, global permissions typically allow access to pages in Project Web Access or to functionality that applies more broadly than to particular projects or resources. For example, the New Resource permission allows a user to create a resource within the Project Web Access Resource Center. When a user is creating a new resource and assigns the New Resource permission, the permission obviously doesn't apply to the new resource until after the resource is created.

In Project Server 2007, permissions are separated into groups for global and category permissions (see Figure 14). You can apply Allow and Deny global permissions to individual users and to user groups. You can also apply Allow and Deny settings for both category permissions and global permissions in security templates.

How Permissions Work

To perform a specific task or action, a user or group needs the Allow permission for that task. You can explicitly set permissions for a user or group to Allow or Deny. In addition, you can implicitly set a permission to not allow. Table 1 shows the settings in order of priority.

Table 1. Types of permissions

Setting	Description
Explicit Deny	Deny is explicitly selected for the permission.
Explicit Allow	Allow is explicitly selected for the permission.
Implicit not allow	If neither Allow nor Deny is selected, the user doesn't have access unless they are explicitly allowed elsewhere.

It is important to understand that Deny always has the highest priority. A denied permission applies to a user everywhere that the permission affects. Depending on the type of permission, a denied permission can have a big effect on the user's ability to work with Project Server entities and views.

In Figure 4, suppose the administrator Yoichiro Okada denies Steve Masters the About Microsoft Office Project Server permission. Now Steve can't view the About Project Server page in Project Web Access (although he does not consider that a great loss). Because the permission is global, Steve can't view that page even if another administrator tries to give him the permission.

Figure 4. A global Deny permission overrides all other related settings

Global Deny permission overrides other settings

Yoichiro also decides to deny Steve the View Projects in Project Center permission on the Engineering category (Figure 5). The Engineering category and the New Projects category both contain the Project 1 and Project 2 projects. Therefore, even if another administrator sets Allow for the same permission on the New Projects category (Figure 6), Steve cannot view either project in the Project Center page.

Figure 5. A Deny permission for objects in any category takes precedence

Deny permission takes precedence

As previously stated, Deny always overrides Allow for an object in any category.

Figure 6. An Allow permission for the same objects in another category has no net effect

Allow permission has no effect in this case

Permissions are accumulative. To see what permissions a user actually has on a particular entity, you need to look at more than just the user's settings. You also need to verify security categories and/or groups that affect the user. In Figure 7, Steve Masters has the permissions listed in Table 2.

Figure 7. Building a team on some projects is implicitly not allowed

Building a team is implicitly not allowed

Table 2. Permissions shown in Figure 7

Allow	Implicit not allow
Assign Resource on Resources 1, 2, 3, and 4	Build Team on Project for Project 3 and Project 4
Build Team on Project on Project 1 and Project 2

As always, Deny supersedes other permissions. Even if a user's permission is set to Allow in one category, if the permission is set to Deny on the same entities in another category, Deny is the net result.

In Figure 8, what are Steve Master's effective permissions?

Figure 8. Another example of effective permissions

Another example of effective permissions

Compare your answer to the permissions listed in Table 3.

Table 3. Permissions shown in Figure 8

Allow	Deny
Build Team on Project 1	Build Team on Project 2 and Project 3
Assign Resource on Resource 1	Assign Resource on Resource 2 and Resource 3

Note
A user must have at least the following permissions in order to add a new security category: Log On, Manage Security, and Manage Users and Groups. A user who logs on Project Web Access and has only Manage Security permission cannot add a new security category.

Relationship Between Category and Global Permissions

You must set many of the global- and category-level permissions together to achieve full functionality. However, in some cases there is no relationship between category and global permissions.

Global permissions give a user access to Project Server features or to a page in Project Web Access. Category permissions give a user access to specific projects, resources, and views.

An example where a relationship does occur is in building a team for a project. An administrator must set the following permissions to enable a user to build a project team.

Table 4. Permissions for building a project team

Permission	Permission type
View Team Builder	Global
Assign Resource	Category - Resource
Build Team on Project	Category - Project

View Team Builder is a global permission to access the Build Team page in Project Web Access, but does not give permission to assign specific resources. The Assign Resource category permission determines which resources the user can assign to a project. One additional permission is needed: Build Team on Project specifies the projects where user has permission to assign resources. Build Team on New Project gives the user permission to assign resources if the project doesn't exist yet.

Following is a summary of the required permissions for building a project team:

View Team Builder gives the user access to the Build Team page.
Assign Resource determines which resources the user can assign.
Build Team on Project determines the projects in which the user can add resources.

Figure 9 shows the three permissions that enable a user to assign resources to a project.

Figure 9. Permissions required for a user to build a new project team

Permissions required to build a new project team

A common misconception is that global permissions are just global versions of the category-level permissions. For example, you might think that there would be a global Delete Project permission similar to the category Delete Project permission that enables a user to delete all projects. There is not. Category and global permissions are completely separate sets of permissions.

Note
You can set Delete Project for all projects. For more information, see Categories.

Elements of Security

The elements of Project Server security include users, groups, categories, security templates, and organizational permissions—all available in the Security section of the Project Server Administration page in Project Web Access. Categories can include users and groups along with settings for projects, resources, and views.

The WebSvcSecurity PSI Web service includes the Security class methods and related datasets for programmatically managing security. The WebSvcResource Web service includes the methods to update security, group, and category settings for resources and users.

Project Web Access Permissions

The Project Web Access Permissions page in Project Web Access shows the highest level of permissions for Project Server. You can access Project Web Access permissions from the Server Settings page. The Project Web Access Permissions page displays all of the permissions in collapsible groups such as Admin, Project, Resource, Status Reports, Time and Task Management, and Views (Figure 10). Project Web Access permissions are particularly useful if you want to prevent all users on Project Server from being able to perform a certain function such as Delete Project. To deny a Project Web Access permission, clear the check box.

Figure 10. Project Web Access permissions

PWA permissions

If you deny Delete Project in the Project Web Access permissions list, no users have permission to delete projects regardless of whether they have a Delete Project permission set through a category. However, if you select the Delete Project check box in the Project Server Organizational Permissions page, any user who has that permission set to Allow through a category would be able to delete projects.

When you select a Project Web Access permission, you don't automatically give all users that permission. Rather, you enable a particular permission to be given through a category or as a global permission. If you clear a Project Web Access permission, no users can use that permission.

You can read, create, or modify Project Web Access permissions programmatically using the PSI ReadOrganizationalPermissions and UpdateOrganizationalPermissions methods. It's likely that most Project Server administrators do not need to modify Project Web Access permissions after the initial setup.

Users

Although the term user might seem obvious, it helps to define what a user means in Project Server. Essentially, a user is an entity that can log on to Project Server. A user can be a member of a group, can have category-level permissions, and can be assigned global permissions. A user can also be a resource and can be assigned to tasks within projects.

For information about how to query Project Server for user permissions, see Using Security Methods in the PSI.

Groups

Groups are simply collections of users that logically share common attributes or activities. For example, the Administrators group typically contains all users that administer Project Server and need access to all of the settings. The Project Managers group is the set of users who require a specific set of permissions to manage projects.

A group becomes useful when you want to assign permissions to that logical group of users. For example, if you want to ensure that all administrators have the Delete Project permission, you can assign the Administrators group that permission. You can set category permissions and global permissions for a group.

The PSI methods for managing groups include the following:

For information about how to administer the Project Server security system using the PSI, including how to create a security group, assign a permission, and create a security category, see Using Security Methods in the PSI.

Categories

As previously described, categories contain users and groups that can have permissions on specified entities such as projects, resources, and views. Project Server 2007 does not include custom field access control in categories.

A view in a category restricts the columns and settings of a particular page that a user can access. For example, you can specify a Project Center view in the My Direct Reports category that shows summary, tracking, and work data, but not cost or earned value.

The PSI methods for managing categories and checking for specific security category permissions include the following:

Dynamic Rules

One area of confusion for some administrators is the Dynamic Rules feature, in particular, where a category includes the RBS rules. Dynamic rules determine at run-time which objects, projects, or resources the user has access to in a specific category. With dynamic rules, you do not need to explicitly add projects to a category.

The RBS is an enterprise resource outline code. It is typically used to represent a management hierarchy within an organization either arranged by business structure or geography. You are not required to have an RBS defined for a Project Server installation, but it certainly can help—particularly if you want to allow managers to easily view the work of their resources. For example, Steve Masters has an RBS value of America.North.West.Seattle.Sales; Ben Smith has an RBS value of America.North.West.Seattle. Ben's RBS value enables him to view certain information on users below him in the RBS hierarchy, including Steve Masters.

The first step in configuring dynamic rules is to choose which projects to add to the category. On the Add or Edit Category page in Project Web Access, select one of the two options at the top of the Projects section (Figure 11).

Figure 11. Dynamic rules for projects

Dynamic rules for projects

The meanings of the two options follow:

All current and future projects in Project Server database adds all projects in the Published database to the category. The category filters projects according to the five dynamic rules check boxes below the project list.
Only the projects indicated below means the specified projects in the category can also be restricted further by the dynamic rules check boxes.

If you select any of the dynamic rules (Table 5), users in that category can view only the projects that adhere to the selected rules.

Table 5. Effects of RBS rules for projects

Dynamic Project Rule	Effect
The User is the Project Owner	Gives users permissions on any project they own.
The User is on that project's Project Team	Gives users permissions on any project where they are on the project team. Users do not need to have assignments on the project.
The Project Owner is a descendant of the User via RBS	Gives users permissions on any project that is managed by resources under them in the RBS hierarchy.
A resource on the project's Project Team is a descendant of the User via RBS	Allows a user to view any project where a resource is under them in the RBS and the resource is on the project team.
The Project Owner has the same RBS value as the User	The user can view projects managed by people that have the same RBS value that the user has.

For example, if Steve Masters is the project manager for Project X and Project Y, and you select The User is the Project Owner for a category that includes Steve Masters, Steve then has permissions on both Project X and Project Y (that is, assuming Steve isn't denied access to those projects through another category).

If a new project manager is added under you in the RBS and you select The Project Owner is a descendant of the User via RBS, you now get access to their projects as well—that is, while adhering to all of the permissions.

The dynamic nature of rules has advantages and disadvantages. An advantage is that less management is required when you use rules to select all projects or individual projects for a category. The disadvantage is that it can be difficult to understand which projects your users actually have permissions on. Deciding whether to use dynamic rules, and whether to specify a group of projects or to select all current and future projects, requires that you and your organization analyze which options best fit your business requirements.

In addition to dynamic rules for projects, there are dynamic rules for resources on the Add or Edit Category page (Figure 12).

Figure 12. Dynamic rules for resources

Dynamic rules for resources

The dynamic rules for resources (Table 6) specify the resources whose information users can view, for the users or groups in the category.

Table 6. Effects of RBS rules for projects

Dynamic Resource Rule	Effect
The User is the resource	Gives users permissions to view information about themselves (such as assignments).
They are members of a Project Team on a project owned by the User	Gives users permissions to view information for all resources in projects they own.
They are descendants of the User via RBS	Gives users permissions to view information for all resources under them in the RBS.
They are direct descendants of the User via RBS	Gives users permissions to view information about resources that are directly under them in the RBS.
They have the same RBS value as the User	Gives user permissions to view information about resources that have the same RBS value.

Default Categories

Project Server 2007 includes six categories to which users are added by default (Table 7). For example, when you add a user to a project as a resource, the user automatically becomes a member of the default Team Members group, which has permissions in the default My Tasks category.

Table 7. Default categories for users and groups

Default Category	Default Groups in the Category	Description
My Tasks	Team Members	Primarily used by project resources who have assigned tasks.
My Projects	Project Managers Resource Managers Team Leads	Provides access to all projects a user owns.
My Resources	Resource Managers	Useful only after an RBS is defined.
My Direct Reports	Resource Managers	For users who need to be able to approve timesheets.
My Organization	Administrators Executives Portfolio Managers Project Managers Resource Managers	Primarily used by members of a Project Management Office (PMO) and executives.
My Personal Projects	Executives Portfolio Managers Project Managers Resource Managers Team Leads Team Members	Allows users to create projects on Project Server for their own use.

Security Templates

A security template is a set of global and category permissions settings. It is helpful to use a security template when you want to apply the same settings to many users or groups.

Administrators who have Manage Security permission can create and modify security templates on the Manage Templates page in Project Web Access (http://ServerName/ProjectServerName/_layouts/pwa/admin/ManageTemplates.aspx).

Figure 13. Security templates

Security templates

The PSI methods for managing security templates include the following:

Setting Permissions

You can set Allow and Deny for permissions on the following pages in Project Web Access:

Edit User (…/Admin/AddModifyUser.aspx) includes settings for global permissions.
Add or Edit Group (…/Admin/AddModifyGroup.aspx) includes settings for global permissions and a list for selected security categories.
Add or Edit Template (…/Admin/AddModifyTemplate.aspx) includes settings for both category and global permissions.

You cannot select both Allow and Deny in Project Web Access. If Figure 14, for example, if you had previously selected Allow for Change Project State, and then select Deny, Project Web Access clears Allow. Although selecting both might seem confusing, the permissions rules are still followed. Deny always overrides Allow. Therefore, if both Allow and Deny are set for a permission, the net result is that the permission is denied.

Figure 14. Setting permissions in a security category

Setting permissions in a security category

Note
None of the default Project Server security categories or templates have Deny selected for any permission. You should use Deny carefully; plan and document custom settings in categories and groups for your organization. Deny overrides permission settings in all custom categories and user security settings, and can be a source of difficulty in determining effective rights.

Consider a situation in which you have set the permissions for a number of custom categories and groups within your Project Server installation. A user tries to open a project, but gets an error that he doesn't have permission to perform that operation. Because Open Project is a category permission (Figure 10), you need to find the security category that is denying the user the Open Project permission for that particular project. It is likely that the user is a member of a group where that category is in the Selected Categories list.

You can use the following PSI methods to check whether a user has global or category permissions on specified entities: