Authentication and Authorization in SharePoint 2013

In this post, we will discuss Authentication and Authorization in SharePoint 2013. SharePoint 2013 supports two authentication types for user authentication:

  • Claims-based authentication
  • Windows classic mode authentication


Introduction to authentication and authorization in SharePoint 2013:

A security system usually does two operations:

  • Authentication
  • Authorization

Authentication to determine the identity of a caller. This process tries to map the caller to an existing security principal. Like this will map the caller to a user account in an Active Directory domain. When the authentication process is successful, the system establishes the caller’s identity by creating a security token that contains attributes of the security principal.

Windows operating system creates a special type of security token known as a Windows security token when it authenticates a user. A Windows security token is an in-memory data structure that contains the user’s logon name and a list of security groups in which the user is a member.

Authentication process checks “Who are you?”.

The Authorization process checks what a user can do in the system. The authentication process must occur before the authorization process.

Understanding SharePoint Authentication Process:

The SharePoint platform relies on external user authentication systems such as Windows Server and Active Directory or the built-in support in ASP.NET for FBA. After an external system has authenticated a user and created a security token, the SharePoint platform is then able to create a profile around that security token to establish and track the user’s identity inside the SharePoint security system.

SharePoint 2003 was supported only Windows authentication.

SharePoint 2007 supports Windows authentication as well as FBA. FBA very useful for extranets and public facing web sites. Because it’s really impractical to create and maintain an Active Directory account for each user or site member.

Also read some SharePoint 2013 tutorials:
Document Sets in SharePoint 2013

SharePoint 2013 permission groups

SharePoint permission levels

The user is authenticated by using either Windows security or FBA which will create a Windows security token or an FBA token. Then this token needs to be converted to a SAML token. Every SharePoint web server runs a local service known as the Security Token Service (STS). The STS is responsible for converting Windows security tokens and FBA tokens into SAML tokens.

With Windows authentication, a user identity is configured in Active Directory Domain Services (AD DS) and supports having a number of attributes that are associated to each user. The user is either challenged for their credentials when they log on to their client computer or when they attempt to access SharePoint. The downside of this type of authentication is that if additional information about the user is required (roles, group membership, etc.), additional AD DS requests may be required. This approach doesn’t necessarily scale well with advanced authentication providers over Internet or cloud-based solutions. A solution to this problem is to use a claims-based token that you obtain from a trusted identity provider and that contains a set of claims about the users. Each of the claims can contain the critical pieces of data about the user such as name, birthdate, role, group membership, or even an email address that can then be used to give the user access to content based on the claim without going back to AD DS.

SharePoint 2010 introduced claims-based security which is an XML-based standard known as Security Assertion Markup Language (SAML) known as SAML token.

In SharePoint 2010, these SAML tokens are cached in memory on a per–web server basis and can be reused across multiple requests from the same user. SharePoint 2013 further optimizes the caching of SAML tokens with the Distributed Cache Service, which can be configured to maintain a farm-wide cache of SAML tokens.

The advantages of using SAML token is that it increased the number of identity providers like in addition to supporting Windows authentication and FBA, claims-based security makes it possible for a SharePoint farm to authenticate users by using external identity providers such as Windows Azure Access Control Service (ACS), Windows Account, Google, and Facebook.

Claim Based Authentication in SharePoint 2013:

– Claims is the default authentication type in SharePoint 2013.

– Claims-based authentication enables systems and applications to authenticate a user without requiring the user to disclose more personal information (such as social security number and date of birth) than necessary.

– Claims are as a set of information about some subject. This subject is most often a person, but it might also be an application, a computer, or something else. Claim is information like email address, name, age etc.

– A claim is given one or more values and then packaged in security tokens that are issued by a security token service (STS).

Authentication and Authorization in SharePoint 2013
Authentication and Authorization in SharePoint 2013

Steps how it executes authentication and authorization in SharePoint 2013:

  • The client put in the address in the browser and navigate to SharePoint URL, enter their username and password and click Sign In. These credentials are sent to the SharePoint server.
  • SharePoint 2013 is configured to perform claims-based authentication and connect to a trusted identity provider. SharePoint will pass the user’s credentials to the trusted identity provider and request authentication and a token.
  • The secure token server is Active Directory Federation Services and our data source is Active Directory.
  • ADFS will connect to Active Directory to retrieve attributes about the user signing in.
  • ADFS will authenticate the user (validate that their username and password are correct) and create a token. With ADFSv2 the token created can be one of 2 standards-based formats: either SAML 1.1 or WS-Federation. The token will be digitally signed before it is returned to the calling application. The token can also be encrypted if the environment requires it.
  • The signed token is then returned to SharePoint. This is done using either the SAML 2.0 protocol or the WS-Federation protocol depending on the configuration of ADFS.

Once SharePoint receives the token, it will then validate the digital signature on it to ensure that it can trust the token and the claims within it. Once this process is complete and the signature has been validated, the user is now logged into SharePoint. SharePoint now has the current user’s claims in memory (in the SPUser object) and SharePoint knows that it can trust them.