Plan for claims-based authentication or classic-mode authentication (SharePoint Foundation 2010)

Applies to: SharePoint Foundation 2010

In Microsoft SharePoint Foundation 2010, you can choose between claims-based authentication and classic-mode authentication when you create a Web application.

For more information about these two authentication modes, see Plan authentication methods (SharePoint Foundation 2010).

Choosing classic-mode or claims-based authentication

Choosing between classic-mode and claims-based authentication should be based on business needs. For example, if you need to support user accounts in identity providers that are not based on Active Directory Domain Services (AD DS), and you implement forms-based authentication, you must use forms-based authentication with claims-based authentication in SharePoint Foundation 2010. We recommend that you use claims-based authentication whenever possible.

The following chart summarizes the support for authentication types by each authentication mode.

Upgrading to SharePoint Foundation 2010

If you are upgrading from Windows SharePoint Services 3.0 to SharePoint Foundation 2010, you should consider the following information:

• If you are upgrading an earlier version solution to SharePoint Foundation 2010 and the solution includes only Windows accounts, you can use either mode of Windows authentication: Windows Claims or Windows Classic. We recommend that you use claims-based authentication whenever possible. For more information about using claims-based authentication, see Implementing Claims-Based Authentication with SharePoint Server 2010 (whitepaper).

• If you are upgrading a solution that requires forms-based authentication, the only option is to upgrade to claims-based authentication.

• Custom code that uses Windows identities might have to be updated. If you have custom code that uses Windows identities, you can use classic-mode authentication until your code is updated and tested. For example, if you wrote a custom Web part for Windows SharePoint Services 3.0 that retrieved the current user identity and you are upgrading to SharePoint Foundation 2010, you should use SPWeb.CurrentUser() instead of HttpContext.Current.User.Identity() in order to retrieve the identity.

• The migration time will vary, depending on the number of users that are listed in the UserInfo table in the content database. When you change a Web application from Windows classic mode to Windows claims, you must use Windows PowerShell to convert Windows identities to Windows claims identities. Be sure to allow for enough time during the upgrade process to complete this task.

• You can search and list names in people picker when you are using SAML token-based authentication, but they cannot be checked for validity unless you write a custom claims provider.

  For more information about how to write a customer claim provider, see Custom claims providers for People Picker (SharePoint Foundation 2010).

• If you are using the Outlook social connector, you must use either Windows classic-mode authentication or Windows claims authentication.

The following table illustrates several compatibility considerations when you migrate from Windows SharePoint Services 3.0 to SharePoint Foundation 2010.

Notes for the previous table of compatibility considerations:

1. This upgrade path is supported by migrating to claims authentication.

2. This upgrade path is supported, but it requires additional configuration in order to complete the migration.

3. This upgrade path is not supported, but the same level of functionality is provided through SAML token-based authentication.

For additional information about migrating, see the following topics:

• Upgrading to SharePoint Foundation 2010

• Migrate from forms-based authentication to claims-based authentication (SharePoint Foundation 2010)

• Migrate from classic-mode to claims-based authentication (SharePoint Foundation 2010)

Features that do not work with forms-based authentication or SAML security tokens

The following SharePoint Foundation 2010 features do not work when you switch to a claims-based Web application that uses forms-based authentication or Security Assertion Markup Language (SAML) security tokens. These features do not work because claims-based authentication does not generate a Windows security token, which is necessary for these features.

• Search Alerts

• SharePoint Foundation 2010 Explorer View

• Claims to Windows Token Service (C2WTS)

• InfoPath Forms Services

• Search crawling

  Note

  If you are using forms-based authentication or SAML token-based authentication, you will still need a separate zone that supports Windows authentication to enable Microsoft Search Server 2010 to crawl your content.

• Certificate Authentication

  Note

  Certificate authentication is not supported in SharePoint Foundation 2010, but you can configure Unified Access Gateway (UAG) as a front-end to SharePoint Foundation 2010 to enable certificate authentication by integrating with Active Directory Federated Services (AD FS) and SAML token-based authentication.
  For more information about configuring SharePoint Foundation 2010 with UAG, see Forefront UAG integration (SharePoint Foundation 2010).

Features that require additional configuration in order to work with forms-based authentication or SAML security tokens

There are several SharePoint Foundation 2010 features that require additional configuration to work with forms-based authentication or SAML security tokens.

• Business Intelligence (BI)

  BI clients must either use Windows Claims authentication, Windows Classic authentication, or the Secure Store Service. When you are using the Secure Store Service, SAML claims are not translated to Windows tokens, so other services will not detect the SAML identity; the identity will be the service account, an anonymous account, or an unattended account.

• Information Rights Management (IRM)

  A hotfix that enables basic IRM functionality with claims and SAML is available from Microsoft. For more information, see Microsoft Knowledge Base article Description of the SharePoint Foundation 2010 hotfix package: June 30, 2011(https://go.microsoft.com/fwlink/?LinkId=236873).