Different Types of Authentication Architecture In SharePoint 2010

SharePoint 2010 web application in claims mode, different authentication options are available. These options determine the flow of the authentication process.

The steps in the authentication process. It explains, in order, the different routes that the authentication process flow can have, based on the authentication options that are available in SharePoint 2010.

Architecture of the Claims-Based Authentication in SharePoint

Below diagram shows overall architecture of the Claims-Based Authentication in SharePoint.

Different Types of Authentication Architecture In SharePoint
Different Types of Authentication Architecture In SharePoint

Steps in the Claims-Based Authentication Process:

  • The client requests a SharePoint resource.
  • As part of the request pipeline, if the request is not authenticated, the authentication components route the request based on the authentication settings for that zone.
  • The request is then processed by the authentication components. When more than one authentication method is configured for the given zone, the authentication selection page enables the user to choose the authentication method. If only one authentication method is specified, the request is processed directly by the specified authentication method.
  • The user is authenticated by the identity provider. If authentication succeeds, the SharePoint security token service (STS) generates a claims-based token for the user with the information provided by the identity provider. If additional claims providers are configured, the STS augments the user’s token with the claims given by the claims provider.
  • The claims-based token of the user is sent back to the authentication components.
  • The authentication components redirect the request back to the resource address, with the claims-based token issued for the user.
  • The rest of the request pipeline is executed and a response is sent back to the requestor (client). As part of the request pipeline, the authorization is completed.
  • The flow of the authentication process is defined by the options that you select during the configuration of the zone.

Architecture of the Windows authentication in SharePoint

The user selects the option that uses Windows authentication, the user request is redirected to the Windows authentication page, which is silent (no other UI is displayed to the user to indicate that the user is being redirected unless basic authentication is configured). On the Windows authentication page, when the user is authenticated, a claims-based token is requested and the user is sent back to the requested resource. Because the request contains a claims-based token that was issued by SharePoint STS, a claims identity is created and the request process continues.

Windows authentication in sharepoint
Windows authentication in sharepoint

Steps in the Windows Authentication Process:

  • The user requests a SharePoint 2010 resource.
  • User authentication (NTLM challenge/Kerberos negotiation) occurs.
  • The claims-based token request is sent to the SharePoint 2010 STS.
  • SharePoint STS gets the user’s security groups from the Windows token and adds them as user claims in the token.
  • The claims-based token is issued.
  • The request is processed by the rest of the components in the pipeline.
  • The response is sent back to the user.

Architecture of the Forms-based Authentication in SharePoint 2010

The SharePoint forms-based login page collects the credentials of the user, which are then sent to the SharePoint 2010 STS. The STS calls the membership provider that is associated with that web application, to validate the user’s credentials. If this succeeds, the STS retrieves the roles that the user belongs to and adds these as claims in the claims-based token that is sent back to the login page. From the login page, after the claims-based token is issued, the user is sent back to the requested resource and the process continues in the same way as in Windows authentication.

Forms-based Authentication in sharepoint
Forms-based Authentication in sharepoint

Steps in the Forms-based Authentication Process

  • The user requests a SharePoint 2010 resource.
  • SharePoint redirects the user to the forms-based authentication login page.
  • The username and password are collected from the user and sent to the SharePoint 2010 STS.
  • 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.
  • The SharePoint STS gets additional claims for the user (if an additional claims provider is registered for that web application/zone).
  • The claims-based token is issued to the user.
  • The request is processed by the rest of the components in the pipeline.
  • The response is sent back to the user.

Architecture of the SAML Token-Based Authentication in SharePoint

Out-of-the-box, with the default implementation of Active Directory Federation Services (AD FS), when SAML token-based authentication is enabled in the zone settings, users are redirected to a “silent” authentication page, which then redirects the user to the login page, as specified in the SAML-based authentication provider. After the user is authenticated by the authentication provider, a SAML token is issued, and the user is redirected back to the SharePoint 2010 SAML token-based authentication page. The SAML token is then included in the request with the redirect. This process is known as “passive profiles”.

SAML Token-Based Authentication in SharePoint
SAML Token-Based Authentication in SharePoint

Steps in the SAML Token-Based Authentication Process:

  • The user requests a SharePoint 2010 resource.
  • SharePoint redirects the user to the SAML authentication page.
  • 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.
  • The user provides credentials and STS issues a SAML claims-based token.
  • The external STS issues the user claims-based token.
  • 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.
  • SharePoint STS gets additional claims for the user (if an additional claims provider is registered for that web application or zone).
  • SharePoint STS issues the claims-based token.
  • The request is processed by the rest of the components in the pipeline.
  • The response is sent back to the user.

