SAML-based
claims authentication in SharePoint Server 2016
SAML-based authentication requires
- A Client Computer
- A SharePoint 2016 Server/Farm
- Claim Provider / IP-STS (example: ADFS)
- 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.
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)
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.
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:
Happy SharePointing
