New to Microsoft SharePoint Foundation and Microsoft SharePoint Services is claims based authentication. This means Project Server 2010 also gains this authentication addition and improvement as well.
Briefly, claims based systems provide for federated authentication services such as Active Directory Federation Services (ADSF), single sign-on mechanisms and so forth. In a claims-based authentication system a security token exists and is made up of a set of identity assertions about an authenticated user. Assertions are attributes that are associated with a user’s identity. Assertions can include a user name, a role, an employee ID, and a variety of other attributes that can be used to determine authorization. A Security Token Service (STS) responds to authentication requests and creates the token based on account information in various attribute stores. The token is then used to authenticate actions. In essence, claims-based authentication provides flexibility beyond the traditional Windows NTLM/Kerberos authentication method.
For information about what claims authentication is as well as the STS, see the following articles:
Once you understand what claims based authentication is, you may still wonder how it may be useful to or even necessary in a Project Server 2010 installation. For many Project Server 2010 installations, they will be configured to use Windows-legacy authentication which is essentially the same thing as what you have by default in Project Server 2007. That is, Windows Integrated Authentication challenges that use Negotiate (NTLM/Kerberos). In fact, if today your Project Server 2007 server uses Windows Authentication (the default), then there’s nothing you will need to do differently in 2010 – it’ll just work for you once the upgrade is completed. But, here are a number of cases you’ll need to consider that’ll necessitate the use of claims based authentication.
Whether you are migrating from Project Server 2003 to Project Server 2010, Project 2007 to Project Server 2010, or are new to 2010, use the following road map to help you understand your claims requirements.
Project 2003 Authentication Usage
Impact of 2007 Upgrade
Impact of 2010 Upgrade
Using a mix of Project Server and Windows Authentication
Project Server Accounts will be converted to Forms Authentication Accounts.
Claims authentication setup will be required to support this security configuration.
Exclusively using Project Server accounts for authentication
Exclusively using Windows accounts for authentication
Windows Authentication Classic Mode
No claims authentication setup is required if you wish to continue in this mode.
New Authentication modes for Project Server 2010
This is essentially the same as Forms Authentication.
A slight variation to Mixed-Mode.
Below are explanations for each of the authentication modes and more information to help you understand which to use.
Here are the common authentication modes that will require claims.
Project Server accounts are prevalent in Project Server 2003; Project Server performs all authentication requests, maintains the passwords and so forth. If you plan on using these forms accounts in 2010 instead of converting them to Windows accounts, you will need claims. In Project Server 2003, Project Server accounts prompt you for credentials similar to this:
In many respects, Project Server accounts are very similar to Project Server 2007 forms based accounts and can be converted to such.
An example of 2007 forms base user accounts is the AspNetSqlMembership provider or an LDAP provider. If you plan on using the same in 2010, then claims is required. In Project Server 2010, a forms based authentication prompt looks similar to:
Mixed mode authentication allows you to have two different URLs pointing to the same Project site in order to offer a different authentication mechanism for a given set of users. For example, you may have http://servername/pwa available to your users who are behind your corporate firewall and who are logged on using their Windows credentials. You may also have something like http://northwindtraders.com as an external URL available to users outside of the company domain so that they can log on using a forms-based account. Both URLs, however point to the same Project Server site.
All of these authentication methods use Security Assertion Markup Language (SAML) or claims sign-in. SAML-claims looks and works nearly identically to forms authentication except a third-party off-box solution provides a unified logon. For more information about SAML, see articles such as: http://www.pingidentity.com/landing-pages/saml-lp.cfm http://en.wikipedia.org/wiki/SAML http://xml.coverpages.org/saml.html
A typical SAML sign-in form might look something like the following:
Your organization needs the ability to offer more than one authentication method to users but using the same URL. This is known as multi-authentication. This scenario is similar to mixed mode authentication except there’s only one physical URL in one authentication zone and when a user hits the URL, they are taken to a page where they must choose which authentication method they’ll be using similar to that shown below:
Related to multi-authentication or mixed mode authentication, if you use Windows authentication and you use Forms authentication, then you’ll need to use Windows-Claims with your Forms-Claims setup.
These are the primary scenarios when you’ll need to use claims authentication and for each of these you’ll need to do special setup to enable claims authentication. Below are some articles to help you get this setup:
This article shows you how to enable claims to work with the ASP.NET membership/role provider. This article also discusses anonymous access; take note that anonymous access will not work with Project Server.
This article discusses how to configure a SAML based sign-in. Mixed mode and Multi-Authentication are simply combinations of these two basic types.
For more information about planning for the different authentication methods, see the following:
Question: Are there specific procedures for setting up claims to work with Project Server 2010?
Answer: While setup documents specific to Project Server will be released shortly, there’s nothing claims specific to Project Server 2010.
Question: If I use Forms Authentication today in 2007, can I just install 2010 and will everything work automatically?
Answer: No. There’s some work you’ll need to do. On an upgrade, the easiest approach is to install and then after that is completed, you can set up the web app to use claims (including the steps to enable the asp.net membership provider) and then rerun the SharePoint configuration wizard. Rerunning the wizard will then convert the user accounts to the claims format.
Question: If I plan on using Forms authentication using the ASP.NET SQL membership provider, do claims make it easier to manage the users?
Answer: Claims is not user management but instead deals with the authentication of users. Thus, the same processes you use in 2007 to manage users in your ASP.NET membership provider will need to be used in 2010.
Question: Will all of the features like the Report Center work if I choose to use claims?
Answer: Yes. Once setup is completed, all features will work whether it’s the Report Center or features like project workspaces.
Question: In Project Professional 2007, the Login dialog box has an option to allow me to enter my credentials. How can I do this using Project Professional 2010?
Answer: If you’re logging in using any one of the varieties of forms authentication, you’ll get prompted for login information similar to what you see in the browser. If you are using Windows authentication, there is not a direct option to enter credentials but instead it is controlled via Internet Explorer’s User Authentication options. Within Internet Explorer’s Options, for the security zone in which your PWA site exists, change the login options to prompt similar to the picture below:
Note: This changes the logon option for the entire zone and is not exclusive to Project Professional.