You may like following SharePoint 2010 tutorials:

Difference between Classic and Claim based Authentication in SharePoint 2010

Now let us discuss what is difference between Classic and Claim based Authentication in SharePoint 2010.

Classic Based Authentication :
You cannot configure the Forms-based authentication if your web application is using Classic Mode Authentication.

You can convert a web application from Classic Mode Authentication to Claims Based Authentication. However, that can only be done using PowerShell commands and its an irreversible process.

Classic authentication supports authentication types like Kerberos, NTLM, anonymous. Classic is more commonly seen in 2007 environments.

Claim Based Authentication:
It enables authentication from windows as well as non-windows based systems. This also provides the capability to have multiple authentications in a single URL.

Claims based authentication uses claims identities against a against a trusted identity provider.

Claims are the recommended path for new deployments in SharePoint 2010.

Different Authentication mechanism in SharePoint 2010

Now, we will discuss the different authentication mechanism in SharePoint 2010. A user’s identity must be validated before a user trying to use the SharePoint application.

Authentication methods determine which type of identity directory is to be used and how users are authenticated by IIS. SharePoint supports below types of authentication:

  • Windows Authentication
  • Forms Authentication
  • Claims-based Authentication
  • Web Single Sign-On Authentication

Windows Authentication:

Windows Authentication uses Active Directory to validate users. When Windows Authentication is selected, IIS uses the Windows Authentication protocol that is configured in IIS.

The security policies like account expiration policies, password complexity policies, and password history policies etc that are applied to the user accounts are configured within Active Directory, not in SharePoint.

When a user attempts to authenticate to a SharePoint web using Windows Authentication, IIS validates the user against NTFS and Active Directory; once the validation occurs, the user is authenticated and the access levels of that user are applied by SharePoint.

Anonymous Access:

Anonymous access associates unknown users with an anonymous user account(IUSR_machinename). It is commonly used in Internet sites. However, this configuration is disabled by default.

In order to configure anonymous access to a SharePoint application, anonymous access must be enabled in IIS and the SharePoint application, and the anonymous user account must be provisioned.

Anonymous users are only allowed to read, and they are unable to edit, update, or delete content.

Forms-Based Authentication:

The forms-based Authentication method is used against custom authentication provider like custom LDAP directory, SQL Server etc.

Claims-Based Authentication:

Claims-based identity is a security model for authentication and authorization based on the Windows Identity Foundation.

You can check the good article on Configure Claim Based Authentication in SharePoint 2010.

Web Single Sign-On:

The Web Single Sign-On authentication method is used in environments configured for federated identity systems. An independent identity management system integrates user identities across heterogeneous directories and provides the user validation for IIS.

This includes Microsoft Identity Information Server with Active Directory Federation Services, Oracle Identity Management with Single Sign-On and Web Access Control, and Sun Microsystems Java System Identity Manager.

Combined Access:

In SharePoint, it is possible to configure a combination of authentication methods. For instance, employees and external partners can use different methods, such as Active Directory for internal people and a SharePoint list via Forms Authentication for others.

This is achieved by defining two zones and associating authentication methods with the zones. The intranet zone would be configured with Windows Authentication and an extranet zone would be configured with ASP.NET Forms authentication.

Security changes in SharePoint 2013

Now, we will discuss some of the security changes in SharePoint 2013 compared to SharePoint 2010.

SharePoint 2013 has lots of changes in the authentication model. Now Claims-based authentication is the default for all SharePoint 2013 web applications. Claims based authentication uses tokens to identify users with claims which are nothing but some attributes like username, email, etc.

In SharePoint 2013, through claims you will be able to allow multiple authentication types on a single web application. If you are interested to use classic authentication, then you can use PowerShell to change the default claims based to classic mode.

Another change in SharePoint 2013 is the introduction of OAuth. OAuth is used to authenticate and authorize apps and services, without the user having to provide credentials to the app. It does this by establishing a trust between the app server and SharePoint so the app can access its request.

A user signs in to SharePoint 2013 and is authenticated through Claims. They then use an Office Store or an app catalog app; the app is granted permission by the user to access SharePoint resources on the user’s behalf. When a user launches an app, SharePoint 2013 posts a context token to the app.

The app then calls back to SharePoint 2013 to access the SharePoint resources on behalf of the user by using an access token.

If you want to use Active Directory Federation Services, then you can set up multiple applications and systems that trust the authentication cookies you enable, so the user just signs into ADFS and has access to all these systems without having to sign in again.

You may like following SharePoint tutorials:

free sharepoint training

SharePoint Online FREE Training

JOIN a FREE SharePoint Video Course (3 Part Video Series)

envelope
envelope

Gangi Reddy

>