Share via

Plan authentication methods (SharePoint Foundation 2010)

  • Article

 

Applies to: SharePoint Foundation 2010

This article describes the authentication methods and authentication modes that are supported by Microsoft SharePoint Foundation 2010.

Authentication is the process of validating a user's identity. An authentication method is a specific exchange of account credentials and other attributes that assert that identity. After a user's identity is validated, the authorization process determines which sites, content, and other features the user can access.

In this article:

  • Supported authentication methods

  • Authentication modes — classic or claims-based

  • Implementing Windows authentication methods

  • Implementing forms-based authentication

  • Implementing SAML token-based authentication

  • Choosing authentication for LDAP environments

  • Planning zones for Web applications

  • Architecture for SAML token-based providers

Supported authentication methods

SharePoint Foundation 2010 supports authentication methods that were included in previous versions and also introduces support for token-based authentication that is based on Security Assertion Markup Language (SAML). The following table lists the supported authentication methods.

Method category Authentication methods Notes

Windows authentication

  • NTLM

  • Kerberos

  • Anonymous

  • Basic

  • Digest

Forms-based authentication

  • Lightweight Directory Access Protocol (LDAP)

  • Microsoft SQL Server database or other database

  • Custom or third-party membership and role providers

SAML token-based authentication (new with SharePoint Foundation 2010)

  • Active Directory Federation Services (AD FS) 2.0

  • Third-party identity provider

  • Lightweight Directory Access Protocol (LDAP)

Supported only with SAML 1.1 that uses the WS-Federation Passive Requestor Profile (WS-F PRP).

Client certificate authentication is possible through integration with AD FS 2.0.

For additional information, see Configure Client Certificate Authentication (SharePoint Foundation 2010).

Authentication modes — classic or claims-based

Authentication modes determine how client computers authenticate with SharePoint Foundation 2010 resources. SharePoint Foundation 2010 introduces support for a claims-based authentication mode. You can use any of the supported authentication methods with the claims-based authentication mode or you can use classic mode authentication, which supports only Windows authentication.

User identity in Active Directory Domain Services (AD DS) is based on a user account. For successful authentication, the user provides the account name and proof of knowledge of the password. To determine access to resources, applications might need to query AD DS for account attributes and other information, such as group membership or role on the network. While this works well for Windows environments, it does not scale to third-party authentication protocols and directory providers and multi-vendor environments that support Internet, partner, or cloud-based computing models.

Claims-based identity is based on the user obtaining a security token that is digitally signed by a commonly trusted identity provider and contains a set of claims. Each claim represents a specific item of data about the user such as his or her name, group memberships, and role on the network. Claims-based authentication is user authentication that utilizes claims-based identity technologies and infrastructure. Applications that support claims-based authentication obtain the security token from the user and use the information within the claims to determine access to resources. No separate query to a directory service like AD DS is needed.

Claims-based authentication in Windows is built on Windows Identity Foundation (WIF), which is a set of .NET Framework classes that is used to implement claims-based identity. Claims-based authentication relies on standards such as WS-Federation, WS-Trust, and protocols such as SAML.

For more information about claims-based authentication, see the following resources:

For new deployments of SharePoint Foundation 2010, we recommend claims-based authentication. If you use claims-based authentication, all supported authentication methods are available for your Web applications.

When you create a Web application, you select one of the two authentication modes to use with the Web application, either claims-based or classic-mode.

Claims-based or classic mode authentication

If you select Classic-Mode Authentication, you can configure the Web application to use Windows authentication and the user accounts are treated by SharePoint Foundation 2010 as Active Directory Domain Services (AD DS) accounts.

If you select Claims-Based Authentication, SharePoint Foundation 2010 automatically changes all user accounts to claims identities, resulting in a claims token for each user. The claims token contains the claims pertaining to the user. Windows accounts are converted into Windows claims. Forms-based membership users are transformed into forms-based authentication claims. Claims that are included in SAML-based tokens can be used by SharePoint Foundation 2010. Additionally, SharePoint developers and administrators can augment user tokens with additional claims. For example, Windows user accounts and forms-based accounts can be augmented with additional claims that are used by SharePoint Foundation 2010.

A SharePoint Foundation 2010 farm can include a mix of Web applications that use both modes. Some services do not differentiate between user accounts that are traditional Windows accounts and Windows claims accounts. For example, a user who belongs to sites that are configured to use a mix of authentication modes may receive search results that include results from all the sites that the user has access to, regardless of the authentication mode that is configured for Web applications. In this scenario, the user is not interpreted as multiple user accounts. This is because services and service applications use claims identities for inter-farm communication regardless of the mode that is selected for Web applications and users. However, users who belong to more than one user repository that is recognized by SharePoint Foundation Web applications are treated as separate user accounts, depending on which identity they use to log in.

You do not have to be a claims architect to use claims-based authentication in SharePoint Foundation 2010. However, implementing SAML token-based authentication requires coordination with administrators of your claims-based environment, as described in the “Implementing SAML token-based authentication” section of this article.

Implementing Windows authentication methods

The process of implementing Windows authentication methods is similar for both authentication modes (classic or claims-based). Choosing claims-based authentication for a Web application does not increase the complexity of implementing Windows authentication methods. This section summarizes the process for each method.

Kerberos and NTLM

Both the Kerberos protocol and NTLM are Integrated Windows authentication methods, which let users seamlessly authenticate without being prompted for credentials. Users who access SharePoint sites from Internet Explorer will authenticate by using the credentials the Internet Explorer process is running under. By default, these credentials are the credentials that the user used to log on to the computer. Services or applications that access SharePoint Server resources using Integrated Windows authentication methods will attempt to authenticate by using the credentials of the running thread, which by default is the identity of the process.

NTLM is the simplest form of Windows authentication to implement. Simply select this option when you are creating a Web application.

Kerberos is a secure protocol that supports ticketing authentication. Use of the Kerberos protocol requires additional configuration of the environment. To enable Kerberos authentication, the client and server computers must have a trusted connection to the domain Key Distribution Center (KDC). Configuring the Kerberos protocol involves setting up service principal names (SPNs) in AD DS before you install SharePoint Foundation 2010.

The following steps summarize the process of configuring Kerberos authentication:

  1. Configure Kerberos authentication for SQL Server communications by creating SPNs in AD DS for the SQL Server service account.

  2. Create SPNs for Web applications that will use Kerberos authentication.

  3. Install the SharePoint Foundation 2010 farm.

  4. Configure specific services within the farm to use specific accounts.

  5. Create the Web applications that will use Kerberos authentication.

For more information, see Plan for Kerberos authentication (SharePoint Foundation 2010).

Additionally, for claims-authentication Web applications, the Claims to Windows Token Service (C2WTS) must be configured for constrained delegation. Constrained delegation is required to convert claims to Windows tokens.

Note

The C2WTS does not support crossing domain boundaries between forests.

Kerberos authentication allows delegation of client credentials to access back-end data systems, which requires additional configuration depending on the scenario. The following table provides examples.

Scenario Additional configuration required

Delegating a client's identity to a back-end server.

Displaying RSS feeds to authenticated content.

Configure Kerberos constrained delegation for computers and service accounts.

Identity delegation for Microsoft SQL Server Reporting Services (SSRS)

Configure SPNs for SQL Server Reporting Services accounts.

Configure delegation for SQL Server Reporting Services.

Identity delegation for Excel Services in SharePoint

Configure constrained delegation for servers that run Excel Services.

Configure constrained delegation for the Excel Services service account.

For more information about how to configure Kerberos authentication, including configuration steps for common scenarios, see Configuring Kerberos Authentication for Microsoft SharePoint 2010 Products and Technologies (white paper) (https://go.microsoft.com/fwlink/p/?LinkID=197178).

Digest and Basic

Implementing Digest and Basic authentication requires configuring these authentication methods directly in Internet Information Services (IIS).

Implementing forms-based authentication

Forms-based authentication is an identity management system that is based on ASP.NET membership and role provider authentication. In SharePoint Foundation 2010, forms-based authentication is available only when you use claims-based authentication.

Forms-based authentication can be used against credentials stored in AD DS, in a database such as a SQL Server database, or in an LDAP data store such as Novell eDirectory, Novell Directory Services (NDS), or Sun ONE. Forms-based authentication enables user authentication based on validation of credential input from a logon form. Unauthenticated requests are redirected to a logon page, where the user must provide valid credentials and submit the form. If the request can be authenticated, the system issues a cookie that contains a key for reestablishing the identity for subsequent requests.

To use forms-based authentication to authenticate users against an identity management system that is not based on Windows or that is external, you must register the membership provider and role manager in the Web.config file. Registering the role manager is a new requirement for SharePoint Foundation 2010. In the previous version, this was optional. SharePoint Foundation 2010 uses the standard ASP.NET role manager interface to gather group information about the current user. Each ASP.NET role is treated as a domain group by the authorization process in SharePoint Foundation 2010. You register role managers in the Web.config file the same way that you register membership providers for authentication.

If you want to manage membership users or roles from the SharePoint Central Administration Web site, you must register the membership provider and the role manager in the Web.config file for the Central Administration Web site. You must also register the membership provider and the role manager in the Web.config file for the Web application that hosts the content.

For detailed steps to configure forms-based authentication, see Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010)

