Project Server Security–Part 1
Security configuration is a confusing topic for many new and old to Project Server. This series provides a in-depth look at the security model and provides decision points and suggested best practices where applicable. We’ll also work through some common scenarios so that you can see how to best utilize the Project Server security model.
This first post provides an overview of the concepts upon which the rest of the series will build. The subsequent posts will dive into the various components that comprise the security system and how they fit together.
A key piece of advice is to keep things simple. Many times, I’ve had to reset a customer’s security configuration because things had become unmanageable. If you find that you are creating single group-category pairs, you may be working too hard to achieve your security goals.
Let’s Talk Terms
It’s important that you understand the terminology used with regards to security.
Project Server Security has three primary parts and supports three levels of security permissions. It also has the ability to control the data that you can see, based on your organizational position.
The three primary parts of security are:
Users (or User Accounts) typically represent a single person who can log into Project Server. This is important as Project Server security only applies to Users, to control which functions they can perform and which project and resource data they can see.
Users are sometimes used synonymously with Resources, though this is incorrect. Resources can be assigned work in Projects but may not necessarily be able to log into the system. An example would be a generic role based resource. They are added to the plan to show the resource demand. However, they will never log into the system. Users, like the system administrator, are typically not resources.
Groups represent roles within Project Server and the specific functional permissions needed to support those roles. These permissions are called Global Permissions, which is the second level of permission. these permissions define what you can generally do in Project Server. We will discuss the standard roles in greater detail in a later post.
Categories represent pools of Projects and Resource data. The data returned by categories is used to populate Views, like the Project Center. They also contain the security permissions related to allowable actions on the returned data. Hence, these permissions are called Category Permissions, which is the third level of permission. Category Permissions define what you can do functionally to the data you see returned by the Category. In my opinion, these are the most important permissions as they control the ability to create and update data.
You are probably wondering what happened to the first level of permissions? These permissions are called Organizational Permissions, as they impact the entire organization. Organizational Permissions enable the implementer to turn off Project Server functionality for all users, including the administrator.
Lastly, there is a special custom field in Project Server called the Resource Breakdown Structure or RBS. This optional use field is used to capture a data visibility hierarchy. The RBS, when used, filters the visible project or resource data based on a user’s position within the hierarchy. For example, the RBS is used to denote a Resource Manager’s Direct Reports.
Key Entities and Relationships
At the most basic level, the diagram below shows the relationship between key entities. Users derive their allowed functions from the Group. The user also accesses data via Views. The View data derives from the Categories associated with the User’s member Groups.
Therefore, views should only be associated to categories which supply the desired data for the given user role.
The key to understanding the security model is in the relationships between groups and categories. The diagram below outlines the relationships of the out of box security model, where the arrows show the categories associated to each group. Category permissions, set in the relationship, determine what project and resource data appears and how it can be acted upon by a given group of users. Therefore, the category permissions (the intersections) are the most important part of the overall model. A deep dive into this area will be the topic of a future post.
What Security Does and Does Not Control
The Project Server security model controls functionality and data visibility within Project Server and Project Professional. It also automatically manages access to the Project Team Sites created in SharePoint by Project Server when a project plan is published.
Project Server security only applies to Project functionality. Therefore, there is no impact on Business Intelligence Center functionality or in direct SQL database access needed for report development. Special consideration should be taken into account for the handling of confidential projects. For example, if you have configured Project Server to prevent the 2013 Headcount Reduction plan from appearing in Project Center, rest assured, it is likely still visible via the Reporting database and Business Intelligence tools.
The Project Team Site aspect controls the level of access that a Project Team Member has to that Team Site. By default, the Project Owner who is also a member of the Project Manager Group, is the Team Site administrator. If a team member is on the Project team but is not assigned work, they are placed in the Viewer (Read only) role on the Team Site by Project Server. If the team member is assigned to a task, they are promoted to Contributor role on the site, where they can make changes to documents and lists. This permissions synchronization between Project Server and the Project Team Site occurs every time the project is published.
Subsequent posts will cover security configuration in greater detail. Future topics will include understanding the use of the RBS and how to configure Project Server to handle confidential projects.