Export (0) Print
Expand All

Plan for app authentication in SharePoint 2013

SharePoint 2013
 

Applies to: SharePoint Server 2013 Standard, SharePoint Server 2013 Enterprise, SharePoint Foundation 2013

Topic Last Modified: 2014-09-09

Summary: Learn how to plan for app authentication in SharePoint 2013.

App authentication is the validation of an external app for SharePoint's identity and the authorization of both the app and an associated user when the app requests access to a secured SharePoint resource. App authentication occurs when an external component of a SharePoint Store app or an App Catalog app, such as a web server that is located on the intranet or the Internet, attempts to access a secured SharePoint resource. For example, an app for SharePoint that includes a component that runs in Microsoft Azure is an external app. App authentication enables a new set of functionality and scenarios that can be achieved by allowing apps to include data from SharePoint resources in the results that the app processes and displays for users.

To provide the requested resources from an app for SharePoint, the server that runs SharePoint 2013 must do the following:

  • Verify that the requesting app is trusted.

    To authenticate the requesting app, you must configure the server that runs SharePoint 2013 to trust the app that is sending it requests. This is a one-way trust relationship.

  • Verify that the type of access that the app is requesting is authorized.

    To authorize the access, SharePoint 2013 relies on the set of app permissions, which was specified in the app manifest file when it was installed, and the permissions that are associated with the user on whose behalf the app is acting. SharePoint 2013 also relies on the permissions that were granted to the SPAppPrincipal when the trust was established by using the Set-SPAppPrincipalPermission Windows PowerShell cmdlet.

Note that app authentication in SharePoint 2013 is separate from user authentication and is not used as a sign-in authentication protocol by SharePoint users. App authentication uses the Open Authorization (OAuth) 2.0 protocol and does not add to the set of user authentication or sign-on protocols, such as WS-Federation. There are no new user authentication protocols in SharePoint 2013. App authentication and OAuth do not appear in the list of identity providers.

In this article:

Planning for app authentication consists of the following tasks:

  • Identify the set of trust relationships that you have to configure on a farm that runs SharePoint 2013 that correspond to the external apps that will be making requests for SharePoint resources.

  • Provide incoming access from external applications that the Internet hosts.

ImportantImportant:
The web applications that include app authentication endpoints (for incoming requests by apps for SharePoint) must be configured to use Secure Sockets Layer (SSL). You can configure OAuth in SharePoint 2013 so that it does not require SSL. However, we recommend this only for evaluation, for ease of configuration or to create an app development environment.
NoteNote:
You only have to plan for app authentication on a SharePoint farm if you are using one or more external apps for SharePoint that require its resources.

You must configure the SharePoint farm to trust the access tokens that correspond to resource requests that the following types of external apps send:

  • Provider-hosted apps run on their own servers on the Internet or your intranet, are registered with Microsoft Azure, and use ACS to obtain the access token.

    For provider-hosted apps, you must configure the SharePoint farm to trust the ACS instance of the provider-hosted app.

    For more information about provider-hosted apps, see Overview of apps for SharePoint 2013.

  • High-trust apps run on stand-alone servers on your intranet and use a signing certificate to digitally sign the access tokens that the app generates.

    High-trust apps use the server-to-server protocol to request resources on behalf of a user. For high-trust apps, configure the SharePoint farm with the JavaScript Object Notation (JSON) metadata endpoint of the server that hosts the app. Or, you can manually configure the trust. For more information, see Configure app authentication in SharePoint Server 2013

    For more information about high-trust apps, see How to: Create high-trust apps for SharePoint 2013 using the server-to-server protocol.

An on-premises app is either a provider-hosted app that is hosted on an on-premises server or a SharePoint hosted app. Table 1 lists the different authentication user methods of SharePoint 2013 and whether that method can be used for SharePoint 2013 on-premises apps.

Table 1. User authentication methods and support by on-premises apps

Authentication method Supported by SharePoint hosted apps Supported by Provider hosted apps

NTLM

Yes

Yes

Kerberos

Yes, but only when it is configured to use NTLM as a fallback authentication method. Kerberos-only is not supported.

Yes

Basic

Yes

Yes

Anonymous

Yes

Yes

Forms-based authentication using the default ASP.NET provider

Yes

Yes

Forms-based authentication using Lightweight Directory Access Protocol (LDAP)

Yes

Yes

Security Assertion Markup Language (SAML) authentication

Yes, if the identity provider supports wildcard return uniform resource locator (URL) registration and honors the wreply parameter. For more information, see WS-Federation: Passive Requestor Profile.

To configure SharePoint 2013 to use the wreply parameter, use the following commands at a Windows PowerShell command prompt:

$p = Get-SPTrustedIdentityTokenIssuer
$p.UseWReplyParameter = $true
$p.Update()
NoteNote:
Active Directory Federation Services (AD FS) 2.0 version does not support wildcard for return URL registration.

Yes

For more information about user authentication methods in SharePoint 2013, see Plan for user authentication methods in SharePoint 2013.

If external provider-hosted apps are located on the Internet, you have to configure a reverse web proxy to perform app authentication and request resources from intranet SharePoint farms. A configured reverse web proxy at the edge of your network has to allow incoming HTTP over SSL (HTTPS) connections from the apps to your SharePoint farms. You typically identify the HTTPS-based URLs that the external applications will access and configure the reverse proxy to publish those URLs and provide the appropriate security.

High-trust apps generate their own access tokens, which include an assertion of the identity of the user on whose behalf they are acting. The server that runs SharePoint 2013 and services the incoming resource request must be able to resolve the request to a specific SharePoint user, a process known as rehydrating the user’s identity. Note that this differs from app authentication for provider-hosted apps, in which the user is identified, but not asserted.

To rehydrate a user’s identity, a server that runs SharePoint 2013 takes the claims from the incoming access token and resolves it to a specific SharePoint user. By default, SharePoint 2013 uses the built-in User Profile service application as the identity resolver.

The key user attributes for user identity rehydration are as follows:

  • The Windows Security Identifier (SID)

  • The Active Directory Domain Services (AD DS) user principal name (UPN)

  • The Simple Mail Transfer Protocol (SMTP) address

  • The Session Initiation Protocol (SIP) address

Therefore, the app must include at least one of these user attributes and that attribute must be current in user profiles. We recommend a periodic synchronization from identity stores to the User Profile service application.

Furthermore, SharePoint 2013 expects only one entry in the User Profile service application for a given lookup query that is based on one or more of these four attributes. Otherwise, it returns an error condition that multiple user profiles were found. Therefore, you should delete obsolete user profiles in the User Profile service application periodically to avoid multiple user profiles.

If a user profile exists for a user and the relevant group memberships are not synchronized, access may be denied when the user is supposed to be granted access for a given resource. Therefore, make sure that group memberships are synchronized with the User Profile service application.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft