Claims Based Authentication in Sharepoint – How it works – SharePoint 2010 and SharePoint 2013

Why we need Claims Based Authentication for SharePoint 2010 and SharePoint 2013?

Claims based authentication is a new feature introduced by SP2010. We already have classic authentication, so why claims?
Classic authentication works on AD groups. Just imagine for a public facing site, how many AD Group additions need to be done up on user requests.
Secondly, it is for a point to point communication. The security cannot span beyond one application pool.

But in case of claims, it has ability to grant a security token which can authenticate user for all the application which mutually agrees with a System granting security tokens for authenticated users. This granting system generally refers as STS (Security Token System).

Most people jump to decision of using ADFS or some other STS with claims based authentication in SharePoint. Well the user have option to have flexibility of claims even on Windows or Forms based Authentications. You can see all these options while creating a SharePoint Web application.

Understanding the Windows Authentication Process

  1. The user requests a SharePoint 2010 resource.
  2. User authentication (NTLM challenge/Kerberos negotiation) occurs.
  3. The claims-based token request is sent to the SharePoint 2010 STS.
  4. SharePoint STS gets the user’s security groups from the Windows token and adds them as user claims in the token.
  5. The SharePoint STS gets additional claims for the user (if an additional claims provider is registered for that web application/zone).
  6. The claims-based token is issued.
  7. The request is processed by the rest of the components in the pipeline.
  8. The response is sent back to the user.

Understanding the Forms-Based Authentication Process

 
  1. The user requests a SharePoint 2010 resource.
  2. SharePoint redirects the user to the forms-based authentication login page.
  3. The username and password are collected from the user and sent to the SharePoint 2010 STS.
  4. STS validates the user’s credentials with the membership provider and, if validation succeeds, STS requests all the roles that the user belongs to and adds those claims to the user’s token.
  5. The SharePoint STS gets additional claims for the user (if an additional claims provider is registered for that web application/zone).
  6. The claims-based token is issued to the user.
  7. The request is processed by the rest of the components in the pipeline.
  8. The response is sent back to the user.

Understanding the SAML Claims-Based Authentication Process

  1. The user requests a SharePoint 2010 resource.
  2. SharePoint redirects the user to the SAML authentication page.
  3. Based on the configuration of the trusted login provider, the request is redirected to the enterprise STS login page or to the federated STS login page.
  4. The user provides credentials and STS issues a SAML claims-based token.
  5. The external STS issues the user claims-based token.
  6. A claims-based token for the user is requested from the SharePoint STS, and the token from the external STS is used as the authentication proof.
  7. SharePoint STS gets additional claims for the user (if an additional claims provider is registered for that web application or zone).
  8. SharePoint STS issues the claims-based token.
  9. The request is processed by the rest of the components in the pipeline.
  10. The response is sent back to the user.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s