Authentication Changes In SharePoint 2013

There are notable enhancements to the authentication process for SharePoint 2013 across the board, but the most prominent is the easier facilitation of claims based authentication. There are also changes that allow for new scenarios and functions to take place with Exchange Service 2013, Lync Server 2013, and apps that belong to the SharePoint store and to the App Catalog.

There is support for server-to-server authentication and app authentication. This is accomplished through the process of utilizing and extending the Open Authorization 2.0 web authorization protocol. OAuth is an industry standard protocol, and it is able to provide temporary redirection for the authorization to occur. The user or a web application is able to request authorization to temporarily access the specific network resources from a resource owner this way.

The support for OAuth in SharePoint 2013 makes it possible for users to grant apps in the SharePoint Store and App Catalog access to various user resources that are protected. This includes data such as documents, lists, videos, and images without the need for the app to get or to store the credentials of the user.

With OAuth, the app and services are able to act in place of users. This allows them to have limited access to the specific SharePoint resources. For example, a user may be able to get permission to use an app to get access to a specific folder in a document library. This allows the app, including a 3rd party, to access and copy those files in the specific folder that the user has specified. This can be accomplished without the need for the user to be verified or their account credentials to be looked at.

The user authentication in SharePoint 2013 makes it possible to verify the identity of the user when they ask to access any web application that SharePoint offers; this is no different than past versions of SharePoint. The authentication provider has to issue that user a security token that offers a set of claims based elements about that user. This is what is used to verify a given set of permissions that the user has been assigned.

The user authentication in SharePoint 2013 allows the users that can access these defined operations to do so for a specific resource, within any web application that SharePoint offers. There are several methods that are in place for SharePoint 2013 to support this type of user authentication including:

  1. Forms based authentication claims
  2. SAML (Security Assertion Markup Language) based claims
  3. Window Claims

The app authentication and server to server authentication features with SharePoint 2013 do require claims based authentication to occur. This results in claimed based authentication being the default for the new web applications in SharePoint 2013.

When a user creates a web application in Central Administration (WCAM), they can only tell it to use authentication methods for claims based authentication. There is still the Windows Classic Mode offered for authentication in SharePoint 2013. To configure it, go to Windows PowerShell. However, it is highly recommended that you rely on using the claims based authentication.

There are some updates to the infrastructure of claims that offer significant improvements in SharePoint 2013. They include:

  1. Easier to migrate from classic mode to Windows based claims mode. This is accomplished with the new Convert-SPWebApplicationWindows PowerShell cmdlet.
  2. Migration is allowed to be run against each of the content databases as well as for each of the web applications. In the past, it could only be run against the web applications.
  3. Login tokens are cached with the new Distributed Cache Service. Each time a user accesses a web front end server; there is the need for it to be authenticated. The problem though is that multiple re-authentications can occur. In the past to eliminate this, the user would enable and then configure load balancing affinity. This is often referred to as Sticky Sessions. With the process of storing the login tokens in the Distributed Cache Service in SharePoint 2013, the configuration of affinity is no longer a requirement. This also results in less memory being utilized for the authentication process.
  4. More logging so that it is easier to troubleshoot when any authentication issues do arise. There are separate categorized claims for each of the logs for each authentication mode. There is information regarding the addition or removal of FedAuth cookies from the Distributed Cache Service. There is information offered about reasons that FedAuth cookie can’t be used. For example it may be expired or there is a decryption failure. There is information regarding where the authentication requests are redirected. There is also information offered about any failures of the migration when you are describing a specific site collection.

With the extension of OAuth in SharePoint 2013, and it allows implementation of a server-to-server authentication protocol. This allows the services of SharePoint 2013 to be able to authenticate other services. They can include those stemming from Lync Server 2013 and from Exchange Server 2013. As long as the services are in compliance with server-to-server authentication protocol, it will be acceptable.

The dedicated local server to server Security Token Service (STS) in SharePoint 2013 offers server-to-server security tokens that have identity claims in them. This allows for the cross-server authentication to be accessed. The user identity claims are then used by other services to lookup that user against the provider identities.

There is a trust established between the local STS and other server-to-server compliant services. This is the key function in place that enables sever-to-sever possibilities to occur. With on premises deployments, it is possible to configure the JavaScript Object Notation (JSON) metadata end point of the other server-to-server complaint service. This will enable a trust relationship to occur.

With this server-to-server authentication offered from SharePoint 2013, access tokens are issued. The trusted identity providers have to be compliant with the WS-Federation protocol that is supported. This new function of SharePoint 2013 only allows the functions to be performed in order to enable temporary access tokens to access the other services. It isn’t able to be used by any user authentication that isn’t listed on the user sign in page.

The use of OAuth 2.0 is in place so that SharePoint 2013 is able to authorize requests by apps in the SharePoint Store as well as the App Catalog. This allows them to access SharePoint resources for a given user. The user gives permission to the apps in the SharePoint Store and App Catalog. Then the user is able to access the resources of SharePoint once they have been installed.

The use of OAuth in SharePoint 2013 allows the app authentication process to verify a claim made by an app. This will also allow the app to act on behalf of a user that has been authenticated. With SharePoint 2013, the Windows Azure acts as the app identity provider. This can be used without ACS. The process for authorization verifies that the authenticated app has permission to successfully perform the requested operation or to access a specific resource.