App Catalog App Authentication
This example illustrates the second
approach to app authentication. In this case, your app is hosted
on-premises in servers that are not a part of the SharePoint farm, and
not in the cloud as in the previous example. The app has been deployed
to the SharePoint app catalog; app catalogs are deployed to web
applications in SharePoint 2013. Apps in the app catalog are assumed to
be more trustworthy than those external to SharePoint, so the app
authentication process is different.
For this scenario, you need to configure a
server-to-server trust relationship between SharePoint and the app.
This type of configuration is also referred to as a high-trust app,
which is an example of a provider-hosted app for use on the premises;
it is not intended to be used in a cloud-hosted environment.
Administrators should not be misled by the terminology “high trust,” so
the following should further clarify what this means:
- A high-trust app does not have “full trust” access, and must still request and be granted access to SharePoint resources.
- The app is considered “high-trust” because it is trusted to
impersonate a user (aka “asserting a user’s identity”), and it is
responsible for creating the user portion of the access token.
- A high-trust app uses a certificate instead of a context token to establish trust.
Figure 2
shows the process for app authentication in this scenario, as described
in the following steps.
1. A user
opens a SharePoint page that renders content from a SharePoint app
catalog app in an iframe. The app is hosted on the intranet (not part
of the SharePoint farm) and uses a self-signed certificate for its
access tokens. The SharePoint resource that is accessed by the app
requires authentication.
2. SharePoint sends the requested page and the iframe to the user’s browser.
3. The user’s browser requests iframe content from the app server.
4. The app
server, which is hosting the app, authenticates the user and generates
an access token signed with its self-signed certificate.
5. The app server sends the resource request and the access token to the SharePoint server.
6. The
SharePoint server authorizes access to the content. If the app’s
permissions and the user’s permissions are sufficient, then the content
is returned to the app server.
7. The iframe content is returned to the user’s browser.
As you can see, even though the actual SharePoint
configuration is more involved in the second example, the OAuth process
is much simpler. This should be expected, as an app that has been
deployed to the app catalog should be trusted to a much greater extent
than one that is hosted outside of the organization. This example was a
good warm-up for the next section, which delves more deeply into S2S
authentication and gives examples of how it is useful to enable
different servers to share information.