For additional information about forms-based authentication, see the following resources:

For information about features that do not work with forms-based authentication or features that require additional configuration in order to work with forms-based authentication, see Plan for claims-based authentication or classic-mode authentication (SharePoint Foundation 2010).

Implementing SAML token-based authentication

SAML token-based authentication requires coordination with administrators of a claims-based environment, whether it is your own internal environment or a partner environment. AD FS 2.0 is an example of a claims-based environment.

A claims-based environment includes an identity provider security token service (IP-STS). The IP-STS issues SAML tokens on behalf of users who are included in the associated user directory. Tokens can include any number of claims about a user, such as a user name and groups the user belongs to.

SharePoint Foundation 2010 takes advantage of claims that are included in tokens provided by an IP-STS to authorize users. In claims environments, an application that accepts SAML tokens is known as a relying party STS (RP-STS). A relying party application receives the SAML token and uses the claims inside to decide whether to grant the client access to the requested resource. In SharePoint Foundation 2010, each Web application that is configured to use a SAML provider is added to the IP-STS server as a separate RP-STS entry. A SharePoint farm can include multiple RP-STS entries.

Implementing SAML token-based authentication with SharePoint Foundation 2010 involves the following processes that require planning in advance:

  1. Export the token-signing certificate from the IP-STS. This certificate is known as the ImportTrustCertificate. Copy the certificate to a server in the SharePoint Foundation 2010 farm.

  2. Define the claim that will be used as the unique identifier of the user. This is known as the identity claim. Many examples of this process use the user e-mail name as the user identifier. Coordinate with the administrator of the IP-STS to determine the correct identifier because only the owner of the IP-STS knows the value in the token that will always be unique per user. Identifying the unique identifier for the user is part of the claims-mapping process. Claims mappings are created by using Windows PowerShell.

  3. Define additional claims mappings. Define the additional claims from the incoming token that will be used by the SharePoint Foundation 2010 farm. User roles are an example of a claim that can be used to assign permissions to resources in the SharePoint Foundation 2010 farm. All claims from an incoming token that do not have a mapping will be discarded.

  4. Create a new authentication provider by using Windows PowerShell to import the token-signing certificate. This process creates the SPTrustedIdentityTokenIssuer. During this process, you specify the identity claim and additional claims that you have mapped. You must also create and specify a realm that is associated with the first SharePoint Web applications that you are configuring for SAML token-based authentication. After the SPTrustedIdentityTokenIssuer is created, you can create and add more realms for additional SharePoint Web applications. This is how you configure multiple Web applications to use the same SPTrustedIdentityTokenIssuer.

  5. For each realm that is added to the SPTrustedIdentityTokenIssuer, you must create an RP-STS entry on the IP-STS. This can be done before the SharePoint Web application is created. Regardless, you must plan the URL before you create the Web applications.

  6. Create a new SharePoint Web application and configure it to use the newly created authentication provider. The authentication provider will appear as an option in Central Administration when claims mode is selected for the Web application.

You can configure multiple SAML token-based authentication providers. However, you can only use a token-signing certificate once in a farm. All providers that are configured will appear as options in Central Administration. Claims from different trusted STS environments will not conflict.

If you are implementing SAML token-based authentication with a partner company and your own environment includes an IP-STS, we recommend that you work with the administrator of your internal claims environment to establish a trust relationship from your internal IP-STS to the partner STS. This approach does not require adding an additional authentication provider to your SharePoint Foundation 2010 farm. It also allows your claims administrators to manage the whole claims environment.

Important

You need to set network load balancing to single affinity when using claims-based authentication. If you use SAML token-based authentication with AD FS on a SharePoint Foundation 2010 farm that has multiple Web servers in a load-balanced configuration, there will be an effect on the performance and functionality of client Web-page views. When AD FS provides the authentication token to the client, that token is submitted to SharePoint Foundation 2010 for each permission-restricted page element. If the load-balanced solution is not using affinity, each secured element is authenticated to more than one SharePoint Foundation 2010 server, which will result in rejection of the token. After the token is rejected, SharePoint Foundation 2010 redirects the client to authenticate again back to the AD FS server. After this occurs, an AD FS server will reject multiple requests that are made in a short time period. This behavior is by design, to protect against a denial of service attack. If performance is adversely affected or pages do not load completely, set network load balancing to single affinity. This isolates the requests for SAML tokens to a single Web server.
For information about configuring Active Directory Federation Services (AD FS) 2.0 in SharePoint Foundation 2010, see How to configure AD FS v 2.0 in SharePoint Foundation 2010.

Note

When a Web application is configured to use SAML token-based authentication, the SPTrustedClaimProvider class does not provide search functionality to the People Picker control. Any text entered in the People Picker control will automatically be displayed as if it had been resolved, regardless of whether it is a valid user, group, or claim. If your SharePoint Foundation solution will use SAML token-based authentication, you should plan to create a custom claims provider that implements custom search and name resolution.
For more information, see Custom claims providers for People Picker (SharePoint Foundation 2010).

For detailed steps to configure SAML token-based authentication, see Configure authentication using a SAML security token (SharePoint Foundation 2010).

For additional information about SAML token-based authentication, see the following resources:

For information about features that do not work with SAML security tokens or features that require additional configuration in order to work with SAML security tokens, see Plan for claims-based authentication or classic-mode authentication (SharePoint Foundation 2010).

Choosing authentication for LDAP environments

LDAP environments can be implemented by using either forms-based authentication or SAML token-based authentication. We recommend that you use forms-based authentication because it is less complex. However, if the environment supports WS-Federation 1.1 and SAML Token 1.1, then SAML is recommended.

Planning zones for Web applications

Zones represent different logical paths for gaining access to the same sites in a Web application. Each Web application can include as many as five zones. When a Web application is created, the default zone is created. Additional zones are created by extending the Web application and selecting one of the remaining zone names: intranet, extranet, Internet, or custom.

In previous versions of SharePoint Foundation, zones are used to implement different types of authentication for users coming from different networks or authentication providers. In the current version, claims authentication allows multiple types of authentication to be implemented on the same zone.

Your plan for zones will depend on which of the following authentication modes you select for a Web application:

  • Classic mode — Similar to previous versions, only one type of authentication can be implemented per zone. However, in SharePoint Foundation 2010, only Windows authentication can be implemented when classic mode is selected. Consequently, multiple zones can be used only to implement multiple types of Windows authentication, or to implement the same type of Windows authentication against different Active Directory stores.

  • Claims-based authentication — Multiple authentication providers can be implemented on a single zone. Multiple zones can also be used.

Implementing more than one type of authentication on a single zone

If you are using claims authentication and implementing more than one authentication method, we recommend that you implement multiple authentication methods on the default zone. This results in the same URL for all users.

When you are implementing multiple authentication methods on the same zone, the following restrictions apply:

  • Only one instance of forms-based authentication can be implemented on a zone.

  • Central Administration allows you to use both an Integrated Windows method and Basic at the same time. Otherwise, more than one type of Windows authentication cannot be implemented on a zone.

If multiple SAML token-based authentication providers are configured for a farm, these will all appear as options when you create a Web application or a new zone. Multiple SAML providers can be configured on the same zone.

The following diagram illustrates multiple types of authentication implemented on the default zone for a partner collaboration site.

Multiple types of authentication on a zone

In the diagram, users from different directory stores access the partner Web site by using the same URL. A dashed box surrounding partner companies shows the relationship between the user directory and the authentication type that is configured in the default zone. For more information about this design example, see Design sample: Corporate deployment (SharePoint Server 2010).

Planning for crawling content

The crawl component requires access to content using NTLM. At least one zone must be configured to use NTLM authentication. If NTLM authentication is not configured on the default zone, the crawl component can use a different zone that is configured to use NTLM authentication.

Implementing more than one zone

If you plan to implement more than one zone for Web applications, use the following guidelines:

  • Use the default zone to implement your most secure authentication settings. If a request cannot be associated with a specific zone, the authentication settings and other security policies of the default zone are applied. The default zone is the zone that is created when you initially create a Web application. Typically, the most secure authentication settings are designed for end-user access. Consequently, end users are likely to access the default zone.

  • Use the minimum number of zones that are required to provide access to users. Each zone is associated with a new IIS site and domain for accessing the Web application. Only add new access points when these are required.

  • Ensure that at least one zone is configured to use NTLM authentication for the crawl component. Do not create a dedicated zone for the index component unless it is necessary.

