Freigeben über

Security in Project Server 2010–What about Custom Permissions?

  • Artikel

SharePoint Server 2010 handles user authentication through claims processing, which is a new feature for SharePoint and Project Server. SharePoint handles both Windows authentication and Forms authentication for Project Server users. For authorization, you can use the ReadResourceAuthorization and SetResourceAuthorization methods in the Resource service of the PSI. Because you probably don’t often change security authorization settings for users, you would normally go to the Manage Users page in Project Web App to select a user and set the global and category permissions.

The Security business object in Project Server (with programmatic access through the PSI Security service) manages security groups, categories, templates, and the global Project Web App permissions. The Security service can add existing permissions or remove permissions from the sets available for Project Server users. However, the Security service does not have a method for creating a custom permission. For example, if you created a Project Server extension that updates a Siebel CRM system, you might want a custom permission that enabled users to use that extension.

In Office Project Server 2007, you can create custom global and category permissions by modifying security tables in the Published database. Custom permissions show in the PWA lists of permissions, where Project Server administrators can secure the 3rd-party extension the same way they secure other Project Server features. The Walkthrough: Creating and Using Custom Project Server Permissions article is the only SDK example where an exception is made for changing the Published database. 

NOTE: The Project team would like some feedback on the importance of custom permissions. If you need to create custom permissions in Project Server, please respond to this post.

 In Project Server 2010, that process for creating custom permissions still works as it did in Project Server 2007. In future versions of Project Server, no modifications to tables in the Published, Draft, or Archive databases will be supported. Custom permissions and secure links that rely on table modifications still work in Project Server 2010, but that process will be deprecated. As an alternative, you may have to create your own user interface to manage custom permissions, or use claims augmentation in a custom application. For more information, see Claims Provider.

Thanks,
--Jim

For more information about Project Server security, including a discussion of global and category permissions, see the Project Server Security Primer in the Project Server 2007 SDK and Security and protection for Project Server 2010 in TechNet.

Comments

  • Anonymous
    February 17, 2011
    Hi i't issue for us because all MPS addons  ussualy used the custom permission, i't was pretty good for us because the permissions were linked to custom menu items and we were able seamlessly integrate custom sollution with MPS. But what is important we used only global permission there wasn't any business case to implement custom permission for project / resource martin.winzig () autocont cz

  • Anonymous
    February 22, 2011
    I confirm that this is an issue for all of us partners who have built solutions on top of Project Server. Obviously it was very nice, for us and for our customers, to be able to integrate the custom permissions we needed in the standard Project Server permissions. Is this decision a result of the problems there have been migrating 2007 databases with custom permissions?

  • Anonymous
    February 28, 2011
    I have created custom permissions in Project Server and would like to continue to be able to.  It is a very clean way for me to give customers the ability to change the security model.

  • Anonymous
    March 03, 2011
    Quite some development work we did for Project Server 2007, especially in the area of client tools, relies on custom permissions. I would highly appreciate if this capability is restored in Project Server 2010

  • Anonymous
    March 16, 2011
    I would LOVE to see Custom permissions implemented in PS 2010. I see that as a gap in PS 2010 that MS should fill before a vendor does and which adds an additional cost to the organizations.

  • Anonymous
    March 29, 2011
    Comments copied from the Project Customization and Programming forum:

Livia Galeazzi: I'm surprised there are no more reactions. As I already commented on the blog post, that's obviously something we partners will have to find a workaround for. Many custom solutions require custom permissions, and integrating that in the Project Server permissions was an easy and painless way to make it easy for customers to manage and make use of the project server security infrastructure, including AD sync. One use case where we used custom permissions in 2007 is the following: we integrate access to a custom aspx page through the quick launch. However, only users with appropriate permissions should be able to see that additional link. So we would add a custom permission for this (last part of that walkthough: msdn.microsoft.com/.../aa974255(office.12).aspx) Now we can still manage our application's security on our side, but we have no way to add security to links in the Project Server quick launch. We thought about using the SharePoint navigation in combination with audience targeting for this, but because of that issue, that's not going to work: englando.wordpress.com/.../project-server-2010-navigation-bug Of course it doesn't prevent the application from running, but you know customers... they see a link they shouldn't, click, get an authentication error, and instead of reading it, they call the helpdesk. Any clue on how to solve that use case?

Jim Corbin: Implementing custom security in Project Server 2010, and adding a secure link in the Quick Launch that can be hidden from users based on their security settings, still works as described in the Project Server 2007 SDK article. However, custom permissions are not officially supported in Project Server 2010.

Livia Galeazzi: So if I understand well, modifications to the tables MSP_WEB_SECURITY_FEATURES_ACTIONS, MSP_WEB_CONVERSIONS, MSP_WEB_SECURITY_ORG_PERMISSIONS and MSP_WEB_SECURITY_TEMPLATE_PERMISSIONS are not supported anymore and should not be part of our custom solutions. However modifications to the tables MSP_SITEMAP and MSP_SITEMAP_PERMISSIONS in order to create a secure link as documented in the walkthrough are still possible and supported? So we would need to link the security of custom links to one of the standard Project Server permissions instead of a custom permission. Correct?

Jim Corbin: Secure custom links, as described in the SDK article, are supported in Project Server 2007 and continue to be supported in Project Server 2010. They will be deprecated in future versions, so modifications using those processes cannot be carried over. Even so, your customer needs to be aware that CUs and SPs can overwrite changes made in the SQL tables, so the secure links must be tested and perhaps re-implemented after installing an update.

Livia Galeazzi: It's quite understandable that Microsoft wants to avoid any changes made directly in the databases, but I hope we will get a PSI method to do this in next versions. A claim provider isn't the solution in our case, I'm afraid.

  • Anonymous
    May 12, 2011
    This is important.  Please don't disallow.

  • Anonymous
    February 19, 2012
    Agree with all that this is an important capability.  Rather than deprecate, I wish the product team would actually go farther in exposing methods that would traverse category rules and allow us to do full lists of allowed actions by project.  Please remember that one of the strengths of this platform is the ability of developers to build solutions on it.  A core security infrastructure is an extremely important aspect of robust integrated application development.