You should always keep in mind SharePoint 2013’s “claims first” authentication architecture during your development as well as in discussions with the business about their custom requirements.
With SharePoint 2013’s user authentication based on claims, user authentication results in creation of a claims token which tracks name value pairs related to token subject. These claims tokens are stored in memory using FEDAUTH token format.
Overview of App Authentication
SharePoint 2013 app authentication is supported in CSOM as well as in REST API endpoints but is not supported for custom web services. There are three types of app authentication utilized by SharePoint 2013 as follows:
■ Internal authentication
■ External authentication using Server-to-Server (S2S) trusts
■ External authentication using OAuth
Internal Authentication
Internal authentication is utilized when an incoming call targets a CSOM or REST API endpoint or when an incoming call carries claims token with established user identity. Internal authentication is also utilized when an incoming call targets the URL of an existing SharePoint 2013 app web. This authentication does not support app-only authentication to elevate privilege(s).
There is no programming efforts required in terms of access tokens and internal authentication is automatically utilized with client-side calls from pages in the app web and it can also be utilized from remote web pages that are using the cross-domain library.
External Authentication
External authentication, which users both S2S and OAuth, is utilized for server-side code in the “remote web” and issues CSOM or REST API calls against the SharePoint host. The incoming calls are able to target host web and other sites within your organization’s tenancy.
External authentication does require custom app code to be developed to create and manage access tokens which carry the apps identity as well as user identity as the app is required to transmit an access token in request header when making a call to SharePoint 2013.
Apps Granted Permissions
In SharePoint 2013, an app that is granted permissions is not identical to how a user is granted permissions. App permissions have only two options which is they are or are not granted permissions as it is really a simple “yes or no” type scenario.
App permissions have no permissions hierarchy unlike the user permissions strategy and available security hierarchy within a given site collection.
Apps with Default Permissions
An app has that been provided with default permissions has full control over the app web as well as access to incoming query string parameters but does not have default access to the host web. An app with default permissions must include a permission request within its application manifest as the installer actually grants or denies permissions during the installation of the app and will automatically cancel any app install if permissions are denied.
Adding a Permission Request
As mentioned above, an app must have a permissions request added to its application manifest. You can achieve this by opening the AppManifest.xml file in the manifest designer in Visual Studio and adding a permission request for each permission to SharePoint that the web application requires.
The Visual Studio 2013’s SDK provides for project templates, tools, tests, and reference assemblies that are required to build extensions for Visual Studio 2013 and this can be downloaded at the following link: http://www.microsoft.com/en-us/download/details.aspx?id=40758
Server-to-Server (S2S) Trust Architecture
The new server-to-server (S2S) authentication architecture enables your organization’s infrastructure to share resources between various servers in your SharePoint farm. The S2S Trust also provides for access services to other servers such as those that support your Exchange Server 2013 and\or Lync Server 2013 platforms.
The S2S authentication protocol does not just support those servers that run your origination’s other major “Microsoft application stack” technologies as SharePoint 2013’s supports resource sharing and access any server within your organization that is compliant with the S2S protocol.
An overview of the server-to-server (S2S) authentication architecture is shown below:
An S2S Trust consists of:
■ Trusted connection between app and SharePoint
■ OAuth and Access Control Services (ACS) for on-premises farms
■ Trust between servers configured using SSL certificates
■ App code that contains the required access to a private key of an SSL certificate
■ Creation of security token service on SharePoint servers
Azure Access Control Service which is also referred to as Access Control Service or ACS is a Microsoft Azure service that provides an easy way for you to authenticate users to access your web applications and services without having to add complex authentication logic to your code.
The following features are available in ACS:
■ Integration with Windows Identity Foundation (WIF).
■ Support for Active Directory Federation Services (AD FS) 2.0.
■ An Open Data Protocol (OData)-based management service that provides programmatic access to ACS settings.
■ Support for popular web identity providers (IPs) including Microsoft accounts (formerly known as Windows Live ID), Google, Yahoo, and Facebook.
■ A Management Portal that allows administrative access to the ACS settings.
There are nine overall key steps you must take in the configuration of an S2S trust which are as follows:
-
Create a x509 certificate
-
Make the certificates public key accessible to SharePoint
-
Utilize Windows PowerShell to create a trusted security token issuer based on public key
-
Develop a provider-hosted app which has access to the private key file
-
Create S2S access tokens with the help of TokenHelper class
-
Pass access token by calling into SharePoint using the CSOM or REST API
-
Select one of the two available methods to make a certificate available
-
Pass the file path of certificate to SharePoint
-
Expose the certificate from app as metadata endpoint
The underlying architecture of an S2S trust contains the following elements and configurations:
■ App that has x.509 certificate with public/private key pair
■ Private key used to sign certain aspects in access token
■ Public key registered with SharePoint farm
■ The public key creates a trusted security token issuer
■ App creates access token to call into SharePoint, as shown in figure below
■ App creates access token with a specific client ID and signs it with private key
■ Trusted security token issuer validates signature
■ SharePoint establishes app identity
■ App identity maps to a specific client ID
■ Availability to have multiple client IDs associated with a single x.509 certificate