SAML-based Claims Auth in SP2016

SAML-based claims authentication in SharePoint Server 2016

SAML-based authentication requires 

1. A Client Computer
2. A SharePoint 2016 Server/Farm
3. Claim Provider / IP-STS (example: ADFS)
4. Identity Provider (example AD, LDAP) which contains the actual accounts and password 

Note:
ADFS and SAML claims are not required if you are using AD DS infrastructure in which the forest and domain trust each other. 

Trust Relationship for SAML-based claims authentication process

Steps

• The ADFS Server must trust the Identity Provider for which it is issuing SAML Security Token.
  Note:
  In case of AD and ADFS in the same domain; the trust is implicit and therefore trusts the validation security credentials by its domain controllers
  
• ADFS must also trust Security Token request for locations on the SharePoint 2016 Server
  
• You configure ADFS with the URLs of SharePoint 2016 Web Applications as a Relying Party and then web pages of SharePoint 2016 Server and those URLs will now be trusted for SAML Security Token requests
  
• The SharePoint 2016 Server must also trust ADFS Server that uses a Token Signing Certificate to sign the SAML Security Token that is issues.
  
• To validate the Digital Signature on the Security Tokens issues by ADFS, we configured the SharePoint 2016 Farm with Public Portion of that ADFS Token Signing Certificate

The SAML-based claims 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 2016 web page

Step 2
The SharePoint 2016 Server redirects the Client Computer to the ADFS Server to obtain a SAML-based login page for User Credentials (username/password)

Step 3

The User provides credentials (username / password) and the Client Computer sends them to the ADFS Server with a request for a SAML Security Token

Step 4

The ADFS Server validates the sent credentials (username/password) with the Identity Provider (Active Directory, LDAP etc.)

Step 5

After validating the credentials from Identity Provider; the ADFS Server

• Constructs a SAML Security Token,
• Sign the Security Token, and
• Send this Security Token to the Client Computer

Step 6

The Client Computer sends a new request for the SharePoint 2016 Web Page and this time it includes the SAML Security Token that it(the Client Computer) received from the ADFS Server

Step 7

The Security Token Service on the SharePoint 2016 Server then creates a claim-based Security Token and stores it with the Distributed Cache Service on the SharePoint 2016 Farm.

Claims (username, password, email address or whatever info) in this Security Token are based on the Claims in the SAML Security Token from the ADFS Server

The SharePoint 2016 Server then creates and sends a Federated Authentication or FedAuth Cookie to the Client Computer

This FedAUTH Cookie contains an encrypted key or index to the Security Token.

If the User is authorized to access the requested web page on SharePoint through analysis of the claims in the Security Token created by Security Token Service of SharePoint 2016 and Configured Permissions on SharePoint Contents; the SharePoint 2016 Server then sends the contents on the requested web page on SharePoint.

For subsequent requests, the Client Computer uses the FedAUTH Cookie for authentication.

Note: 

All above steps are valid for SharePoint 2013 Server as well.

Reference:

https://technet.microsoft.com/en-au/library/jj219571(v=office.16).aspx?f=255&mspperror=-2147217396

Happy SharePointing