Project Server Security Scenarios – Part 1

In this blog series, I’ll talk about implementing some specific security requirements in Microsoft Project Server 2010 / 2013. I’ll assume that you already have some basic idea about Groups, Categories & Permissions but if that’s not the case, you can learn about Project Server 2010 Security Model (also applicable on Project Server 2013) through this excellent article by Ben Howard

Project Server 2013 also offers a new permission mode known as SharePoint permission mode. As the name suggests, it is managed via SharePoint 2013 permissions model. It is a simplified model which can quickly be implemented, but it is not possible to implement the scenarios I am going to cover in this blog and hence the rest of the blog will only talk about classic Project Server permissions mode.

Scenario 1: Bob should access all Projects managed by his Department
By “Project managed by his department”, I mean the projects where the Project Manager belongs to Bob’s department. We don’t want to give access to Bob on the projects where his resources are working as a team member but not managing the projects.

We need to use RBS (Resource breakdown Structure) to define departmental relationships of users. This can mimic the actual organizational hierarchy or it could be a simplified version just to cover projects security requirements.
1) Go to Server Settings -> Manager Users > Bob (or whatever the name of your user is). Set the RBS value of that user at a top departmental level. E.g. Acme.HR
2) All other Project Managers in that department should either be at same RBS level (i.e. Acme.HR) or below it (e.g. Acme.HR.PM)
3) Create a new category called my department Projects. In the Projects Section, use the following settings.
4) The last checkbox is only required if some of the PMs are at the same RBS level as of Bob.
5) In “Views – Add to Category” section, Assign at least 1 Project Center view to this Category, so that Bob can see the Project Name in Project Center.
6) Create a new group called “Department Managers”, Add Bob to this group, and add your newly created category “My department Projects” to Selected Categories section.
7) While “My department Projects” is in selected categories section and it is clicked. You should see Permissions section which is specific for this category. If you want to give Bob the same level of access as of Project Manager then select “Project Manager” in the “Set Permissions with template” Drop down and click apply. You can also give Permissions of Administrator, Team member or any other pre-defined access set.
8) For users of other departments, who want similar access as of bob for their own department’s Projects, You need to setup their RBS values but without creating a new category, you can simply add them to “Department Managers” group.

Scenario 2: Bob should access all Projects managed by his sub-ordinates.

This is the extension of previous scenario. Here Bob instead of being a department manager, could be at any level in an organization. So he could be leading a Business Unit, division or team etc.

As long as your RBS is setup properly (i.e. all subordinates’ RBS value are at level below the RBS value of Bob), the solution will remain same as of scenario 1. For semantic correctness, you may want to use different names for your newly created category and Security group.

In the next part of this blog series, I'll cover scenarios including access to SharePoint based Project Sites and accessing Projects where a certain value for a custom field has been set.


Post a Comment