This post comes to us from Phil Smail, our Project Server Security Program Manager. He understands Project Server security better than anyone since he oversees the design of the implementation. So, Phil wanted to share the solution to a fairly common problem that we experienced internally. With that, here's Phil.
I was asked a question recently on an internal distribution list about how a Microsoft Group should handle their Project Server Security. At first the issue didn’t seem too complex but after a face to face meeting it became obvious that there challenges here but thankfully the Project Server security model was able to work around it. I feel it’s worth spending some time to describe the scenario as it may help others who face similar issues.
Don’t worry, all names are changed to protect the innocent!
This particular Microsoft group, let’s call them Microsoft Group Foo, has a lot of localization work that occurs through external vendors. It’s up to the internal Microsoft folks to assign those vendors to localization projects. Each Vendor has general work resource that can be assigned to these localization work, for example for Vendor A the resource will be called ‘General Vendor A Resource’. Now this is where things get complicated!
Each Vendor has a number of users (not assignable resources) in Project Server who are allowed to edit the project if the Vendor’s general resource is assigned to that Project. They should also be able to assign full time Microsoft folks to the Project as required. It’s not a concern for vendors to see what other vendors are working on the same project but vendors shouldn’t be able to see what other, non-related, projects that other Vendor’s are working on. Got that?
So let’s say we have a User, called Roderick, who is one of the Microsoft Employees. He needs to be able to assign a general resource per vendor to projects. This general resource should be represented by a generic resource with each vendor having their own generic resource. Therefore the Microsoft employee no longer needs to worry about who in the Vendor does the actual work
Now each Vendor has their generic resources but we need to add in the users for each vendor. Let’s say Vendor A has the user David and Vendor B has the User Heather. We know we have the parent-child relationship between the Vendor users and the Generic Vendor resource. It also makes sense for the Microsoft internal folks to have a parent child relationship with all the Vendors
The way we would represent in our security system would be by assigning these users/resources values within the Resource Breakdown Structure (RBS). Both Users and Resources can have RBS values and therefore can all exist in the hierarchy. The RBS is useful as it allows us to use the RBS category rules. These rules allow us to get permissions to Resources and Projects that have some relation with our peer Resources or Resources below us in the RBS. This means we would put the generic Vendor resources below the Vendor users and the Microsoft internal folks above the Vendors in the RBS to allow them the correct permissions on the Resources and Projects
I figured we could represent the RBS structure as such:
Now what about the Categories that would need to be associated here?
First off David and Heather need to be added to a category that gives them Project Manager permissions. The Category rules are more interesting.
The rules they’d definitely need set are:
Project permissions: ‘A resource on the project’s Project Team is a descendant of the User via RBS’.
This rule would allow them to view all Project’s that the general Vendor Resource had been added to the Project Team.
Roderick, and all other Microsoft employees within that group should belong to another category which has the ‘Assign Resource’ permission and the following Category Rule:
Resource permissions: ‘They are descendants of the User via RBS’.
This rule would allow them to assign the general Vendor resources to projects
Now one tricky bit is for the Vendor users, for example David if they become the Project Owner, is how to assign Roderick to a project. The only option would be to create another category which includes David and Heather (and any other users). The would also be given the ‘Assign Resource’ permission. The resources in the category would be the list of Microsoft employees that could be assigned. Unfortunately there’s no way to assign a group as the list of resources so as the list of MS resources changes then this list would need to be manually modified.
So there you have it. An environment now where vendors can only see the projects that they’re assigned to, the Microsoft folks can assign the Vendor’s to projects and the Vendors can assign Microsoft people to those projects
Questions and Answers
Question: The obvious follow up question is how do we take this model further and prevent Vendors from seeing the work that other Vendors are doing on even if they’re on the same Project
Answer: Unfortunately this functionality is not available in Project Server 2007. The only solution would be to create sub projects for each vendor and aggregate into a master project
But let’s think about expanding this further. This solution could be used to support full time employees managing contractors who manage sub contractors! Assuming the contractors are longer term vendors and the sub contractors are short term resources it makes sense to make the sub contractors generic resources under the main contractors. This is super cool!
Question: I have sub contractors who are managed by multiple contractors. How do I cope with that in the RBS
Answer: Unfortunately the RBS based category rules do not support accessing RBS nodes in different branches. That is something we are hoping to improve in future releases. This is where another category containing those sub contractors resources would make sense