Authentication in SharePoint 2010

SharePoint 2010 supports 3 types of authentication methods:

Authentication Method	Description	Examples
Claims	Claims authentication for SharePoint Server 2010 is built on the Windows Identity Foundation, which is a set of .NET Framework classes that are used to implement claims-based identity.	N/A
Windows	The standard IIS Windows authentication methods are supported	Anonymous Basic Digest Certificates Kerberos (Integrated Windows) NTLM (Integrated Windows)
Forms-based	SharePoint Server 2010 adds support for identity management systems that are not based on Windows by integrating with forms-based authentication. Forms-based authentication enables SharePoint Server 2010 to work with identity management systems that implement the MembershipProvider interface. You do not need to rewrite the security administration pages or manage shadow Active Directory directory service accounts.	Lightweight Directory Access Protocol (LDAP) SQL database or other database Other forms-based authentication solutions

SharePoint 2010 now supports claims-based authentication or classic mode authentication when you create a Web application.

Claims-based authentication


The claims-based authentication model for SharePoint Server 2010 is built on the Windows Identity Foundation (WIF). Claims-based authentication in SharePoint Server 2010 enables authentication across Windows-based systems and systems that are not Windows-based. Claims-based authentication supports delegation of user identity between applications. Using claims-based authentication, you can implement multiple forms of authentication on a single zone.

Classic-mode authentication

Classic-mode authentication refers to the Integrated Windows authentication model supported in Windows SharePoint Services 3.0. In classic-mode authentication, no claims augmentation is performed and the new claims authentication features are not supported. Using classic-mode authentication, you can implement all of the previously supported forms of authentication with a limit of one form of authentication for each zone.


The following diagram illustrates a Windows SharePoint Services server farm that is configured to host sites for multiple companies.

Connect to identity management systems that are external or not based on Windows


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 in the Web.config file. In addition to registering a membership provider, you can register a role manager. SharePoint Server 2010 uses the standard ASP.NET role manager interface to gather group information about the current user. Each ASP.NET role is treated like a domain group by the authorization process in SharePoint Server 2010. You register role managers in the Web.config file the same way you register membership providers for authentication.
If you want to manage membership user or roles from the Central Administration site, you can register the membership provider and the role manager in the Web.config file for the Central Administration site in addition to registering these in the Web.config file for the Web application that hosts the content.
Ensure that the membership provider name and role manager name that you registered in the Web.config file is the same as the name that you entered in Central Administration. If you do not enter the role manager in the Web.config file, the default provider specified in the machine.config file might be used instead.

For example, the following string in a Web.config file specifies a SQL membership provider:
<membership defaultprovider="AspNetSqlMembershipProvider">

Integrating with forms-based authentication places additional requirements on the authentication provider. In addition to registering the various elements in the Web.config file, the membership provider, role manager, and HTTP module must be programmed to interact with SharePoint Server 2010 and ASP.NET methods, as indicated in the following table.

Category	Description
Membership provider	To work with SharePoint Server 2010, the membership provider must implement the following methods: GetUser (String): SharePoint Server 2010 calls this method to resolve user names during invitations and to get the user's display name. GetUserNameByEmail: SharePoint Server 2010 calls this method to resolve user names in invitations. FindUsersByName and FindUsersByEmail: SharePoint Server 2010 calls these methods to populate the user picker control on the Add Users page. If the membership provider does not return any users, the picker will not function and administrators will need to type the user name or e-mail address in the Add User text box.
Role manager	The role manager must implement the following methods: RoleExists: SharePoint Server 2010 calls this method during invitations to verify that a role name exists. GetRolesForUser: SharePoint Server 2010 calls this method at access check to gather the roles for the current user. GetAllRoles: SharePoint Server 2010 calls this method to populate the group and role picker. If the role provider does not return any groups or roles, the SharePoint Server 2010 picker will not function and the administrator will need to type the name of the role in the Add User text box.

Enabling anonymous access

You can enable anonymous access for a Web application in addition to configuring a more secure authentication method. With this configuration, administrators of sites within the Web application can choose to allow anonymous access. If anonymous users want to gain access to secured resources and capabilities, they can click a logon button to submit their credentials.
Using different authentication methods to access a site

You can configure Web applications in SharePoint Server 2010 to be accessed by up to five different authentication methods or identity management systems. The following figure illustrates a partner application that is configured to be accessed by users from two different identity management systems. Internal employees are authenticated by using one of the standard Windows authentication methods. Employees of the partner company are authenticated against their own company's identity management system.



To configure a Web application to be accessed by two or more different authentication systems, you must configure additional zones for the Web application. Zones represent different logical paths of gaining access to the same physical application. With a typical partner application, employees of a partner company access the application through the Internet, while internal employees access the application directly through the intranet.

To create a new zone, extend the Web application. On the Extend Web Application to Another IIS Web Site page, in the Load Balanced URL section, specify the URL and zone type. The zone type is simply a category name applied to the zone and does not affect the configuration of the zone.

After extending the Web application, you can configure a separate authentication method for the new zone. The default zone is the zone used by internal employees. The Internet zone is configured for partner access and uses forms-based authentication to authenticate partner employees against the partner identity management system.