Last week Microsoft released the preview for the next version of SharePoint Microsoft SharePoint 2013. With a new version comes new features and capabilities, both of which SharePoint 2013 has plenty.
During the course of this blog series I will be covering new topics in authentication for SharePoint 2013 Preview. This first post will be an overview of the new authentication capabilities Microsoft has put into this new version. Subsequent posts will cover the details of each new feature and walk through the implementation of each one.
Authentication is the process of a user supplying credentials against an authentication provider to gain access to an application. If the credentials supplied are correct, the authentication provider will issue a security token containing claims-based assertions about the user. This token is what determines the authorization for the user (i.e. what the user can access within the application). SharePoint 2013 Preview supports the following authentication methods:
- Windows Claims
- Security Assertion Markup Language (SAML)-based claims
- Forms-based authentication claims
The methods listed above are now the recommended authentication methods for SharePoint 2013. In fact, with the new app and server-to-server authentication features, claims-based authentication is the default option.
NOTE: Windows Classic mode authentication can still be configured in SharePoint 2013 Preview, but only through PowerShell as this has been deprecated. For organizations that will be upgrading an environment from Windows Classic authentication in SharePoint 2010 to Claims-Based authentication in SharePoint 2013 Preview, there is a new Convert-SPWebApplication PowerShell command for converting the web application over to Claims. This will be covered in detail in a later post.
By extending OAuth, SharePoint 2013 Preview is able to implement server-to-server authentication. This is accomplished by a new local security token service (STS) that issues tokens containing user identity claims to allow for cross-server authentication. This can be utilized by Exchange Server 2013 Preview, Lync Server 2013 Preview, and any other services that allow for the server-to-server authentication method. The service that has established a trust with SharePoint 2013 Preview uses the user identity claim that SharePoint sends to authorize the user against its own identity provider.
For on-premise implementations, the JSON metadata endpoint is configured to establish the trust relationship between SharePoint and the server-to-server compliant service. For external implementations, the Windows Azure Access Control Server (ACS) is used as a trust broker to facilitate communication between the servers.
NOTE: It is important to understand that server-to-server authentication is not used for user authentication. Because of this, it is not listed on the SharePoint 2013 Preview sign-in page, the authentication providers UI, or in the People Picker.
SharePoint 2013 Preview has added the concept of the SharePoint Store and App Catalog. More information on these topics will come in a later blog post.
These apps use OAuth 2.0 for authorization to use SharePoint resources. When a user installs an app from the SharePoint Store or App Catalog, they grant authorization of the app on behalf of their account. Once the app has been installed, anytime it needs to access SharePoint resources it will make an assertion based on a claim that it can act on behalf of an authenticated user. An instance of the Windows Azure ACS acts as the app identity provider, however you can also configure app authentication without ACS.
Over the course of this series on SharePoint 2013 Preview authentication, I will go into each of the above topics in detail. I will cover when and when not to use each one, as well as exactly how to configure each authentication method.