App authentication is the validation of an external app for SharePoint’s identity. It also allows for the authorization of both the app and an associated user. For this to occur, the app requests access to a secured SharePoint resource. An external component from SharePoint Store App or an App Catalog App that is located on the intranet or internet attempts to serve content. This allows for a new set of functions to be achieved. It enables the apps to include data that comes from SharePoint resources that can be displayed for users.
In order to provide the requested resources from an app through SharePoint, the server has to run SharePoint 2013. It must be able to perform the following:
- Verify the requesting app is trusted
- Authenticate the requesting app. The server that runs SharePoint 2013 must be configured to trust the app sending it.
- Verify the type of access that the app is requesting has been authorized.
Authorize access of the app set permissions from SharePoint 2013. These permissions are associated with the user who the app is working for. It also relies on the permissions that have been granted to the SP App Principal when the trust was established with the Set-SP App Principal Permission Windows in Powershell cmdlet.
For app authentication to work in SharePoint 2013, it is separated from the user authentication. It isn’t used as a sign in authentication protocol for the SharePoint users. The app authentication will use the Open Authorization (OAuth) 2.0 Protocol. It isn’t added to the set of user authentication or sign on protocols including WS Federation. This is why app authentication and OAuth don’t appear in the list of identity providers.
There are several tasks involved with planning for app authentication including:
- Identify the set of trust relationships that have to be configured on a farm that will run SharePoint 2013. They need to correspond to the external apps that will be able to make request for SharePoint resources.
- Provide incoming access that will be hosted by the internet from external applications.
All web applications that include app authentication endpoints for the incoming requests by apps for SharePoint 2013 have to be configured to use SSL. This can be configured with OAuth in SharePoint 2013 and that doesn’t require SSL. You will need to plan for app authentication with a SharePoint farm if you are using 1 or more external apps that share their external resources through SharePoint.
It is necessary to configure the SharePoint farm so that it can trust the access tokens for corresponding to the resource requests. They will need to allow the following types of external apps to send:
- Autohosted apps that run as web role for Windows Azure and that use the Windows Azure Access Control Service (ACS) in an effort to get the access token.
- Autohosted apps will need to be configured so that the SharePoint farm is able to trust the ACS instance of the autohosted app.
- With provider hosted apps, they will need to run their own servers on the internet or intranet. They need to be registered with Windows Azure and use ACS in order to obtain the token for access.
- Provider hosted apps will need to be configured for the SharePoint farm to trust the ACS instance of the provider hosted app.
- High trusted apps will run on stand-alone servers on the intranet. They use a signing certificate to digitally sign the access tokens that the app will generate.
When there is an external autohost or provider host app on the internet, you must configure a reverse web proxy. This will be used to perform the authentication and to request resources from intranet SharePoint farms. The configured reverse web proxy found at the edge of the network needs to allow incoming HTTP over SSL connections from the apps to your SharePoint farms.
You will need to identify the HTTPS based URLS that the external applications are going to access and configure. This allows the reverse proxy to publish those URLS and to provide the right level of security.
With high trust apps, they generate their own access tokens. This includes an assertion of the identity of the user who they are acting on behalf of. The server running SharePoint 2013 also services the incoming resource request. This allows the request for a specific SharePoint user to be resolved. This process is called re-hydrating the identity of the user. This is different from app authentication for auto hosted or provider hosted apps. They will identify the user but not assert them.
When rehydrating the identity of the user, the server runs SharePoint 2013 to take the claims from the incoming access token. Then it will resolve it to a specific SharePoint user. The default for SharePoint 2013 includes the built in user profile service application as the identity resolver.
There are key attributes for users through the identity re-hydration including:
- Windows Security Identifier (SID)
- Active Directory Domain Services (AD DS)
- User Principal Name (UPN)
- Simple Mail Transfer Protocol (SMTP)
- Session Initiation Protocol (SIP)
The app must have at least 1 of these user attributes in place. That attribute must be current in user profiles. It is recommended that you periodically sync from identity stores to the user profile service application. SharePoint 2013 expects 1 entry in the user profile service application for a given query. It can be based on these attributes. It can return an error condition if there are multiple user profiles found. That is why it is recommended to delete older user profiles from the user profile service application on a regular basis. If there are user profiles and group memberships not synced, then the user will experience a denial of access when they try to access a given resource. To avoid this, always make sure the memberships are synced with the user profile service application.