Authentication and Authorization
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
The security model in Microsoft Office Project Server 2007 is essentially a superset of the security model in Microsoft Office Project Server 2003, but is based upon the common security features of Windows SharePoint Services 3.0. Users can log on to Project Server with Windows authentication, for single sign-on across all parts of Microsoft Office SharePoint Server 2007 and other applications that take advantage of the Windows SharePoint Services security model. Users can also log on to Project Server using Windows SharePoint Services Forms authentication for Project Server accounts.
Authentication for Project Server
Project 2007 can be thought of as a 3-1/2 tier system, where the front-end user interface is separate from the application services tier of the Web server.
The front-end user interface applications are Microsoft Office Project Professional 2007, Internet Explorer, or a third-party application.
The user interface tier is Project Web Access.
The application server tier is the Project Server Interface (PSI), which is the API for the Project Server business objects.
The back-end tier includes the Project Server Queuing and Eventing services, data access layer (DAL), and the databases.
All communication from the front-end Web server user interface and external components is authenticated. User authentication does the following:
Proves the user is who the user claims to be.
Establishes whether the user is valid on the network and on Project Server.
If a client application includes a user interface, it can authenticate the user directly through the Project Web Access logon Web service or through the PSI Forwarder on a Project Web Access server. The PSI Forwarder sends the user's credentials to Project Server and saves a logon cookie to the local server cache. The PSI Forwarder subsequently checks the logon cookie and forwards client requests to the PSI Web services.
If a line-of-business (LOB) application runs only on a back-end server, it can authenticate as the Project Web Access super user to act on behalf of end users and call the PSI Web services directly without going through the PSI Forwarder.
For more information about Project Web Access Server and the PSI Forwarder, see Project Server Architecture.
Windows and Forms Authentication
Project Server supports both Windows and Forms authentication. Windows authentication uses the standard Windows SharePoint Services authentication component for Microsoft Single Sign-On. A successful logon to Project Server, for example, can also authenticate the user for Office SharePoint Server 2007 and related applications. Windows authentication examines credentials stored in the Active Directory directory service. Forms authentication examines credentials stored in the Windows SharePoint Services administration and the Microsoft SQL Server membership provider databases.
Forms authentication is the equivalent of Project Server authentication in earlier versions. There are several advantages for the new Forms authentication, compared to earlier Project Server versions.
Project Server 2007 does not store authentication information or encrypted passwords in a Project Server database. Windows SharePoint Services manages user credentials and authentication for the entire server farm.
Project Server uses the standard mechanism for authentication provided by Microsoft ASP.NET 2.0 and Windows SharePoint Services. A registered Project Server user with Forms authentication can log on to Office SharePoint Server 2007 with the same account.
Users can log on to Project Server using multiple third-party membership providers.
Administrators can specify different password and user account restrictions for different membership providers. For example, the same user can log on to Project Server with different permission sets when using a Windows account or Forms authentication using a SQL Server membership provider.
If a user can log on with Windows authentication, it is not necessary to add Forms authentication for that user. Creating Project Server users for Forms authentication requires using a tool that can register the user into the following three separate databases:
SQL Server membership provider database, to be authenticated by the ASP.NET 2.0 forms logon page
Windows SharePoint Services administration database, to access Office SharePoint Server 2007 components
Project Server MSP_RESOURCE table in the Published database, to become a registered Project Server user
.gif "Note")
NoteProject Server 2007 supports the SQL Server membership provider for the .NET Framework 2.0. The Project Forms Authentication download includes instructions for migrating Project Server users from previous versions and the PjFormsAuthUpgrade.exe tool to help register users for Forms authentication. This tool is included with Project Server 2007. For more information, see Project Server 2007 Authentication on Microsoft TechNet.
If Windows SharePoint Services authenticates the user with either Windows or Forms authentication, Project Server returns an encrypted cookie to the client or to the PSI Forwarder on a Project Web Access server. Subsequent requests to the PSI use the authentication cookie.
In operation, all clients use one of two ASP.NET pages in Project Web Access for Windows authentication and one of two pages for Forms authentication, depending on whether the logon is through the standard user interface or a Web service. Two .aspx pages provide a standard user interface for Windows or forms logon, and two .asmx pages provide the Web service description for Windows or forms logon. The Project Web Access server can handle all authentication requests through the PSI Forwarder. A client application within the intranet can also directly access the PSI Web services.
A client can host Internet Explorer to use the .aspx logon page and pass user credentials to the PSI as form variables in an HTTP post. A client that uses the PSI or PSI Forwarder Web services passes user credentials as parameters to a function. For more information about Project Server authentication, see How to: Log on to Project Server Programmatically. For more information about the SQL Server membership provider, see How To: Use Forms Authentication with SQL Server in ASP.NET 2.0.
Authorization for Project Server
Authorization does the following:
Determines whether an authenticated identity has the necessary permissions based on roles to access data or perform an operation.
Determines what a user can do.
Project Server security is built on the security architecture of the .NET Framework 2.0. Figure 1 shows the general security objects and relationships.
Figure 1. Project Server security objects and relationships
.gif "Project Server security objects and relationships")
A .NET Principal object fundamentally consists of the identity of a user and the groups to which the user belongs. Project Web Access uses role-based security checks to ensure that users are allowed to view the content of certain pages. PSI methods such as QueueCreateProject also use role-based security because security checks of application data require that objects already exist.
Security groups can be used for both role-based security and for data access security. For example, anyone in a Project Manager group can use QueueCreateProject, and categories within the security group can define what projects a specific user is allowed to manage.
A security principal represents a user the system has identified. A security principal can describe a user represented by a Windows account or an application-level user. The security principal object stores additional information about the user for application-level authentication and authorization.
A category represents a collection of secure Project Server objects, for example, projects p1, p2, and p3. Groups with that category permission would have access to all three projects. Categories can be defined dynamically, for example, "include in this category all projects that my direct reports are working on."
A rule defines a query for a category to determine group membership. Group membership includes static category members and members returned by a query. A rule is type-specific for an object. That is, rules for gathering a collection of projects can be different from rules for gathering a collection of resources.
The concept of a role serves several purposes in Project Server 2007. Specific permissions are not fixed for a category, as they were in Project 2003. Instead, relationships between categories and security groups are attributed. The attributes of a relationship define permissions that users in a security group have when accessing members of a category. A role is a set of permissions. A permission expresses what a user can do at an entity level. Examples of permissions are "open project" or "delegate task."
For more information about Project Server security groups, permissions, categories, and templates, see Using Project Server Security.
See Also
Tasks
How to: Log on to Project Server Programmatically
Concepts
Other Resources
Principal and Identity Objects
Designing Application-managed Authorization
Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication
How To: Use Forms Authentication with SQL Server in ASP.NET 2.0