March 30, 2016 / Kannan / 0 Comments
SharePoint 2013 – SAML Based Authentication
The following is the interaction between
- Client Computer
- SharePoint Server
- Active Directory Federation Service (AD FS)
- Active Directory Domain Service (AD DS)
Notes:
- AD FS & SAML Claims are not required if AD DS is the provider in which the forest and domains trust each other
- AD FS must trust the AD DS for which the AD FS is issuing the SAML security tokens
- Here the trust might be implicit as the AD FS is the member of AD DS domain and hence trusts the domain controllers
- AD FS must also trust the SharePoint locations
- Hence AD FS is configured with SharePoint’s web application URLs as relying parties
- SharePoint server also must trust the AD FS’s SAML token.
- This trust is obtained via a signed certificate which the AD FS has and it signs the tokens with this certificate
- The SharePoint server is also configured with the public portion of the above mentioned signed certificate which AD FS uses and SharePoint trust those signed tokens using this public portion
The SAML Based Authentication Process
- User does anonymous request to secured SharePoint Webpage
- SharePoint redirects the user to AD FS’s login page for user to enter credentials
- User types in the credentials and sends back to AD FS using the client computer
- The AD FS server then validates the credentials with AD DS
- Once user is validated, the AD FS then creates a SAML token, signs and send it back to client computer
- The client computer now sends a new request to SharePoint server now with SAML token provided by AD FS
- SharePoint then creates a claims based security token using Security Token Service and this claims is based on the claims which it found in SAML token which the AD FS has sent to client computer
- Then SharePoint stores this security token with Distributed Cache Service on the farm
- SharePoint server then generates and send the federated auth cookie back to client computer
- The fed auth cookie has encryped key or index to security token
- This fed auth cookie is used by the computer for subsequent requests
The following Video will explain the Forms based authentication in SharePoint 2013. This video is part of the Authentication overview for SharePoint 2013 article located at https://technet.microsoft.com/en-us/library/jj219571.aspx
For more information on SharePoint Claims check out more articles at http://social.technet.microsoft.com/wiki/contents/articles/14214.sharepoint-2013-claims-based-authentication.aspx
March 30, 2016 / Kannan / 0 Comments
SharePoint 2013 Authentication – Forms Based
The following is the interaction between
- Client Computer
- SharePoint Server
- ASP.NET Membership provider
The Form Based Claims Authentication Process
- User does anonymous request to secured SharePoint Webpage
- SharePoint responds with form based login page
- User types in the credentials and sends back using the client computer
- SharePoint server then validates the credentials with membership provider
- SharePoint server then queries the roles provider for user’s associated roles
- This becomes the role claims for user’s account
- SharePoint then creates a claims based security token using Security Token Service
- Then SharePoint stores this security token with Distributed Cache Service on the farm
- SharePoint server then generates and sends the federated auth cookie back to client computer
- The fed auth cookie has encrypted key or index to security token
- This fed auth cookie is used by the computer for subsequent requests
The following Video will explain the Forms based authentication in SharePoint 2013. This video is part of the Authentication overview for SharePoint 2013 article located at https://technet.microsoft.com/en-us/library/jj219571.aspx
For more information on SharePoint Claims check out more articles at http://social.technet.microsoft.com/wiki/contents/articles/14214.sharepoint-2013-claims-based-authentication.aspx
March 30, 2016 / Kannan / 0 Comments
SharePoint 2013 – Windows Claims Authentication
The following is the interaction between
- Client Computer
- SharePoint Server
- Active Directory Domain Service
The Windows Claims Authentication Process
- User does anonymous request to secured SharePoint Webpage
- SharePoint requests back Windows Credentials (It can be a NTLM or Kerberos or basic)
- If user is in intranet zone, the browser sends back the logged in credentials to SharePoint, else user is prompted for credentials
- For both the cases the browser send back the credentials to SharePoint
- SharePoint then validates this credentials with Active Directory Domain Services (AD DS)
- AD DS then responds back to SharePoint with Windows Security Token
- SharePoint then checks, to which security groups the user belongs in AD DS
- SharePoint then creates a claims based security token using Security Token Service
- Then SharePoint stores this security token with Distributed Cache Service on the farm
- The IIS Server in SharePoint server then send the auth code to the user’s computer
- The client computer then uses this auth code for subsequent requests
The following Video will explain the Windows claims authentication in SharePoint 2013. This video is part of the Authentication overview for SharePoint 2013 article located at https://technet.microsoft.com/en-us/library/jj219571.aspx
For more information on SharePoint Claims check out more articles at http://social.technet.microsoft.com/wiki/contents/articles/14214.sharepoint-2013-claims-based-authentication.aspx