Overview of Oauth in Sharepoint 2013 : Application Authorization - On-Premises App Authentication with S2S

In some situations an organization might need its SharePoint environment and solutions to be purely on-premises. This could be for security reasons, technical reasons such as in disconnected network situations, or simply because on-premises solutions are the company policy. In these situations, using Office 365, Azure Access Control Services (ACS), and apps hosted in Azure will not work. An alternative is to host the apps on premises along with the SharePoint sites and to use Server to Server (S2S) authentication. S2S effectively removes reliance on Azure Access Control Services (ACS). In its place SharePoint acts as the Security Token Service (STS) and predefined certificates are used to sign and verify the tokens that are generated. S2S uses extensions to the OAuth 2.0 protocol that are not (at the time of this writing) currently part of the OAuth 2.0 standard, but have been submitted by Microsoft for future inclusion.

Applications that run using S2S are also said to be “high-trust” apps. High-trust apps must authenticate users independently themselves versus being passed a trusted identity as part of the context token from SharePoint. Typically, applications would authenticate a user using Windows Authentication (NTLM) or a similar scheme. High-trust apps are considered “high trust” because SharePoint trusts the application and trusts that it has authenticated and identified the user context being passed as part of an API call.

Part of the reason why high-trust apps establish the identity of users themselves is because of other authentication/authorization needs in on-premises scenarios. Take, for example, the scenario where a financial organization needs to keep all its data on premises for regulatory reasons. It builds an app that works with data in a variety of other on-premises systems and its organization uses Active Directory (AD) to manage users and security in those systems. A high-trust app would use a user’s Windows identity to authenticate him and check his permissions; that same identity could also be used for downstream systems such as SQL Server.

This means that high-trust apps can play in the same playground as other on-premises applications and, most importantly, use the same internally mandated authorization and authentication system.

Setting up S2S authentication requires a number of manual setup steps for it to work properly. Following them correctly is important to ensure proper authentication operation.

You must setup and configure two items prior to starting the S2S configuration:

• User Profile Service Application
• App isolation

For more setup steps for app isolation, see the following MSDN document: http://msdn.microsoft.com/en-us/library/office/apps/fp179923.aspx.

After you have the prerequisites set up then you can complete the following:

After completing the preceding items, you can start building Provider-hosted apps that are deployed on premises with IIS and SharePoint. The app and SharePoint are able to generate and verify the tokens required based on the trust set up with the certificate. You’ll need to create a certificate so that your app can generate and verify the tokens. You can either create a self-signed certificate or use a certificate obtained from a certificate issuing authority. A self-signed certificate is simply a certificate that you sign yourself rather than obtaining it from a trusted issuing authority, and, for the purposes of these steps, is adequate to use. To create a self-signed certificate, follow these steps (Windows Server 2012):

You are now ready to register a new app identity in SharePoint. To do this, you can use the following PowerShell script. You need to generate a new GUID for the $clientid value, set the path to your certificate, and set the name of the app appropriately.

$clientid= "7c17e591-f4da-46fc-b85c-a22a6b09c059"
$publicCertificatePath = "C:\MyAppCert.cer"
 
$certificate = Get-PfxCertificate $publicCertificatePath
$web = Get-SPWeb "http://servername"
$realm = Get-SPAuthenticationRealm -ServiceContext $web.Site
$fullAppIdentifier = $issuerId + '@' + $realm
 
New-SPTrustedSecurityTokenIssuer -Name "My App" 
-Certificate $certificate -RegisteredIssuerName $fullAppIdentifier
 
Register-SPAppPrincipal -NameIdentifier $fullAppIdentifier -Site $web 
-DisplayName "My App"
 
$serviceConfig = Get-SPSecurityTokenServiceConfig
$serviceConfig.AllowOAuthOverHttp = $true
$serviceConfig.Update()

The preceding script does the following:

• Sets up a new trusted security token issuer.
• Creates a new app identity/registration.
• Turns off SSL for OAuth for development purposes.

Now you are ready to create a Provider-hosted app in Visual Studio using the Microsoft Office Developer Tools for Visual Studio 2012 - Preview 2. Follow these steps: