Objective: To understand how forms-based claims authentication works in SharePoint 2013.

Forms-based claims authentication video [2 min] (transcript)

After viewing the video, use the following to practice and review: 

	Practice by building out the SharePoint Server 2013 forms-based authentication test lab
	Review questions

	Previous module in the series (Windows claims authentication)
	Next module in the series <<link>> (SAML-based authentication)

See Claims Authentication in SharePoint 2013 for Fast Learners <<link>> for all of the modules in this Fast Learner series.

SharePoint 2013 Claims Authentication Resources

• Claims-Based Authentication Portal (http://aka.ms/spclm)
• Plan for user authentication methods
• Configure authentication infrastructure
• Share-n-dipity blog

Review Questions

1. What information does the SharePoint server use to construct the claims-based security token?
   
   
2. How does the FedAuth cookie prove that it represents the validated user?
   
   
3. True or False: The SharePoint server sends the contents of the request web page immediately after issuing the claims-based security token.
   
   
4. Why is this authentication method known as "forms-based authentication"?
   
   
5. [Extra Credit] The SharePoint server stores the claims-based security token in the SharePoint distributed cache. What authentication issue in SharePoint 2010 does the use of the distributed cache for security tokens mitigate?
   
   

For the answers to these review questions, click here.

Video Transcript

Let’s step through the forms-based claims authentication process for SharePoint 2013.

Forms-based claims authentication is an interaction between a client computer, a SharePoint server, and a membership and role provider that is available through the ASP.NET interface.

• Step 1: Assuming that the client computer does not already have a claims-based security token, forms-based claims authentication occurs when it makes an initial anonymous request of a secured SharePoint web page.
• Step 2: The SharePoint server responds with a forms-based login page for the user to enter credentials.
• Step 3: The user on the client computer types credentials and the client computer sends them.
• Step 4: The SharePoint server then validates the sent credentials with the configured membership provider.
• Step 5: The SharePoint server then queries the role provider for the roles associated with the user credentials. These become the list of role claims for the user account.
• Step 6: The Security Token Service on the SharePoint server then creates a claims-based security token and stores it with the Distributed Cache service on the SharePoint farm. Claims in the security token are based on the user name and the list of roles for the user account.

The SharePoint server then creates and sends a Federated Authentication, or FedAuth, cookie to the client computer. This cookie contains an encrypted key or index to the security token. If the user is authorized to access the requested web page, through analysis of the claims in the security token and the configured permissions, the SharePoint server then sends the contents of the page. For subsequent requests, the client computer uses the FedAuth cookie for authentication.

For additional information about claims authentication, go to the SharePoint 2013 claims authentication portal at aka.ms/spclm.

Also visit technet.com/sharepoint.

Answers to Review Questions

1. What information does the SharePoint server use to construct the claims-based security token?

Answer: Information about the user account name and the list of roles from the role provider.

2. How does the FedAuth cookie prove that it represents the validated user?

Answer: The FedAuth cookie contains an encrypted index to the security token stored in the distributed cache on the SharePoint server.

3. True or False: The SharePoint server sends the contents of the request web page immediately after issuing the claims-based security token.

Answer: False. Issuing the claims-based security token is only authentication. The request for the SharePoint resource must also pass authorization by ensuring that the claims in the security token have the correct permissions. Only after both authentication and authorization does the SharePoint server send the contents of the web page.

4. Why is this authentication method known as "forms-based authentication"?

Answer: Because the credentials are entered by the user into a web form on the client computer.

5. [Extra Credit] The SharePoint server stores the claims-based security token in the SharePoint distributed cache. What authentication issue in SharePoint 2010 does the use of the distributed cache for security tokens mitigate?

Answer: In SharePoint 2010, security tokens are stored on each front-end web server. With a network load balancer in front of multiple front-end web servers, there is an authentication delay as the web client authenticated with each front-end web server. To avoid multiple authentications, you can configure load balancer affinity. With the distributed cache in SharePoint 2013, security tokens are now distributed across the front-end web servers and the web client computer only needs to authenticate once. Load balancers do not need to be configured to use load balancer affinity.