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

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

	Practice by building out the SharePoint Server 2013 SAML authentication test lab
	Review questions

Previous module in the series (forms-based authentication)

See Fast Learner Modules for Claims Authentication in SharePoint 2013 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. What is the difference between the SAML security token and the SharePoint claims-based security token?
   
   
3. True or False: The web client stores both the SAML security token and the SharePoint claims-based security token and uses the latter when making subsequent requests of resources on the SharePoint server.
   
   
4. What is the element of configuration so that the AD FS server trusts the SharePoint server? What is the element of configuration so that the SharePoint server trusts the AD FS server?
   
   
5. How does the SharePoint server verify that the SAML security token was issued by its trusted AD FS server?
   
   

For the answers to these review questions, click here.

Video Transcript

Let’s step through a simplified Security Assertion Markup Language, or SAML,-based claims authentication process for SharePoint 2013.

SAML-based claims authentication is an interaction between a client computer, a SharePoint server, an identity federation server (such as Active Directory Federation Services, or AD FS), and an identity provider, which contains the actual accounts, passwords, and account attributes, such as Active Directory Domain Services, or AD DS.

Please note that this process example is deliberately simplified. AD FS and SAML claims are not required if you are using an AD DS infrastructure in which the forests and domains trust each other.

Before we step through the authentication process, let’s examine the set of trust relationships that must be in place. First, the federation server, the AD FS server, must trust the identity provider for which it is issuing SAML security tokens. In this case, the trust is implicit because the AD FS server is a member of the AD DS domain, and therefore trusts the validation of security credentials by its domain controllers.

AD FS must also trust security token requests for locations on the SharePoint server.

For this trust relationship, you configure AD FS with the URLs of SharePoint web applications as relying parties. Web pages within those URLs will now be trusted for SAML security token requests.

The SharePoint server must also trust the AD FS server. The AD FS server uses a signing certificate to sign the SAML security tokens that it issues. To validate the digital signature on the security tokens issued by AD FS, you configure the SharePoint farm with the public portion of that signing certificate.

Now let’s take a look at the authentication process.

• Step 1: Assuming that the client computer does not already have a claims-based security token, SAML-based claims authentication occurs when it makes an initial anonymous request of a secured SharePoint web page.
• Step 2: The SharePoint server redirects the client computer to the AD FS server to obtain a SAML-based login page for user credentials.
• Step 3: The user types credentials and the client computer sends them to the AD FS server with a request for a SAML security token.
• Step 4: The AD FS server validates the sent credentials with the identity provider, which in this case is an AD DS domain controller.
• Step 5: The AD FS server constructs a SAML security token, signs it, and then sends it to the client computer.
• Step 6: The client computer sends a new request for the web page, this time it includes the SAML security token that it received from the AD FS server.
• Step 7: 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 this security token are based on the claims in the SAML security token from the AD FS server.

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: Claims in the SAML security token received from the web client, as issued by the AD FS server.

2. What is the difference between the SAML security token and the SharePoint claims-based security token?

Answer: The SAML security token is issued by the AD FS and is the proof that a web client has provided valid security credentials with its identity provider. The SharePoint claims-based security token is issued by the Security Token Service on the SharePoint server and is used to represent a validated user to SharePoint components.

3. True or False: The web client stores both the SAML security token and the SharePoint claims-based security token and uses the latter when making subsequent requests of resources on the SharePoint server.

Answer: False. The web client does not store the SharePoint claims-based security token. The web client uses a FedAuth cookie for subsequent resource requests.

4. What is the element of configuration so that the AD FS server trusts the SharePoint server? What is the element of configuration so that the SharePoint server trusts the AD FS server?

Answer: The web application URL of the SharePoint server is configured as a relying party. The public portion of the AD FS token signing certificate

5. How does the SharePoint server verify that the SAML security token was issued by its trusted AD FS server?

Answer: The SharePoint server uses the installed public portion of the AD FS server's token signing certificate to validate the digital signature on the SAML security token.

• The SharePoint server calculates its own hash value for the claims in the SAML security token.
• The SharePoint server uses the public portion of the AD FS signing certificate to decrypt the digital signature in the SAML security token and obtain the hash value as calculated by the AD FS server.
• If the hash values match, the AD FS server must have created the SAML security token.