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:
Learner Modules for Claims Authentication in SharePoint 2013 for all of the modules in this
Fast Learner series.
For the answers to these review questions, click
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.
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
Also visit technet.com/sharepoint.
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.