Among your most important configuration efforts is mapping your organizational security requirements to Project Server’s security constructs. You must give yourself time to understand the underlying concepts so that you can apply them in a way that meets your requirements and enables easier maintenance.
Project Server provides a flexible set of security management tools. At first glance these may seem obscure and complex. In this chapter, I’ll do my best to render these approachable. In previous chapters, you’ve learned the language of “enterprise” in Project Server. Now it’s time to tackle Project Server’s language of “security.” In this introductory section, I list the terms you’ll come across when you read the Project Server documentation and include brief explanations to get you started. Although the term “permissions” is also used as a stand-alone concept, I’ve chosen to work with one term, “global permissions,” because in practice there seems to be no discernable difference between the two.
Topping the following list is “authentication methods,” which I covered amply in the previous chapter, so look there for anything more than the honorable mention below. Each of the succeeding topics makes up the subject matter of this chapter.
Authentication methods: As covered in Chapter 9, Project Server uses Windows Integrated Authentication as well as its own built-in authentication system.
Global permissions: A collection of permissions that grant access to security objects.
Group: A collection of permissions that can be assigned to a user.
User: An individual logon account in Project Server.
Category: A collection of security objects and, to a more limited extent, permissions that can be assigned to a user or group.
Security object: Software functions, views, and project and resource data, collectively.
Security rules: Access permissions that may be assigned based on Project Server relationships. (I think of them as relationship-based security roles.)