The following diagram illustrates multiple zones that are implemented to accommodate different authentication types for a partner collaboration site.

One zone for each authentication type

In the diagram, the default zone is used for remote employees. Each zone has a different URL associated with it. Employees use a different zone depending on whether they are working in the office or are working remotely. For more information about this design example, see Design sample: Corporate deployment (SharePoint Server 2010).

Architecture for SAML token-based providers

The architecture for implementing SAML token-based providers includes the following components:

SharePoint security token service   This service creates the SAML tokens that are used by the farm. The service is automatically created and started on all servers in a server farm. The service is used for inter-farm communication because all inter-farm communication uses claims authentication. This service is also used for authentication methods that are implemented for Web applications that use claims authentication, including Windows authentication, forms-based authentication, and SAML token-based authentication. You must configure the security token service during the deployment process.

For more information, see Configure the security token service (SharePoint Foundation 2010).

Token-signing certificate (ImportTrustCertificate)   This is the certificate that is exported from an IP-STS. The certificate is copied to one server in the farm. Once you use this certificate to create an SPTrustedIdentityTokenIssuer, you cannot use it again to create another one. If you want to use the certificate to create a different SPTrustedIdentityTokenIssuer, you must delete the existing one first. Before you delete an existing one, you must disassociate it from any Web applications that may be using it.

Identity claim   The identity claim is the claim from a SAML token that is the unique identifier of the user. Only the owner of the IP-STS knows which value in the token will always be unique for each user. The identity claim is created as a regular claims mapping during the process of mapping all desired claims. The claim that serves as the identity claim is declared when the SPTrustedIdentityTokenIssuer is created.

Other claims   These claims consist of additional claims from a SAML ticket that describe users. These can include user roles, user groups, or other kinds of claims such as age. All claims mappings are created as objects that are replicated across the servers in a SharePoint Foundation farm.

Realm   In the SharePoint claims architecture, the URI or URL that is associated with a SharePoint Web application that is configured to use a SAML token-based provider represents a realm. When you create a SAML-based authentication provider on the farm, you specify the realms, or Web application URLs, that you want the IP-STS to recognize, one at a time. The first realm is specified when you create the SPTrustedIdentityTokenIssuer. Additional realms can be added after the SPTrustedIdentityTokenIssuer is created. Realms are specified by using syntax similar to the following: $realm = "urn:sharepoint:mysites". After you add the realm to the SPTrustedIdentityTokenIssuer, you must create an RP-STS trust with the realm on the IP-STS server. This process involves specifying the URL for the Web application.

SPTrustedIdentityTokenIssuer   This is the object that is created on the SharePoint farm that includes the values necessary to communicate with and receive tokens from the IP-STS. When you create the SPTrustedIdentityTokenIssuer, you specify which token-signing certificate to use, the first realm, the claim that represents the identity claim, and any additional claims. You can only associate a token-signing certificate from an STS with one SPTrustedIdentityTokenIssuer. However, after you create the SPTrustedIdentityTokenIssuer, you can add more realms for additional Web applications. After a realm is added to the SPTrustedIdentityTokenIssuer, it must also be added to the IP-STS as a relying party. The SPTrustedIdentityTokenIssuer object is replicated across servers in the SharePoint Foundation farm.

Relying party security token service (RP-STS)   In SharePoint Foundation 2010, each Web application that is configured to use a SAML provider is added to the IP-STS server as an RP-STS entry. A SharePoint Foundation farm can include multiple RP-STS entries.

Identity provider security token service (IP-STS)   This is the secure token service in the claims environment that issues SAML tokens on behalf of users who are included in the associated user directory.

The following diagram illustrates the SharePoint 2010 Products claims architecture.

SharePoint claims authentication components

The SPTrustedIdentityTokenIssuer object is created by using several parameters. The following diagram illustrates the key parameters.

SPTrustedIdentityTokenIssuer design

As the diagram illustrates, an SPTrustedIdentityTokenIssuer can include only one identity claim, one SignInURL parameter, and one Wreply parameter. However, it can include multiple realms and multiple claims mappings. The SignInURL parameter specifies the URL to redirect a user request to in order to authenticate to the IP-STS. Some IP-STS servers require the Wreply parameter, which is set to either true or false and is false by default. Only use the Wreply parameter if it is required by the IP-STS.

See Also

Other Resources

Resource Center: Security and Authentication for SharePoint Foundation 2010