What is Distributed Cache Service in SharePoint 2013 ?How does it help in authentication?

One of the big changes for the authentication infrastructure is being able to use the new Distributed Cache Service.  SharePoint uses that caching service to keep track of FedAuth  cookies for users that authenticate using FBA or SAML authentication.  In SharePoint 2010 each web front end kept their own local cache of fed auth cookies, and as a result we required you to use sticky sessions with your load  balancers to ensure that once a user got

authenticated, he or she was always redirected back to the same server so the 

authentication cookie could be found.  By using the new Distributed Cache to keep track of 

these authentication cookies, we no longer require sticky sessions when you use FBA or

SAML claims in SharePoint 2013.

 A) FBA authentication

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.

B)SAML Based (ADFS)  claims authentication

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.