What’s New in SharePoint 2013’s Authentication Model
SharePoint 2013 brings with it significant changes in the authentication model behind the scenes. To the end user, it will appear as if nothing has changed when they log in. These are the major behind the scenes changes that exist in SharePoint 2013 and I’ll go through each one briefly:
- Claims-based authentication is the default authentication mode for SharePoint 2013 web applications
- SharePoint apps will use OAuth to access SharePoint data
- Server to Server (S2S) Authentication enables automated identity delegation across select applications
A (Brief) History of Authentication in SharePoint (2007-Present)
Microsoft Office SharePoint Server (MOSS) 2007 relied on the capabilities of Microsoft Internet Information Services (IIS) to provide authentication in what has become known as “Classic” authentication. Classic authentication supports Basic, Forms-Based Authentication (FBA), NTLM, or Kerberos modes. A single MOSS web application could only use a single authentication mechanism for most intents and purposes. This meant that in order to support NTLM and FBA an administrator would have to extend the MOSS web application (and create a second URL) to use the other authentication mode.
SharePoint Server 2010 introduced the concept of Claims-Based authentication to the SharePoint community using “tokens” that identify the user and specific, customizable attributes about the user (username, email, full name, etc.). Each attribute is known as a claim. Claims also allows multiple authentication types on a single web application without the need to extend the web application. However, SharePoint 2010 defaults to Classic authentication still, although Claims is recommended for new deployments or when FBA is needed. Internally, however, SharePoint 2010 uses claims regardless of the web application’s authentication mode. This simplifies the code base and prevents a lot of unnecessary authentication mode-specific code.
Fast forward to SharePoint 2013 and Claims is the new default. In fact, it’s not possible to create a Classic authentication web application from the user interface. It is possible from PowerShell but not recommended. Microsoft has also made it easier to convert a Classic web application to a Claims web application via the Convert-SPWebApplication PowerShell cmdlet. In addition, the user’s authentication cookie is stored in the new Distributed Cache Service, which is shared across web front-end servers so a user must only log in once.
OAuth and SharePoint 2013 Apps
If you haven’t heard of OAuth, I suggest you check it out here and on Wikipedia. In SharePoint 2013, OAuth provides authorization for apps to access specific user resources without the user needing to provide credentials to the app. If this sounds familiar to Facebook apps it’s because they both use the OAuth standard to provide this access. Regardless of where the app is actually hosted (on-premise or in the cloud), a trust is established between the app server and SharePoint allowing the app access to the resources it’s requested.
In the case of an on-premise app, everything is negotiated between the server and SharePoint and an implicit trust exists. This comes from the app being hosted on SharePoint. For the case of cloud-based apps, SharePoint trusts the Azure Access Control Service (ACS). The app also trusts ACS. So when the user accesses the app, ACS brokers the connection and transfer of the necessary tokens, but the user connects directly to the app. The advantage of OAuth here is that it enables the app to access the SharePoint resources as the user even though it’s not running under the user’s credentials just the user’s context.
When the app is first installed, it must provide a list of the resources and access it requires. If the user installing the app cannot provide this access because they don’t have the necessary access, then that user cannot install the app. This has nothing to do with OAuth, but is an important point nonetheless.
Server to Server (S2S) Authentication
The final major authentication change in SharePoint 2013 is the addition of Server to Server (S2S) Authentication. This is similar to OAuth for Applications but is for an entire server and is actually delegating the user’s identity to the remote server. Currently, the only servers that leverage S2S are SharePoint 2013, Lync 2013, and Exchange 2013 as well as multi-tenant workflow. This means the S2S could also flow seamlessly across Office 365 (i.e. cloud-based) solutions and on-premise solutions.
S2S relies on claims behind the scenes to delegate the user’s identity. Where it differs from straight claims is that the delegation is automatic and doesn’t have to be initiated by the user. Notable use cases are listening to Lync voice messages in SharePoint, synchronizing tasks across SharePoint and Exchange, and surfacing a site mailbox in SharePoint that exists in Exchange.
Summary
Not a whole lot is different from an end-user perspective, but behind the scenes, there’s a lot to get excited about. With apps being segregated from SharePoint entirely and requiring an OAuth token to obtain specific access to SharePoint resources, security and portability of apps becomes much simpler from an administrative point of view. In a sense, OAuth allows a super-sandboxing of content while avoiding a lot of the drawbacks of sandboxed solutions because server resources aren’t leveraged directly.
S2S Authentication has a chance to provide a convergence between the three major Microsoft server offerings permitting data and functionality to be surfaced from one server in another server with minimal effort on the part of the user. The use cases for these scenarios are plentiful and only require leveraging data from one server and while using it in another. All of the authentication is taken care of behind the scenes automatically.
