With the holidays fast approaching, and my family travel schedule starting to blend into my work travel schedule, it’s been a bit hard to maintain momentum with my blog posts.  Hence, with all due respect to my loyal readers, I am forgoing the brilliant, creative insights you’re used to, and instead mining some of my older 2007 posts to see what needs updating for the new 2010 environment.

This article is based off of a post I did in November 2009 which I am now updating in 2010. The general gist is to present a model for planning and, perhaps more importantly, documenting the Project Server security structure.  Seeing as I spent a couple of years preaching the gospel of ITIL, I am hesitant to call this a “best practice,” but I would go so far out on a limb to call it a “pretty good practice that seems to work for me, and that other folks have actually used with few objections.”

As usual, I welcome any and all recommendations for improvement.  In fact, I am sure that I will be revisiting these ideas at a later date after I’ve got a couple more 2010 installs under my belt.

Here’s the link to the worksheet that I am using.  Note that this was developed in Excel 2010, and as far as I can tell, data validation and lookup tables get a bit squirrely when moving from Excel 2010 to Excel 2007.

***

MOPS 2010 security can be broken out into two major chunks: functional requirements and configuration specifications:

Functional Security Requirements

 

Functional MOPS 2010 requirements must be broken out into language that the Business users (and approvers) will understand.  Typically, what that means to me is a simple matrix with the resource roles on the left, and then the key elements of the MOPS/SharePoint interface along the top.

 

PWA

Project Center

Resource Center

BI
Center

Personal Settings

Server Settings

Project Workspace

Executive Read Only Access Read all projects across the enterprise. No access Can view all reports. No access No access No access
Project Director Read Only Access Read permissions to all projects across the enterprise. View all resources within department.  No edit permissions. Can view all reports. Full access No access Contributor access to all project workspaces in the organization.
Project Manager Read Only Access Read all projects within region.
Write access to own schedules.
View all resources within department.  No edit permissions. Can view specific document libraries. Full access No access Read access to all projects within the organization.  Contributor access to their own projects.
Team Member Read Only Access Can see only projects to which they have been assigned. View their own assignments.  No access to other resources.  No edit permissions. No access. Full access No access Contributor access to their own projects.  No access to other projects.
Functional Manager Read Only Access Read all projects within region.  No write access. View their own reporting resources.  No edit permissions. Can view specific document libraries. Full access No access Read access to all projects within the department.  No access to other projects.
Administrator Full edit permissions Full read/write permissions to all projects Full edit permissions for all resources. Full access. Full access Full access Read/write access to all projects.

 

Additional detail and elements can be added as needed, but generally speaking this may be sufficient to provide adequate documentation of the functional requirements in a single, easy to review format.

Configuration Specifications

Configuration specifications require a lot more time and forethought to develop.  Typically, I’ll use a virtual environment to configure, and in the process develop a security workbook in Excel (see example here).  Once I’ve done that, I’ll use the Playbooks tool to transfer the settings over to the target environment.  (Here’s a post I did a while back on Playbooks in 2007, that I’ll also need to update for 2010.)  That’s a formula that has worked pretty well for me in the past.

2010 adds some security details, but doesn’t significantly change the model from 2007.  To me, the most significant security configuration changes reside in managing security delegation, controlling access to the PDP pages, and the BI Center.  I am still working out my best practices for documenting the first two, but have included the BI Center in the revised workbook.

Here’re a couple of key principles in managing and documenting Project Server security..

1) PWA Settings – To create a workbook for future use, either download the example I have posted, or simply go into the PWA Permissions and right click on the permission list.  You should get an “Export to Excel” option which will allow you to pull all of the security settings into a single Excel worksheet.  Make this your first worksheet in the Security Workbook, and configure appropriately.

image_thumb1

2) Security Templates – The main challenge with documenting Project Server security is that each Group:Category correlation may have its own security settings.  This quickly becomes very difficult to document.  The easiest way to attack this challenge is to create a series of security templates.  Then, as security is assigned to each Group:Category correlation, the appropriate template can be used to define security.  In essence, that reduces the documentation burden to documenting a single table of all security templates, and then a second table of Group:Category correlations.

image_thumb18

Note that I used the following abbreviations for security settings:

image_thumb19

For those of you not familiar with these terms, here’s the rundown:

  1. Allow – one allow box checked.  No deny box checked.
  2. Hard Deny – deny box is checked.  This overrides the allow box if it is checked as well.  No other category or group may grant this specific permission.
  3. Soft Deny – neither allow or deny box is checked.  This means another category or group may grant this permission.
  4. Not Relevant – the functionality is turned off in the PWA settings, and cannot be used throughout the instance.

 

By using only security templates as the basis of your security planning, you can avoid much of the difficulty of documenting the Group:Category security settings.  Typically, I will create a number of security templates, document those in a single worksheet, and then create another worksheet to map the Group:Category correlations, and to identify which security template I use to apply security to that correlation.

Here’s an example:

image_thumb3

Since some categories are RBS bounded, it helps me to note which correlations are filtered by the RBS. I can refer back to my Category Settings worksheet to identify those categories configured to filter projects or resources by RBS settings.

image_thumb5

3) User Groups – As a general rule, I like to create new groups, and not use any of the default groups – which seems to work better, especially when using the Playbooks tool.  If you’re using the RBS, identify to which level each of the groups needs to be set.  That provides a useful reference for you later on when you go create the new resources and wish to validate that you did it correctly.

image_thumb7

4) RBS – If the implementation is using an RBS, I will go ahead and document that in my next worksheet.  Depending on how ambitious I am feeling, when I create the Resource Worksheet, I map it back to this worksheet and create a formulaic check to make sure that each resource, when assigned to a security group, is also assigned to the right RBS level.  This is done by looking up the security group they’re in, and then counting the number of periods in their associated RBS field, to ensure they all match up.  Note that one of the design principles I typically follow is to put each resource into a single security group (if possible).  That may not happen in every implementation, but it makes the administrative burden a lot easier.

image_thumb9

5) Categories – Make a list of all of your Security Categories, and include sufficient description.

image_thumb11

6) Category Settings – Make a table of all of your Category configurations.

image_thumb13

7) Group:Category Mapping – Define the security correlations as discussed in item #2.

image_thumb14

8) PWA Security – Typically the default PWA security settings are way to open for most companies.  I like to ratchet them down.  (Note that I haven’t played with this too much in 2010, but am basing this observation off of 2007 where Project Managers by default had permissions to change the theme of the main PWA page for everybody.)

Note for those new to the Project Server game that the SharePoint security model doesn’t necessarily map to specific user groups in Project Server.  What happens is that SharePoint identifies users based on specific Project Server permissions, and then slots them into specific SharePoint security groups.  So, for instance, anyone with Save Project permissions within Project Server for any project will be slotted into the Project Manager group.

SharePoint by default then uses four groups for synchronized Project Server users:

  1. Project Managers
  2. Team Members
  3. Readers
  4. Web Administrators

 

For more information on how the security is mapped, and what specific permissions drive this mapping, see this Technet article.

image_thumb16

9) BI Center – Since the BI Center is a separate site from the main PWA site, it is governed by its own security settings.  Configure those appropriately, and consider adding library or item level security.  That will have to be the subject of another post.

image_thumb21

The BI Center works much like PWA in the fact that it maps specific Project Server security to SharePoint groups.  More specifically, it maps Project Server Security to PWA SharePoint groups to BI Center SharePoint groups.  For more information on this mapping, please refer to this Technet article.  Note that I do not address SQL permissions in this post, but probably will have to at some point in the future.

10) And that’s about it.  As I develop the security model, I may identify a selection of Administrative Security Procedures which may eventually be required: Phase Gate Review and Baseline Save, Creating New User, Transferring Project Ownership.  Typically, I may drop those into a final worksheet called Administrative Procedures.

image_thumb23

So, in the end, at a minimum, to fully capture the configuration of MOPS 07 security settings, I have a total of 8-9 worksheets in a single workbook that should include all required data to recreate the security configuration in a brand new environment:

  1. PWA Settings
  2. Security Templates
  3. Security Groups
  4. RBS (if used)
  5. Security Categories
  6. Security Category Settings
  7. Group:Category Correlations
  8. PWA Security Settings
  9. BI Center Security Settings
  10. Administrative Procedures (if required)

 

Note that this doesn’t include the security configurations on the Project Workspaces, but that may be a topic for another post.

Sample security planning/documentation workbook posted here.  The document is provided “as is” with no guarantees, warranty, etc.