Various options can be leveraged for the authentication in SharePoint. Claims based authentication is the default authentication method in SharePoint. We will go through different types of claims authentication used in SharePoint
What is a Claim?
Definition from source: A claim is a statement that one subject, such as a person or organization, makes about it or another subject.
In the context of SharePoint Authentication, Claim is a statement by a user or a resource to prove its identity.
What is Authentication?
Definition: In simple words, Authentication is the process of checking the user’s identity.
When SharePoint Authentication does occur?
- If any user tries to access SharePoint resource
- If any App tries to access SharePoint resource
- If the SharePoint server tries to access SharePoint resource
There are a few Authentication methods and you can use any of them. We will go through them one by one.
- Windows authentication
- NTLM
- Kerberos
- Digest
- Basic
- Forms-based authentication (FBA)
- Security Assertion Markup Language (SAML) token-based authentication
Windows Authentication:
In Windows authentication, SharePoint takes advantage of the default authentication provider (ADDS) to authenticate the logged-in user. In this type of authentication, SharePoint site takes the same credentials, which was used by the user to log in to his machine.
- NTLM
- Kerberos
- Digest
- Basic
Windows claims Authentication process in SharePoint
- Assume, on client’s computer there’s no any claims-based security token, User requests SharePoint resource (Site, list, page, etc.…).
- SharePoint asks the user for the credential.
- The user provides the credentials.
- SharePoint takes the credentials and goes to the identity provider to verify the credentials
- The identity provider will verify the credentials and will send back the Windows Security Token.
- SharePoint asks Domain Controller for the list of Security Groups that the user belongs to.
- Domain Controller sends the list of Security Groups to SharePoint
- Using this information (Windows Security Token and Group Membership of the user account), Security Token Service in SharePoint server creates claims-based Security Token.
- Security Token Service (STS) stores claims in Distributed Cache Service (DCS) in SharePoint farm.
- IIS server on the SharePoint server sends authorization code to the client computer.
- The end-user accesses the page if the user is authorized, through analysis of the claims in the security token and configured permission.
- After authorization is successful, the SharePoint server sends the content of the page.
Note: Authorization code is used for authentication of any subsequent requests.
Forms-based authentication (FBA)
Form-based authentication is a process of checking the user’s claim based identity with the help of ASP.Net membership and role provider. You can use Forms-based authentication if the user credentials are stored in one of the below authentication providers.
- ADDS
- SQL Server or equivalent database
- Lightweight Directory Access Protocol (LDAP) datastore
Forms-based claims Authentication process in SharePoint
- Assume, on client’s computer there’s no any claims-based security token, User requests SharePoint resource (Site, list, page, etc.…).
- SharePoint sends Form-Based login page to the user and asks the user to enter credential.
- The user provides the credentials.
- SharePoint sends the credentials to Membership Provider.
- Membership Provider verifies the credentials
- SharePoint queries Role Provider for the credentials (user)
- Role Provider sends the list of Roles that are associated with the user
- Based on Information from Membership and Role Provider, Security Token Service in SharePoint server creates claims-based Security Token.
- Security Token Service stores claims in Distributed Cache Service (DCS) in SharePoint farm. Claims in Security Token include user identity and the roles of the user account.
- IIS server on the SharePoint server sends Federated Authentication or Fed Auth Cookie to the client machine.
The cookie contains encrypted key or index to the security token (which is created in SharePoint server in Distributed Cache Service - DCS).
- The end-user accesses the page, If the user is authorized, through analysis of the claims in the security token and configured permission.
- After authorization is successful, the SharePoint server sends the content of the page.
Fed Auth Cookie is used for authentication of any subsequent requests.
Security Assertion Markup Language (SAML) token-based authentication
SAML based authentication process includes:
(1) User: The end-user who requests the content/data.
(2) SharePoint Server: The SharePoint server where the actual data is available.
(3) Identity Federation server such as ADFS (Active Directory Federation Services): ADFS is a Microsoft component developed for Single Sign-On Solution (SSO) especially when the users are not capable of accessing the application using Integrated Windows Identity (IWA) through Active Directory (AD).
(4) Identity provider - ADDS (Active Directory Domain Services): which contains id, password and other details of the objects/users.
Trust Relationships - Security Assertion Markup Language (SAML) token-based authentication
- Identity Federation server (ADFS here) should establish TRUST with Identity Provider (ADDS here) for which ADFS is issuing SAML security tokens.
- Identity Federation server (ADFS here) also needs to TRUST security token requests for locations on the SharePoint server.
For this, you need to configure ADFS with SharePoint Web Application URLs as Relying Parties. The idea behind this is to trust pages within those Web Application URLs for SAML security token requests.
- SharePoint Server needs to TRUST the Identity Federation server (ADFS here).
- ADFS uses the certificate to sign the security token that it issues.
- SharePoint server needs a public key of that certificate to validate the digital signature on the security tokens issued by ADFS server.
Security Assertion Markup Language (SAML) token-based authentication process
- Assume, on client’s computer there’s no any claims-based security token, User requests SharePoint resource (Site, list, page, etc.…) and SAML Authentication process starts with this request.
- SharePoint server redirects the user (client computer) to the Identity Federation server (ADFS here) server to obtain SAML-based login page.
- The user enters credentials in the login page and sends back to Identity Federation server (ADFS here) server and requests SAML security token
- Identity Federation server (ADFS here) sends credentials to Identity Provider (ADDS here)
- Identity Provider (ADDS here) confirms credentials and send a reply to Identity Federation server (ADFS here)
- Identity Federation server (ADFS here) then creates a SAML token for the user, signs it and send it to the user.
- The client computer sends a fresh request to SharePoint resource (Site, list, page, etc.…). This time SAML security token is also included in the request that it got from the Identity Federation server (ADFS here).
- Security Token Service in SharePoint server creates claims-based Security Token from SAML security token received from the Identity Federation server (ADFS here).
- Security Token Service stores claims in Distributed Cache Service in SharePoint farm
- IIS server on the SharePoint server sends Federated Authentication or Fed Auth Cookie to the client machine.
The cookie contains encrypted key or index to the security token (which is created in SharePoint server in Distributed Cache Service).
- The end-user accesses the page if the user is authorized, through analysis of the claims in the security token and configured permission.
- After authorization is successful, the SharePoint server sends the content of the page.
Fed Auth Cookie is used for authentication of any subsequent requests.
Conclusion:
We went through each claim based authentication process in details which is used in SharePoint.
You can go through the Microsft article about SharePoint Authentication Overview in detail.