It is hard not to be aware of the existence of Apps. Made hugely popular by the smart phone and iPad markets, these little programs can be downloaded from different types of App stores against a fee, or sometimes completely free of charge. After that, those Apps run on some type of client device, fulfilling the personal needs of the owner of that client device. SharePoint 2013 innovates that game by introducing Apps targeted towards the enterprise instead of the consumer.

Note App stores are becoming increasingly important in the Microsoft world. You will not only find an App store for SharePoint, App stores are also integrated within Windows 8 and Office 2013.

The introduction of Apps to the SharePoint platform is likely the one new feature that is the biggest eye catcher of all. Or, as Brian Jones (Group Program Manager on the Office Solutions Framework team) stated it with some sense of drama: “It’s the most significant thing we’ve done with the (Office) platform in 15 years since the introduction of Visual Basic for Applications (VBA)”.

At first, Apps may sound like nothing more than a change in brand name. In SharePoint 2013, lists are Apps, document libraries are Apps, site pages are Apps, event handlers are Apps, and so on. “Everything is now considered an app”, is a quote from Richard Riley, Director of Product Management for SharePoint. You will likely hear this quote, or something similar, a lot when talking about SharePoint 2013. You may also think about Apps as a logical evolution in the way SharePoint solutions are built and made available to the platform, and you wouldn’t be wrong. But you will see that Apps are more. Firstly, this blog post will teach you that Apps are in fact a paradigm shift in the way the SharePoint platform can be customized by 3^rd parties. Secondly, you will learn how to deal with this new paradigm.

Apps, the SharePoint Store, and the Corporate Marketplace

With SharePoint 2013, the platform has in-built support for Apps, which provide functionality that allows you to customize SharePoint. Or, to put it in other words, Apps are ready-to-use solutions. The term App doesn’t just apply to third-party efforts, basically everything that is there in SharePoint out of the box is now also designated as an App. For example, now lists, libraries, tasks, and calendars all are Apps.

Note Apps are reusable pieces of functionality. Sounds familiar? This does sound a lot like the definition of a web part. The big difference being that web parts are hosted and executed on the SharePoint servers themselves. As you will see later on, SharePoint Apps don’t have to be.

The main reason for introducing Apps to the enterprise market is to make it real easy, but also safe, to extend your existing SharePoint platform with third-party Apps. To facilitate this and make life easier for Microsoft Independent Software Vendors (ISV) partners, Microsoft has introduced an online App store called the SharePoint Store, which is itself hosted in the cloud. SharePoint Store is directly integrated with SharePoint 2013 (in the on-premises variant as well as the Office 365 cloud variant) so that it’s real easy to acquire, buy and manage these Apps. The SharePoint Store shares the same back-end as the Office Store and is hosted on Office.com. Alternatively, you can get Apps from on-premises Corporate Catalogs. It is to be expected that Apps will provide various services, like:

· Site templates, Apps can provide ready-to-use site templates targeted towards specific branches.

· Site add-ons, Apps can enhance existing functionality by, for instance, adding new ribbon buttons that provide some type of new feature.

· Web parts, Apps can provide pieces of reusable functionality in the form of web parts that make sense in the enterprise sphere.

· Branding, Apps can provide custom branding themes by providing CSS files and JavaScript.

· Application Integration, Apps can integrate with external services, such as the ones offered in the Azure Marketplace (https://datamarket.azure.com/ ).

· Independent Line of Business (LOB) applications that integrate with SharePoint, Apps can provide an immersive full page solution that is still tied in to SharePoint.

The SharePoint Store has its own integrated payment system and it’s possible to allow end users to install Apps without requiring server administrators to be involved with the deployment and activation of Apps. Apps, after undergoing a rigorous validation process conducted by Microsoft, can be admitted to the SharePoint Store.

At the time of writing, the SharePoint Store is still in preview and the offering is still limited. The possibilities are endless though. To mention a few, there are Apps that offer Facebook integration, offer Digital Asset Management capabilities for working with paper documents, extend the SharePoint ribbon with the possibility to create compound documents, and offer an HTML 5 workflow creation tool. As may be clear, the range of possibilities is endless end the surface has barely been scratched.

Understanding the SharePoint App Model

If you take a look at the history of the SharePoint platform, you can tell there has been an evolution in the way the platform could be customized by 3^rd parties. Always, there was a need for balance between the security/stability of the platform versus the power required by 3^rd party customizations to offer useful solutions.

In the 2001 version, you could run web part code directly within page execution, in the same process, in the same thread, using either the JavaScript Eval or VBScript Execute functions. The power was limited to running either VBScript or JavaScript, and the potential disruptive force in the area of stability of the custom scripts during the normal page execution life cycle was huge.

The 2003 version was the first step towards maturity. Customizations were deployed to the server and ran under a strict set of privileges defined by various Code Access Security (CAS) policies, or full trust. This allowed IT Pros, if they chose to do so, to limit the potentially dangerous actions that could be executed by custom assemblies. At the same time, SharePoint web applications could be separated between multiple IIS Application Pools running in separate processes, thereby limiting the impact a single SharePoint web app could have on another. But still, custom code was executed on one or more servers of the SharePoint farm and could definitely have their impact on the performance and stability of such servers.

The development model didn’t really change in the 2007 version, although one major issue was addressed: a fool-proof way was added that allowed solutions to impersonate user accounts and run code in an elevated context. Other than that, as far as the available development models went, not much changed.

The development model did change in version 2010. Sandboxed solutions were introduced. They could be uploaded by site collection users and ran in a special and safe sandbox (in its separate process); under the control of a very strict Code Access Security policy to ensure sandboxed solutions couldn’t do any real harm. For instance, sandboxed solutions were allowed to execute a subset of the SharePoint server-side object model, but didn’t have read/write access to the file system, registry, or database. Another new feature was that sandboxed solutions could not only be run in on premises SharePoint farms, but also in SharePoint Online. To top it all, there was a sandbox resource limitation mechanism that allowed IT Pros to specify resource throttling settings to prevent sandbox solutions from over expanding server resources.

SharePoint Server 2013 brings a new addition to the available development models: the App model. To put it in black-and-white, the App model allows you to customize your SharePoint farm by running code outside your farm. For the first time, it is possible to develop custom solutions that are unable to affect your SharePoint farm in a direct way, since they are no longer a part of that farm. In the next sections, you will see how Apps are able to do that.

SharePoint App Architecture

As established earlier, SharePoint Apps provide custom pieces of functionality and have the capability to run isolated from your SharePoint farm. What an App can do exactly is determined by three factors (and you will learn about each of these factors later on in this section):

· App scope

· App permissions

· App authorization policy

In order for these factors to have an effect on Apps, every App needs to have its own App identity that can be used to recognize the App and associate the App to a security principal, which is also known as the App principal. The App principal needs to contain 5 pieces of information:

· App ID (also known as the client ID), a GUID that uniquely identifies the App.

· App Secret, a signing key that consists of a Base64 encoded string that is used by various parties to encrypt and decrypt messages and send it across the network.

· App Title, the friendly SharePoint App name.

· App URI, typically the base DNS name required to get to the App, such as https://myappserver.mydomain.com.

· Redirect URL (optional), in some cases the SharePoint App wants to increase the permissions it has been given programmatically. In such cases, SharePoint will respond by calling the Redirect URL that has been specified as part of the App Principal and send its answers along with this response.

Important The App Identity is great for tracking App activities via the SharePoint Audit Trail mechanism.

App Principals can be retrieved via the following page (be warned: it’s not a very user friendly UI):

http://%5Bserver name] /_layouts/15/appprincipals.aspx

Apps have two different ways to retrieve their App identity:

· From Azure Access Control Service (ACS) over the OAuth protocol, see section “OAuth” for more information.

· From a High Trust Relationship (via S2S trust and certificates), see section “High-Trust Apps” for more information.

NOTE The notion of applications having their own identity recognized apart from user identities sets OAuth and S2S apart from other authorization protocols.

Every App is shipped with an App manifest file (an XML file called appmanifest.xml), which contains essential information about the App and its configuration. The following is considered to be the essential information about Apps:

· The App Client ID

· The App display name

· The App domain

· The App version number

Then, there is information in the App manifest pertaining to its configuration, such as:

· The URL of the App start page, the page that opens when the App is started. This can be any page located anywhere, the sole requirement is that the file type of the start page must be able to support HTTP POST requests (so, for example, images as start pages are out of the question, but ASP.NET or PHP pages are perfectly acceptable).

· A list of App prerequisites (for example, certain features or services that just have to be there in order for the App to be able to run correctly).

· App scope, authorization policies, and permission requests for that scope.

· Other properties such as supported locales (i.e., en-US, nl-NL).

The following fragment shows some example content of an App manifest file:

<?xml version=”1.0″ encoding=”utf-8″ ?>

<App xmlns=”http://schemas.microsoft.com/sharepoint/2012/app/manifest&#8221;

ProductID=”{ff01dda0-712e-62c4-c224-d4d522d2286d}”

Version=”1.0.0.0″

SharePointMinVersion=”15.0.0.0″

Name=”TheCustomApp”

> 

<Properties>

<Title>The Custom App</Title>

<StartPage>~remoteAppUrl /default.aspx/?SPHostUrl={HostUrl}</StartPage>

<SupportedLocales>

<SupportedLocale CultureName=”en-US” />

<SupportedLocale CultureName=”nl-NL” />

</SupportedLocales>

</Properties>

<AppPermissionRequests AllowAppOnlyPolicy=”true”>

<AppPermissionRequest Scope=”http://sharepoint/content/sitecollection/web/list&#8221; Right=”Write”/>

</AppPermissionRequests>

<AppPrincipal>

<RemoteWebApplication ClientId=”2ab64d52-6b4d-688f-e44f-bb453baad652″ />

</AppPrincipal>

</App>

Note You may have noticed that there is some magic surrounding the URLs of the start page and permission request. The format of the start page looked like this: ~remoteAppUrl/default.aspx/?SPHostUrl={HostUrl}, and as you can see it contains some tokens that can be used within the URLs. ~remoteAppUrl stands for the URL of the remote web application in an App for SharePoint, {HostUrl} is replaced by the URL of the host web of an App for SharePoint. See http://msdn.microsoft.com/en-us/library/jj163816(v=office.15).aspx for an overview of the available tokens. The format of the URI of the permission request in the <AppPermissionRequest> element was in this form: http:// sharepoint/content/sitecollection/web/list. This is because permission requests are made without intimate knowledge of the topology of the SharePoint site collection where the App gets installed. So, instead of specifying a specific SharePoint URL, you need to specify a generic URI. To complete the discussion about tokens and URL formatting, see http://msdn.microsoft.com/en-us/library/ms431831(v=office.15).aspx for an overview of generic SharePoint URL tokens.

When an App is installed within a SharePoint environment, this environment is called the Host. Once an App gets installed in a SharePoint site, this site is called the Host Web. It’s possible that the App needs a place to store specific App resources or declarative items, such as lists, site pages, CSS files, and JavaScript files. These resources won’t be added to the Host Web, they’re added to a dedicated child site called the App Web. If an App doesn’t contain any resources, no App Web will be created.

The end user who is installing the App is shown which permissions the App wants, based on the permissions requested in the App manifest file, and then it’s up to the end user to decide if the App is granted those permissions. This is an all or nothing thing: Apps can choose from one of the predefined permission sets and can’t create custom ones, and end users either grant the App all of the permissions requested or none at all.

Note There are multiple events that lead to a change in permissions assigned to Apps: the App is installed by the site administrator, the App is explicitly granted permission by a tenant administrator or site administrator, the end user gives consent, or the App is removed.

After granting permissions to Apps, you can’t modify them, so that the App won’t be broken because of it. Of course, it is possible to revoke App permissions, see section “Uninstalling Apps” for more information. End users can only grant permissions they actually have, or the installation fails.

Important At this point, the App has made clear which permissions it needs, but also to which scope those permissions apply and which authorization policy will be used. Under water, it’s the App principal that gets associated to specific SharePoint permissions and rights.

The scopes to which App permissions can apply are these:

· SharePoint Site collection, permissions apply to the entire site collection (including all children, such as sites, lists, and list items) where the App is installed. In the App manifest file, this scope is represented using the following URI: http://sharepoint/content/sitecollection/.

· SharePoint site, permissions apply to the entire SharePoint site (including all children, such as lists, and list items) where the App is installed. In the App manifest file, this scope is represented using the following URI: http://sharepoint/content/sitecollection/web. If you want to use a site-scoped App, you need to install it for each and every SharePoint site where you want to use the App.

· SharePoint list, permissions apply to the entire list (including all children, such as list items) where the App is installed. In the App manifest file, this scope is represented using the following URI: http://sharepoint/content/sitecollection/web/list.

· Tenancy, permissions apply to the tenancy where the App is installed. In the App manifest file, this scope is represented using the following URI: http://sharepoint/content/tenant. Tenancy-scoped Apps are installed in a single App Catalog site and are available for use in multiple host webs (as opposed to site-scoped Apps). This means that every host web accesses one single App instance, which centralizes App management.

· Feature, scopes can apply to specific SharePoint features, such as Search, Business Connectivity Services (BCS), and Project Server 2013. All other URIs referred to content stored in the SharePoint content database only. The way feature URIs look depends upon the specific feature.

Important All App permissions that were mentioned apply to resources in the SharePoint host environment. By default, Apps get Full Control rights over their corresponding App web.

The site collection, site, list, and feature scopes are probably familiar to you. The Tenancy scope may require a little further explanation. A SharePoint 2013 tenancy is a set of site collections in either a SharePoint farm or SharePoint Online. Usually, a tenancy relates to a single customer in a SharePoint environment used by multiple customers. A tenancy can be an entire site collection, or a subset of them, and the format of a tenancy URL looks like this (the content part reflects the fact that you’re accessing content stored in the SharePoint content database): http://sharepoint/content/tenant.

More Info For more information about tenancies, please refer to http://msdn.microsoft.com/en-us/library/fp179896(v=office.15).aspx .

Next to App permissions and scope, App authorization policies are a key factor in determining what Apps can do. The following App authorization policies are available:

· User and App policy, both the App as well as the current SharePoint end user have to have sufficient permissions in SharePoint to execute an operation. This policy is mandatory for SharePoint Store Apps that call back to SharePoint resources.

· App Only, only the App needs to have sufficient permissions to execute an operation. This is a good policy when the App is not impersonating end user actions in any way. The end user installing the App must have site collection administrator rights in order to grant the App the use of this policy. All operations executed by Apps under this policy run under the special SHAREPOINT\APP account.

Note Apps that do not make OAuth authenticated calls can’t use this policy. In addition, some APIs, such as the Search API, require the presence of a user context and therefore won’t run under the App Only policy.

· User Only, the current SharePoint end user needs to have sufficient permissions in order for the App to complete an operation successfully. This is a good policy when end user resources are accessed.

Each App can choose between four different, predefined permission sets to access SharePoint content:

· Read-Only, these rights correspond to the end user Reader default permission level. This allows an App to view pages, list items, and download documents.

· Write, these rights correspond to the end user Contributor default permission level. This allows an App to view, add, update, and delete list and library items.

· Manage, these rights correspond to the end user Designer default permission level. This allows an App to view, add, update, delete, approve, and customize items or pages within a SharePoint site.

· FullControl, these rights correspond to the end user Full Control default permission level. This allows an App to have full control within the specified scope.

Important See http://technet.microsoft.com/en-us/library/jj219576(office.15).aspx[ for a detailed overview of the exact permissions that are included in each set. It’s important to note that separate SharePoint features can have separate scopes and available permission sets. For example, the scope for Business Connectivity Services (BCS) applies to BCS connections, and you can only assign Apps Read permissions. For Search, there’s a permission set that won’t be found in the standard collection of permission sets: the QueryAsUserIgnoreAppPrincipal permission set. See http://msdn.microsoft.com/en-us/library/fp142383(v=office.15).aspx for more details.

When Apps are stored in the cloud, their App Manifest data is stored in ACS. To make it possible to install such Apps, SharePoint 2013 introduces a new service application called the Apps Service Application. The main responsibility of the Apps Service Application is to store basic information about Apps, their related App licenses (when Apps are downloaded from the SharePoint Store) and related App permissions.

Note The place where this information is stored is also known as the Storefront. First of all, you can use the Storefront to view all Apps in the SharePoint Store (so that SharePoint users don’t have to go to Office.com themselves). All Apps that are downloaded from the SharePoint Store, or from other places that will be discussed shortly, are persisted in this Storefront. Access to the Storefront is not just restricted to site collection administrators; in principle every site user can be granted access to it.

The Apps Service Application is consulted each time an App is accessed to ensure that the end user has sufficient permissions to make such a request. At this point, you have already learned that you can get Apps from the SharePoint Store, but there are several other options as well. Here’s the overview of the available options when it comes to hosting (and/or retrieving) SharePoint Apps:

· Submit your App to the SharePoint Store, also located in the cloud.

· Place the App in an isolated SharePoint site, but within your SharePoint farm.

· Place the App outside your SharePoint farm, on a dedicated self-hosted application server.

· Place the App outside your SharePoint farm, in the cloud (Azure).

· No hosting, of traditional SharePoint artifacts

Another common way of dividing SharePoint Apps models is this:

· SharePoint hosted

· Cloud (or remote) hosted

You will also find the hosting models divided in a different way: no hosting, SharePoint hosted (where the Apps run inside SharePoint), and provider hosted (cloud or dedicated application server).

App – SharePoint Communication

Before we dive into the different hosting models, it’s interesting to take a look at how exactly Apps communicate with SharePoint, since Apps will typically run outside of the SharePoint environment that are using the Apps. First thing you need to know is that Apps won’t be able to use the SharePoint server object model at all – even when the App runs in its own isolated SharePoint site (and therefore, runs on a SharePoint server). This is a good thing where it concerns the stability of your SharePoint farm.

In 2013, the only means by which Apps can interact with SharePoint have to come from the several client APIs offered by SharePoint. Apps will be more reliant on client-side technology such as JavaScript, jQuery (a very popular JavaScript library), and Ajax techniques to communicate with SharePoint leveraging either SharePoint’s client-side object model (or CSOM, pronounced ceesom) or REST API (also known as OData). The SharePoint client object model comes in different flavors:

1. Managed client object model, which can leveraged by .NET applications (such as a console application or WPF client) or PowerShell script to communicate with SharePoint.

2. Mobile client object model, which can be leveraged by Windows Phone devices.

3. JavaScript client object model, which can be leveraged by JavaScript code to communicate with SharePoint.

4. Silverlight client object model, which can be leveraged by Silverlight applications to communicate with SharePoint.

Since Apps are so reliant on CSOM, the coverage of SharePoint functionality has been extended a great deal. Starting in SharePoint 2013, new APIs are also available within CSOM, such as User Profiles, Search, Taxonomy, Publishing, Workflow, Analytics, E-Discovery, IRM and BCS.

In all forms of the client object model, client-side calls will be made to the CSOM end point, a Windows Communication Foundation (WCF) service called client.svc. In SharePoint 2013, client.svc is extended with REST capabilities (implemented in accordance with the OData protocol) so that it, as opposed to SharePoint 2010, now not only supports the fixed amount of entry points reserved for the different kind of CSOM flavors, but also has direct support of REST clients. In addition, all the CSOM calls can also be made via REST. REST calls will be made via URLs of the following format: [sharepoint url]/_api. Under the cover, these requests will be redirected to client.svc.

Note The new CSOM capabilities overlap with the previous REST endpoint ListData.svc. While new applications should be created using the new CSOM/REST capabilities, old client applications leveraging ListData.svc will still work in SharePoint 2013. In 2013, the new REST API always uses _api in the URL that accesses a REST end point. The following is an example of the format of a REST API call that requests the title of a SharePoint root web: http://ASharePointSiteColl/_api/ASharePointSite/title.

All this results in a major shift for App developers. Where in the previous versions of SharePoint most code was written in C#, or at least server-side code, now App developers will have to shift and write a lot more of their business logic using JavaScript. Microsoft did take care to make these client-side APIs a lot more powerful than they were in the previous version.

As an alternative, applications hosted on a dedicated application server or in the cloud won’t be able to leverage the SharePoint server-side object model, but will be able to leverage the managed client object model to let the App server-side code communicate with SharePoint.

Best Practices It would be a fair assessment if one would state that the App model is best suited for solutions that are mainly oriented towards HTML and JavaScript. From the administrator’s perspective, you can’t overlook the fact that Apps will bring along a lot of additional web traffic, much of it consisting of large blocks of JSON and XML data.

As you have seen, there are a lot of different options when it comes to communicating with SharePoint. Let’s finish this section with some closing advice about when to which option, as this will help you validate design choices made by App developers:

· Apps that offer Create/Read/Update/Delete (CRUD) actions against SharePoint or BCS external data, and are hosted on an application server separated by a firewall benefit most from using the JavaScript client object model.

· Server-side code in Apps that offer Create/Read/Update/Delete (CRUD) actions against SharePoint or BCS external data, and are hosted on an application server but not separated by a firewall mainly benefit from using the managed client object model, but the Silverlight client object model, JavaScript client object model or REST are also options.

· Apps hosted on non-Microsoft technology (more on this later) will need to use REST.

· Windows phone Apps need to use the mobile client object model.

· If an App contains a Silverlight application, it should use the Silverlight client object model.

· Office Apps that also work with SharePoint need to use the JavaScript client object model.

Note Keep track of further insights into best practices concerning the question when it makes sense to use a client API, please visit the following TechNet Wiki page: http://social.technet.microsoft.com/wiki/contents/articles/13637.sharepoint-2013-best-practices-what-client-api-should-you-choose-when-building-apps.aspx.

More Info The following MSDN article contains more information about important aspects of the App for SharePoint architecture and development landscape: http://msdn.microsoft.com/en-us/library/fp179922(v=office.15).aspx.

App Hosting Options

In the next sections, you will learn about the various App Hosting options, such as Cloud hosted, Provider hosted, and SharePoint hosted. At this point, it’s important to understand that the various App Hosting options are not mutually exclusive: it’s perfectly possible that Apps include various components that are hosted differently. For example, think of an App that contains SharePoint hosted components as well as Cloud hosted components.

Apps in the SharePoint Store

Only ISVs will go through the trouble of going to the SharePoint Store submission process, which requires adding Apps to the Office AppHub and undergoing an approval process. Once Apps are approved, they can be found in the SharePoint Store via the SharePoint Storefront in your SharePoint farm and used. The life cycle of a SharePoint Store App looks like this:

1. The ISV or individual software developer creates an App.

2. The App is entered in the official submission process and sent to the Office AppHub.

3. Microsoft validates each and every Apps and checks for potential issues about security, performance, any threats the App might pose to the SharePoint farm, and such.

4. If Microsoft approves and certifies the App, it becomes available in the SharePoint Store (at Office.com).

5. Both your own on premises SharePoint farm and SharePoint Online (your farm in the cloud) have a Storefront. The Storefront is responsible for integrating the SharePoint Store with your own SharePoint environment in a way that is completely transparent for your end users. Storefront uses a set of web services to communicate with the SharePoint Store.

6. End users will leverage the SharePoint UI and use Storefront to retrieve information about Apps that are actually hosted in the SharePoint Store. Please note that both administrators and end users can be allowed to have access to Storefront.

7. At that point, end users can actually buy or get (if the App is free) the App of their choice. By doing this, the App becomes available within SharePoint by hosting it either in the cloud, on a dedicate application server, or as an AppWeb within the SharePoint farm. After that, the App can be executed.

8. Every time an App gets executed, the Apps Management Service will check that the end user has the sufficient amount of permissions to do so. The Apps Management Service will also check if license requirements for that particular App have been fulfilled.

9. If the App is shipped under a licensing model, the App will contact the SharePoint Store at Office.com to validate if the end user is allowed to use the App.

10. The App UI will be generated and rendered by the App host (cloud, application server, or AppWeb).

The life cycle for a custom App that isn’t submitted to the SharePoint Store (a situation you’ll typically find for in-house development scenarios) is a little bit different. Instead of submitting the App to the SharePoint Store, it will be packaged and the SharePoint administrator will manually add that package to a Corporate Catalog. After adding the App to the Corporate Catalog, it too will become available via Storefront, where it can be selected by the end user. Figure 1 clarifies the App lifecycle as discussed so far:

Figure 1 The SharePoint App lifecycle: from App submission to usage.

Now let’s look at more detail at the architecture of what happens once the App is installed and ready for use.

1. The end user wants to use a specific App.

2. This request is received by the Web Front-End (WFE).

3. The WFE, via its service application proxy, calls the Apps Management Service.

4. The Apps Management Service decides what information regarding permissions and licenses needs to be retrieved from the database, but doesn’t retrieve this information itself. Instead, it returns control to the WFE. For performance reasons, the WFE caches the location of the Apps Management database. Therefore, it is more efficient if the WFE, and not the Apps Management Service, retrieves the required information.

5. The WFE retrieves information surrounding App permissions and licensing from the Apps Management database.

This is the normal workflow of a normal App request, which is displayed in Figure 2. If you manage Apps (for example, by using the administration UI or PowerShell commands) things work a little differently. Such administrative requests are directed directly against the Apps Management Service, instead of to the WFE, as was the case during a normal App request. Again, to optimize performance, the Apps Management Service won’t interact with its service application database, but will leave that to the WFE.

Figure 2 A depiction of the general SharePoint App communication flow.

Apps in an isolated SharePoint site

In this hosting option, Apps are still hosted on-premises within SharePoint, although they run completely isolated. This type of App is generally called a SharePoint Hosted App and comes in two flavors:

· AppWebs

· App Parts

Let’s start with a discussion of AppWebs. During this hosting mode, whenever an App is installed, a new SharePoint site is created that will house the App. This SharePoint site is called the AppWeb. AppWebs can’t be modified using either SharePoint Designer or the browser UI, to make sure end users are unable to interfere with the correct running of the App.

AppWebs need to be created as sub sites of the SharePoint site collection, but AppWebs don’t have to be immediate children of the root site. AppWebs provide their own chrome and contextual elements, but the permissions are provided by the parent web and the parent context is also passed to the AppWeb so that the client object model (CSOM) can make calls to resources located in the parent site, thus making it easy for the App to interact with SharePoint. However, despite their ability to communicate with their parent web sites, AppWebs can’t communicate with other AppWebs. AppWebs are made visible in the UI via an IFrame in the parent site.

The other flavor of SharePoint-hosted apps is the App part, also known as a Client Web Part. The App part is nothing more than an IFrame which can be added to any page and provides access to some remote resource.

Apps on an Application Server

Microsoft Support has found that the most common reason for issues in farms is caused by custom code. The greatest thing about hosting Apps on dedicated application servers is that it’s guaranteed that your SharePoint farm won’t be harmed anymore by custom code, while still leaving you in full control of the environment. Such Apps are the first example of Provider-hosted Apps. The Apps are stand-alone applications that run completely outside of your SharePoint farm, and SharePoint is completely technology-agnostic as far as these Apps go. This means, Apps can be hosted on any technology, such as application servers running on components of the LAMP stack (Linux, Apache, MySQL, and PHP).

Best Practices This particular feature was hailed enthusiastically by developers. I don’t share the sentiment. Although in itself it’s great to have the flexibility to use any flavor of application server you like, in reality I’ve found that this type of platform independence is almost never an issue. If you’re an avid Java or PHP developer planning to build Apps, you’ll find that you still have to have intimate knowledge of SharePoint technology and development models, as well as access to SharePoint-friendly tools. I’m convinced that the share of skilled Java and SharePoint developers is pretty limited. In addition, some people have even predicted the end of the era of SharePoint developers, since now every ASP.NET developer will be able to create Apps as well. I think this is a wrong conclusion, for exactly the same reasons. If you want to develop SharePoint solutions, you need the knowledge about the platform. You simply can’t do that, while avoiding becoming a “SharePoint” developer.

Apps on a dedicated application server are the first example of provider-hosted Apps. The interesting thing about provider-hosted Apps is that as soon as end user clicks on the App icon in the UI, the end user gets redirected to a destination web site located on the application server. The App can then leverage a set of available JavaScript libraries that enable the retrieval and display of basic chrome elements from the referring SharePoint site (including the basic stylesheet of that referring site). Apps can interact with the referring SharePoint site and execute callbacks to the referring SharePoint site collection and web resources. Apps will rely heavily on JavaScript to execute asynchronous JavaScript client object model calls and/or REST calls that allow the App to communicate with the SharePoint referral context.

In addition to running Apps on a dedicated application server, on-premises, it’s also possible to host Apps on dedicated remote application servers, under the control of a 3^rd party vendor. The biggest advantage of running Apps on dedicated application servers is twofold: not only is it guaranteed that executing custom Apps won’t affect your SharePoint farm directly, if custom Apps don’t perform well enough you don’t have to scale SharePoint anymore: it’s sufficient to just scale the App causing trouble. From a management perspective, this is truly a great thing.

Apps in the Cloud

In essence, this option is identical to hosting Apps on a dedicated application server, with the big difference that in this scenario Apps are hosted in the cloud (Azure), within the Azure Web role. Therefore, this type of Apps is called Azure Hosted Apps. Azure Hosted Apps won’t be hosted in a dedicated cloud space provided by the App developer and shared by all customers. During installation, every App is installed in the cloud space of the customer: it will create Web, worker, and database roles as required. The App developer/vendor can ensure that the infrastructure that is external to SharePoint but required for the App is created in Azure during the App deployment process, but the customer is responsible for paying the costs associated to such an infrastructure. Because of this, these types of Apps are also known as Azure auto-provisioned Apps.

No Hosting

It may come as a bit of a surprise, but SharePoint Apps also come in a flavor where they don’t have to be hosted at all. In this case, it concerns Apps that contain classic SharePoint artifacts, such as content types, fields based on existing field types (but not custom field types or CFTs) such as the Calculated and Computed field types, remote site pages that can also include built-in SharePoint web parts, remote event receivers, list templates, and web templates. Such Apps can be deployed directly into the target SharePoint site.

What Apps can’t do

SharePoint Apps are quite powerful, but you need to be aware that there are certain things you can’t do. This section provides an overview of App limitations.

Best Practices Now we have arrived at what I think are two of the biggest drawbacks of the current App model: although Apps can use a basic stylesheet of the referring site, so far it doesn’t look as though Apps provide a seamless UI experience, but customers will expect nothing less. A second thing is that Apps, as opposed to previous versions that were dominated by server-side, object-oriented code, will now for a large part be written in JavaScript. It’s easily possible that this will lead to spaghetti code. It remains to be seen how App developers will respond to these challenges.

Within Apps, you can’t:

· Create custom web parts, although Apps can provide similar functionality in the form of site pages containing SharePoint web parts or App parts that run on a SharePoint site page.

· Use SharePoint server-side object model event receivers. Instead, Apps can handle remote events and App events (see section “Handling events in Apps for SharePoint” for more information).

· Deploy Custom Field Types. However, it is possible to deploy new fields based on existing field types.

· Deploy application pages.

· Call the SharePoint server-side object model.

· Access SharePoint components located on another SharePoint site.

· Deploy master pages, custom site definitions and themes.

· Deploy custom action groups and custom action hiding.

· Deploy custom user controls (.ascx files).

· Deploy delegate controls.

· Communicate with other Apps (but can share access to a list located in a parent SharePoint site).

Best Practices I expect that the first question companies will ask themselves when deciding to build Apps (or not) is this: will we able to build this App using CSOM? If the answer is yes, building a feature as an App becomes a lot more attractive.

Handling events in Apps for SharePoint

Apps know how to communicate with the referring SharePoint site and site collection via the JavaScript client object model or the REST API, but you may be surprised to find out that Apps are also able to subscribe and respond to several SharePoint events. App developers can create remote events receivers and App event receivers (both via WCF) to handle events:

· Remote event receivers handle events that occur within the life cycle of a SharePoint artifact, such as a SharePoint list item, SharePoint list, or SharePoint site. They function in a way very similar to their SharePoint server object model event counter parts, except for the fact that they work remotely. Events that occur before the actual action occurs can even prevent certain events from happening, such as the deletion of important list items. One way events always happen after the action has occurred, and can only be used to observe what has happened to the SharePoint environment.

· App event receivers deal with events within the App life cycle itself, most notably App installing, upgrading and App uninstalling events. Such event receivers are very useful for cleaning up App changes that affect the SharePoint environment, sending notifications, and logging purposes.

As part of the deployment deliverables, you should demand that App developers provide sufficient error handling within App event receivers. Failing to do so may lead to Apps that can’t be installed, upgraded, or uninstalled due to unhandled exceptions within App event receivers. The next code fragment shows a part of an installation file of a SharePoint App that registers an event receiver that responds when new items are added to a SharePoint announcements list:

<?xml version=”1.0″ encoding=”utf-8″?>

<Elements xmlns=”http://schemas.microsoft.com/sharepoint/”&gt;

<Receivers ListTemplateId=”104″>

<Receiver>

<Name>RemoteEventReceiver1ItemAdding</Name>

<Type>ItemAdding</Type>

<SequenceNumber>10000</SequenceNumber>

<Url>~remoteAppUrl/RemoteEventReceiver.svc</Url>

</Receiver>

</Receivers>

</Elements>

Understanding SharePoint Customization Models

Now that you have learned more about the Apps customization model that makes it possible that SharePoint is extended with customizations, it’s a good idea to contrast that model against the other available development models for customizing SharePoint. Let’s start out by recapping what models are there:

· Farm solutions

· Sandboxed solutions

· SharePoint Apps

Farm Solutions

Farm solutions (.wsp files, a specific flavor of .cab files) are deployed to the Global Assembly Cache or web application Bin folder of every SharePoint Web Front-End (WFE) in the farm. These solutions typically have a wide range of possibilities as far as executing server-side code goes, and can be very powerful. Because of that, they also have the potential to destabilize the SharePoint farm in a direct way.

Security Alert In a lot of the resources I’ve seen about SharePoint 2013 Apps, the terms Farm solution and Full Trust solution are used interchangeably (even in MSDN documentation), implying that the code in Farm Solutions always runs under full trust. Don’t make this mistake. The capabilities of farm solutions can be limited to a very fine-grained level, but do require IT Pros to have a working knowledge of Code Access Security (CAS). In real life, there are plenty of companies that have taken the shortcut by letting farm solutions run under full trust. This goes against best practices and is not a trait of farm solutions per se.
However, be aware of a breaking change in SharePoint 2013: the default CAS policy that is used in this version is Full Trust (instead of the safe wss_minimal policy that allowed solutions to perform a very limited set of operations, like it used to be). In the web.config file it’s defined like this:

<trust level=”Full” originUrl=”” legacyCasModel=”true” />

This means that by default, a SharePoint 2013 farm solution will run under full trust, and allows a solution to do pretty much everything it wants. In effect, by default this also makes every farm solution a full trust solution. At the time of writing, it wasn’t completely clear what the reasoning behind this break in security best practices is and if it’s possible to run SharePoint 2013 under a different trust model without breaking. One thing that is quite clear at this point is that lots of companies found it hard to deal with security policies and opted for the easy way out by running their SharePoint farms under Full Trust anyway.

Sandboxed Solutions

Sandboxed solutions (.wsp files, a specific flavor of .cab files) run in isolation in a separate process called the User Code Service, running under a very strict CAS policy that does allow you to make service calls via full trust proxy services, as well as client-side web service calls (such as WCF services). What’s more, Sandboxed solutions run under a resource throttling mechanism that allows IT Pros to assign points of server resources that a solution is allowed to spend. This system allows for the automatic shutdown of solutions that spend too many server resources. All in all, although Sandboxed solutions run within your SharePoint farm, they are designed for safety, are intentionally limited in their capabilities, and have a minimal impact on their environment. Because of that, in SharePoint 2010, it was a recommended best practice to build Sandboxed solutions whenever you could. However, in the real world, most people found Sandboxed solutions to limited to be very useful. Therefore, Sandboxed solutions haven’t become as popular as was anticipated.

Important Although Sandboxed solutions are still supported; they are deprecated in SharePoint 2013. This means this type of solution probably isn’t supported in SharePoint vNext anymore, and best practices dictate that it’s better to avoid building new sandboxed solutions in SharePoint 2013. The development community won’t mind this decision as much.

App Solutions

We have talked about Apps, but let’s recap for a moment. Apps can run outside of your SharePoint farm, outside of any SharePoint technology, even outside of Microsoft technology, and if you want, in the cloud (Azure). Apps can do this in a safe way by leveraging the OAuth and S2S security protocols and still provide the functionality by leveraging the extended and improved client object model and/or REST (OData) API.

Note App solutions are deployed in the form of .spapp files. Each App package file itself contains a .wsp file (a cab file of the SharePoint brand) full of App resources.

What Apps typically can’t do is execute server-side code. The Apps model is by far the model that has the littlest impact on your SharePoint farm as it can’t affect it directly. However, as of yet, it is more difficult to integrate it with your SharePoint farm and also requires an understanding of the architectural ramifications of the App model.

Best Practices It’s an interesting question what to do when you’re still doing SharePoint 2010 development, and expect that one day in the undefined future you’ll be migrating to SharePoint 2013. Since SharePoint 2010 Best Practices dictate to buld Sandboxed solutions whenever you can, there’s a clear conflict because SharePoint 2013 Best Practices advise to build Apps wherever possible. What’s more, SharePoint 2013 deprecates Sandboxed solutions. One way to approach this problem is to go ahead and build Sandboxed solutions in a way that makes them easy to port to the App model. This would mean that they should be designed in such a way, that they leverage either the client object model or SharePoint REST interface a lot, and refrain from using the server-side object model. I would advise differently. You have to realize that both the client object model and the SharePoint REST interface have become a lot more powerful in SharePoint 2013. Therefore, you can create lots of headaches by trying to create the same solutions for SharePoint 2010 and will most likely end up with higher initial development costs. Instead, build Sandboxed solutions like you’re used to do and remember that they will continue to run effortlessly in SharePoint 2013 environments. If your solution survives until SharePoint vNext, invest in an upgrade at that point in time.

Comparing SharePoint Customization Models

You have learned about the various models available for customizing SharePoint, but now the question remains: when should you prefer which model? Let’s start with this: in SharePoint 2013 it’s a best practice to create SharePoint Apps whenever possible, in lieu of the other development models: Farm solutions and Sandbox solutions, since Apps can’t hurt your SharePoint farm directly. The things you could do with Sandboxed solutions can also be achieved via Apps, in a better way, so it should always be avoidable to build Sandbox solutions. The use of Farm solutions however, can’t be avoided completely. The following table provides detailed guidance on how to make the decision of which model to choose.

table 1 Comparison of SharePoint Customization Models

When to use/Customization model	Sandboxed solutions	SharePoint Apps	Farm solutions
Is it a best practice?	Sandboxed solutions are still supported but deprecated. Therefore, it’s unadvisable to build new sandboxed solutions.	For SharePoint 2013, creating SharePoint Apps is the best practice. You should choose Apps as a way of customizing your SharePoint environment if at all possible.	Create farm solutions when you need to do something that can’t be done using SharePoint Apps. See section “What Apps can’t do” for more information.
Does it have the ability to run server-side code?	Runs under a strict CAS policy and is limited in what it can do.	When Apps are hosted in an isolated SharePoint site, no server-side code whatsoever is allowed. The use of the SharePoint server-side object model code is never allowed within Apps.	Can run full trust code or under a fine grained custom CAS policy. Provides all the flexibility and power you could wish for.
How much impact does it have on server resources?	Run under an advanced resource management system that allows resource point allocation and automatic shutdown for troublesome solutions. In this regard, sandboxed solutions provide the most advanced capabilities, although they still run inside your SharePoint farm.	Apps run isolated from a SharePoint farm, but can have an indirect impact by leveraging the client object model.	Can impact SharePoint server-farm stability directly.
Is it able to runs cross-domain?	No, and there’s no need to since code runs within the SharePoint farm.	Yes, this provides a very interesting way to distribute server loads.	No, and there’s no need to since code runs within the SharePoint farm.
How about the efficiency and performance of the solution?	Runs on the server farm, but in a dedicated isolated process. The sandbox architecture provides overhead.	Apps hosted on separate app servers (even cross-domain) or in the cloud may cause considerable communication overhead. Apps can leverage the CSOM which has built-in task batching capabilities, which relieves this problem to a certain degree.	Very efficient.
How safe is it?	Very safe.	Apps rely on OAuth 2.0. OAuth is a protocol designed for safety, but App architecture offers a bigger attack surface compared to the other models. The Apps Updating mechanism has received criticism, since full control Apps that get updated are not subject to an extensive approval process (as long as the App manifest doesn’t change). In theory, this allows Full Control Apps to start misbehaving after receiving an update. In reality, App vendors can be traced easily via the SharePoint Store, which makes them easily reachable in case of losses caused by malicious Apps.	Can be very safe, but this requires administrators to put thought and effort in the CAS policies they allow to run.
Manageability	Easy to manage within the SharePoint farm. The technical infrastructure of sandboxed solutions is more complicated compared to farm solutions.	Can even be managed on a dedicated environment without SharePoint. Dedicated app admins can take care of this. The technical infrastructure of SharePoint Apps is without a doubt the most difficult to understand of all three customization models.	Easy to manage within the SharePoint farm. The technical infrastructure of farm solutions is the easiest to understand.
Cloud Support	Yes, sandboxed solutions are supported in Office 365.	Yes, Apps are supported in Office 365. What’s more, they have inherent support for the cloud (Azure).	No, on-premises only.
Maturity	There has been only one version of sandboxed solutions. After that, this technology has been deprecated. Therefore, the maturity and success of this technology is very limited.	The Apps model is completely new and therefore needs to mature.	Farm solutions have been around for a long and provide the most mature of all customization models. However, farm solutions have been known, because of their power and the fact that they run inside your SharePoint farm, to destabilize SharePoint farm deployments.
Audience	Available within Office 365 and on-premises SharePoint farm.	An immense audience can be reached easily by adding Apps to the SharePoint Store. Apps can be used in Office 365 as well as on-premises SharePoint farms.	Only available within your on-premises SharePoint farm.

Best Practices As a general rule of thumb, solutions targeted towards administrators don’t lend themselves well to be implemented as Apps. It seems fair to state that Apps are end-user focused almost exclusively.

The overview provided by this table is subject to change, since further insights can impact the comparison. Track the following TechNet Wiki page for a recent comparison of SharePoint customization models: http://social.technet.microsoft.com/wiki/contents/articles/13373.sharepoint-2013-what-to-do-farm-solution-vs-sandbox-vs-app.aspx. The following MSDN article compares Apps with SharePoint solutions: http://msdn.microsoft.com/en-us/library/office/apps/jj163114(v=office.15).

Understanding Security Protocols: OAuth and S2S

As a way of obtaining an App identity that can be used for authentication and authorization purposes, SharePoint Apps are able to leverage two different security protocols: OAuth and S2S. OAuth is the only security protocol supported in Office 365, which means that SharePoint Online will only be able to use Apps leveraging OAuth. By default, on-premises installations don’t contain an OAuth provider which makes S2S the de facto standard for on-premises App deployments.

High-Trust Apps

High-Trust Apps are hosted on on-premises Application servers, as opposed to the Office 365 model where Apps use the ACS to be able to support OAuth and obtain their App identities that way. ACS acts as an authorization service that needs to be trusted by both content server (SharePoint) and client application (SharePoint App). High-Trust Apps are a good solution for on-premises scenarios, because they make the use of ACS obsolete. Instead, High-Trust Apps leverage the S2S protocol to obtain App identities. High-Trust Apps are called this way because they are trusted to assert any user identity that they want by creating the user part of the access token. The term High-Trust App doesn’t mean that such Apps have Full Trust. App permissions have to be requested and granted separately, like Apps leveraging OAuth. In fact, S2S is also called application to application OAuth, but is not an official part of the OAuth specification, as you will learn later.

Best Practices Theoretically, it is possible for on-premise environments to use ACS. In order to do so, you will have to configure this explicitly, although you have to realize you won’t be able to use ACS directly. Instead, you need to acquire an Office 365 tenancy to manage security principal accounts, set up a trust from the on-premises SharePoint farm to the Office 365 tenancy, and go through the tenancy to communicate with ACS. All in all, this route means more work, additional costs, and it is unlikely that organizations will have it set up for use. More than that, doing so doesn’t provide tangible benefits above using the High-Trust App model which makes it hard to argue with the local Enterprise Architect if you do want to enable ACS. In Office 365 environments, OAuth and ACS are already configured reducing the effort of using the ACS/OAuth model to the minimum, which makes a lot more attractive option. All in all, I don’t expect that ACS will be used in on-premises environments that much.

The SharePoint S2S STS, running within the SharePoint farm, provides the tokens necessary for server-to-server authentication. This enables SharePoint 2013 to access application services such as SharePoint Apps hosted on Application servers using temporary access tokens, if a 2-way trust relationship (also known as the S2S Trust or trusted connection) between SharePoint 2013 and the application service exists.

Note At the moment, the other Microsoft application services (also known as App principles) that support S2S are Exchange Server 2013, Multi-tenant workflows running in Azure Workflow Server, and Lync Server 2013. This means it’s possible to configure S2S authentication between a SharePoint 2013 farm and other SharePoint 2013 farms, and/or these other server products. Refer to http://technet.microsoft.com/en-us/library/jj219532(v=office.15).aspx for an explanation how to configure this.

S2S Security Tokens are like OAuth tokens (to be discussed later), but are not a part of the OAuth specification. Microsoft has submitted S2S Security Tokens to the OAuth specification, so they may end up becoming a part of OAuth eventually. Each S2S Security Token must contain the following information:

· It must contain the App identity

· It can optionally contain the identity of the end user

· It must be encrypted with an SSL certificate

S2S Trusts are configured using one or more SSL certificates. The App running on a dedicated application server needs to have access to both the public and the private key pair of the SSL certificate.

Note Private key files end with the extension .pvk, or .pfx when it’s encrypted using a password. For security reasons, Apps should work with .pfx files. Password encrypted .pfx files can be created using the pvk2pfx.exe tool located by default in c:\Program Files (x86)\Windows Kits\8.0\bin\x64. SSL certificates are X509 certificates that end with .cer. These .cer files contain the public key of the certificate.

The App authenticates the end user (using Windows authentication, Forms authentication, and such), then uses the private key to sign a security token, including information about the end user identity, and sends it to SharePoint. SharePoint then uses the public key of the SSL certificate to validate that the security token was indeed signed by a party having access to the private key, which it trusts.

In addition to sending a valid S2S Security Token, Apps are also responsible for exposing a web service end point for metadata discovery which must be available using anonymous access. This end point returns a JavaScript Object Notation (JSON) security token with service metadata (type of certificate, public key of SSL certificate, and App ID) and allows SharePoint 2013 to discover the App ID and public key value.

Once the App metadata end point is in place, the S2S STS can be created on the SharePoint farm using the New-SPTrustedSecurityTokenService PowerShell cmdlet by passing it a friendly name and the URL of the App metadata end point. By doing so, the S2S STS retrieves and stores the App ID and SSL public key. The S2S STS needs the latter to be able to decrypt the security tokens sent by the App that were encrypted using the SSL private key.

Now that the S2S STS is up and running, you usually need to register one App principal. If you’re working with multiple tenancies (refer to section “SharePoint App Architecture” if you’re not sure what a tenancy is), you’ll need to register multiple App principles: one for each tenancy. This can be done via the PowerShell Register-SPAppPrincipal cmdlet. Once you’ve done that, you’ll need to assign permissions (such as Full Control) to the App principal using the Set-SPAppPrincipalPermission PowerShell cmdlet.

The resulting communication flow that happens once the end user starts making requests to a SharePoint Apps looks like this:

1. The End User makes a request to a SharePoint site page via the browser.

2. Because the browser finds the site page contains a reference to a SharePoint App hosted on a dedicated application server, now the browser makes a request to this App as well.

3. The App interacts with a SharePoint Web Front-End (WFE) by sending requests via CSOM or the REST API, and includes a special S2S security token.

4. The WFE sends a response message.

5. The App renders the UI that is displayed in the end user’s browser.

This communication flow is shown in Figure 3.

Figure 3 High-Trust App communication using the S2S protocol.

In the remaining part of this section, you will see how to set up an S2S trust to a High-Trust App. We won’t discuss how to create a High-Trust App, as this is a developer topic. However, if you want to create one for testing purposes, the following MSDN article http://msdn.microsoft.com/en-us/library/fp179901(v=office.15).aspx explains how to create one. For the purposes of this section, we have already created this App and for clarity purposes use the same name and client ID as the MSDN article. The App name is HighTrustSampleApp, the client ID is 6569a7e8-3670-4669-91ae-ec6819ab461. You will see them again in the procedures of the rest of this section.

If you want to set up an S2S Trust to a High-Trust App, you’ll need to follow the next steps:

1. In the registry of the SharePoint server, make a change to indicate that you’re supporting High-Trust Apps.

2. Check that required SharePoint services are running.

3. Check that at least one profile exists (or create the first one).

4. Create an S2S STS on the SharePoint server via PowerShell.

5. Turn off the HTTPS requirement for the S2S protocol (only a good idea for testing purposes).

6. Open the High-Trust App in your SharePoint site.

First, you need to configure your server so that it supports High-Trust Apps. You can do this by adding a new registry key called AppDeploymentCheckAppPrincipalAccessToken. The next procedure explains how to do this:

1. Press Windows+R to Open the Run dialog window.

2. Type regedit. This opens the Registry Editor.

3. Go to [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\15.0\WSS].

4. Right-click the WSS node and choose New > DWORD (32 bit) Value.

5. Choose the following name: AppDeploymentCheckAppPrincipalAccessToken.

6. Accept the default value.

7. Close the Registry Editor.

8. Restart your computer.

This registry setting disables the App Principal Access Token Check, a check that is required for Cloud-Hosted Apps, but not necessary for High-Trust Apps.

Next, we will check if the SharePoint services required for S2S Apps are running: the User Profile Service and App Management Service. In addition, at least one profile needs to be present. If this isn’t the case, you will need to add a new profile. S2S depends on the mapping to a user account via the User Profile application, in case you were wondering about the User Profile related prerequisites. SharePoint uses it to create a user context in the form of a user token that contains the following end user information taken from the User Profile Application (UPA): the UPN, SMTP, and SIP attributes.

The next procedure checks the state of the SharePoint services as well as the number of profiles present in the User Profile Service:

1. Start SharePoint 2013 Central Administration.

2. On the Home – Central Administration page, click Application Management > Manage service applications. This opens the Manage Service Applications page.

3. Locate the name App Management Service and check that its status is Started.

4. Locate the name User Profile Service Application and check that its status is Started.

5. Click the User Profile Service Application link (of type User Profile Service Application). This opens the Manage Profile Service: User Profile Service Application page.

6. Click People > Manage User Profiles. This opens the Manage User Profiles page.

7. Check the Total number of profiles. Usually, this already contains at least 1 profile. If that’s not the case, create one by clicking the New Profile link.

The S2S STS is responsible for handling App security tokens. To set it up, you need to have access to the public key of the SSL certificate (.cer file), which will be provided by the App vendor/developer.

Next, you will learn how to set one up for our test High Trust App. Add the following code to a PowerShell cmdlet file and call that file ConfigS2S.ps1. Then, start the SharePoint 2013 Management Shell and execute the ConfigS2S.ps1 PowerShell cmdlet. Take note of the following things:

· We’re using a .cer file called HighTrustSampleCert.cer, located in the c:\Projects folder.

· The app ID is the App client ID mentioned earlier in this section.

· Replace the URL of http://%5Bsharepoint site collection url] with the URL of the SharePoint site collection where you want to add the App.

· The cmdlet needs to be executed on the SharePoint server.

Add this code to the ConfigS2S.ps1 file:

$publicCertPath = “C:\Projects\HighTrustSampleCert.cer”

$appId = “6569a7e8-3670-4669-91ae-ec6819ab461”

$spurl =”http://%5Bsharepoint site collection url]”

$spweb = Get-SPWeb $spurl

$realm = Get-SPAuthenticationRealm -ServiceContext $spweb.Site

$certificate = Get-PfxCertificate $publicCertPath

$fullAppIdentifier = “$appId@$realm”

New-SPTrustedSecurityTokenIssuer -Name “High Trust Sample App” -Certificate $certificate -RegisteredIssuerName $fullAppIdentifier

$appPrincipal = Register-SPAppPrincipal -NameIdentifier $fullAppIdentifier -Site $spweb -DisplayName “High Trust Sample App”

For testing purposes, you can optionally turn off the HTTPS requirement for the S2S protocol. Add the following code to a file called ConfigNoHttps.ps1 and execute it in the SharePoint 2013 Management Shell:

$serviceConfig = Get-SPSecurityTokenServiceConfig

$serviceConfig.AllowOAuthOverHttp = $true

$serviceConfig.Update()

In principle, this completes the section. At this point, you have successfully set up an S2S High Trust. To be complete, we will show what happens if you have created the High Trust App as described in the MSDN article http://msdn.microsoft.com/en-us/library/fp179901(v=office.15).aspx and add it to your SharePoint site.

First, the App will ask for the permissions it needs. In this case, this is limited to Read permissions, as is shown in Figure 4.

Figure 4 SharePoint Apps have to be trusted explicitly before they are added to a site.

After installing the App, it’s shown in the SharePoint Site Contents, shown in Figure 5.

Figure 5 All installed SharePoint Apps can be found in the Site Contents list.

After this, you can click on the App to execute it. If the App uses a Self-Signed test certificate, the browser will issue a warning that the security certificate is not issued by a trusted certificate authority. In this case, just click Continue to this website (not recommended). The App itself does very little: it just displays the title of the SharePoint site that hosts the App.

OAuth

The SharePoint 2013 App model relies heavily upon the OAuth protocol for authentication and authorization. Every Office 365 App uses it and, as of yet, OAuth is only supported in Office 365. OAuth integration for SharePoint as well as Office Apps is made possible via the Azure Control Service, which is configured automatically. The required trusts from ACS to SharePoint, and ACS to SharePoint Apps are configured automatically as well and is ready for use. All Apps leveraging OAuth obtain their App identity from ACS. When Apps are deployed to the SharePoint Store, they have to be registered with ACS as well.

Note Apps used in on-premises scenarios leverage the S2S protocol instead of OAuth. OAuth is designed for use with HTTP and HTTPS only.

OAuth is a protocol that allows end users to grant third-party applications access to the end user resources without sharing their passwords. It also provides a more fine-grained access method compared to a traditional security mechanism such as Windows authentication, as OAuth also makes it easy to grant limited access (such as: limited in the scope of accessible resources, or duration of access) or revoke access.

Note Because OAuth doesn’t require the sending of password information, it’s an attractive candidate in scenarios where HTTP is used and SSL encryption is not an option. Originally, OAuth was designed with insecure communication methods in mind.

Let’s contrast OAuth to the traditional client/server security model in which the client uses its credentials (typically, a user name/password combination) to access its resources on the server. Such resources are also known as protected resources, because they require that authentication takes place in order to access them. In a client/server scenario, the client and server share a secret (normally a password) that belongs to the client. Each request that uses these credentials is authenticated, which is depicted in Figure 6.

Note Clients in client/server scenarios are usually end users, but clients can be any entity controlling server resources.

Figure 6 A classic client-server authentication request.

As far as the server is concerned, the requester is the client; it knows no other roles. As a result, in SSO scenarios, every application acting on behalf of the client needs to be aware of the client’s credentials, and every application pretends to be the resource owner. This scenario is depicted in Figure 7.

Figure 7 A client-server impersonation scenario.

The traditional client/server model doesn’t work that well in typical web scenarios, where it’s the web front-end (WFE) accessing databases using its own identity instead of the end user context (it just wouldn’t scale well). This makes the web model one step more complicated, especially in situations where the WFE does need to make calls to back-end systems on behalf of the user. In this scenario, the WFE impersonates the end user and makes requests in the context of that end user. Such scenarios may be supported by some type of SSO service, such as the Secure Store Service (SSS) that you might know from the SharePoint world. This scenario is depicted in Figure 8.

Figure 8 Single Sign-On in Web scenarios.

In traditional client/server scenarios, when it comes to providing third-party server applications access to resources owned by the end user, several problems and limitations exist:

· Client applications are required to store the end user credentials in a safe way for future use, which requires the type of some type of Single Sign-On solution. At best, this complicates the architecture of the solution and decreases its manageability. At worst, the SSO implementation is unsafe.

· The scope of access client applications get is too coarse grained and too broad: they get the same access as the end user himself, which is almost never really necessary.

· Server applications are required to support password authentication, which, compared to other solutions such as the use of certificates, is a security weakness.

· Once end users hand out their credentials, they can’t revoke access given to client applications without changing their password. Since most end users tend to reuse a limited set of passwords over a large set of applications, this may not be a very attractive course of action.

Best Practices There are secure password management tools (or digital wallets) available that can help manage a multitude of passwords.

· If any client application used by the end user is compromised, the end user password and all the resources protected by it are compromised.

In OAuth, a new abstraction layer in the form of a third role is introduced: the resource owner. In OAuth, there’s a client application who acts on behalf of the end user who is the actual resource owner and knows the credentials to access those resources. The term client application doesn’t imply that it runs on the desktop of the end user, it can run anywhere (a mobile device, a server, in the cloud, and so on) and still be called a client.

Important In OAuth terminology, the term resource owner is preferred above the term end user. This is because the resource owner doesn’t have to be a person, but can be an application as well. In this blog post, the term end user is preferred. This is a SharePoint blog after all, and ultimately, when we’re talking about OAuth, we have scenarios in mind where end users allow SharePoint Apps to access SharePoint resources.

The client application sends requests to the server (or resource server) which hosts the resources that are controlled by the end user (or resource owner) and is capable of accepting and responding to protected resource requests using access tokens . The three roles in OAuth, consisting of client, server, and resource owner, are also fondly known as the OAuth Love Triangle.

In addition, the OAuth infrastructure requires the presence of an authorization server, a trusted server authenticating client applications and issuing access tokens to client applications authorizing them to access end user resources. The application server may act as the authorization server, but the authorization server existing as a separate entity is equally possible. A single authorization server may serve multiple application servers. The OAuth specification doesn’t address the interaction between server and authorization server, so that implementation is completely left to the discretion of the vendor implementing OAuth.

In the OAuth model, the first thing the client application needs to do is obtain sufficient permissions from the end user to be able to access the end user’s resources later. Such permissions are expressed in the form of a security token (or access token) and a matching shared secret. Security tokens contain a scope, lifetime, and optionally other attributes and are issued to client applications by an authorization server with the approval of the end user. Security tokens make it unnecessary for the end user to actually share his credentials with a client application, which is the biggest advantage offered by OAuth and makes it an ideal candidate for implementing Single Sign-On (SSO) solutions. OAuth also differs from other protocols and services in the sense that it’s good at other services not just web sites; it also has built-in support for desktop applications, mobile devices, and set-top boxes. Having said that, at the moment OAuth is only defined for HTTP(S) resources.

Note Another concept mentioned frequently when talking about OAuth is the number of legs used to describe an OAuth request. This typically refers to the number of parties involved in the request. In a simple request the end user makes a request to the server. This is a 2-Legged request. If it’s a little more complicated, let’s say that the client application makes a request to the server on behalf of the end user, three parties are involved. This is a 3-Legged request. This goes up to n-Legged for scenarios where access is shared with yet more client applications (also known as re-delegation) and is limited by your imagination only.

In OAuth, there are three kinds of credentials:

· Client credentials, which are used to authenticate the client application. In potential, servers can do interesting things with this information, such as providing throttling-free access for important client applications. Most of the time, these credentials will only be used for informational purposes and logging.

· Token credentials, which are used instead of sharing the actual end user credentials. Servers will typically treat these token credentials differently from a scenario where an end user uses his credentials to log in to the server and issue a special class of credentials to the client application representing the permission grant given by the end user. Key here is the fact that the client application doesn’t have to know about the end user credentials. Token credentials are usually encrypted using some type of certificate and are limited in scope and duration.

· Temporary credentials, which are used to identify the authorization request itself. This can be used to differentiate between various clients such as web-based, mobile, desktop and such, and thus offer more flexibility.

OAuth operates on two different channels. The communication between end user (resource owner) and client application (client) is called the front-channel. The communication between client application and server application is called the back-channel. OAuth access tokens are only used in the back-channel, so that the end user and his browser will never have to know about it. OAuth access tokens are usually larger than front-channel temporary credentials that the end user sees when the client application asks for authorization. To protected OAuth requests from replay attacks, OAuth uses a nonce and timestamp. Nonce stands for number used once and is a unique and random string that uniquely identifies each OAuth request. In addition to nonces, timestamps are added to each OAuth request so that server applications don’t have to store nonce values forever. Requests that were sent after the allowed time limit are considered to be replay attacks.

Security Alert It’s up to the server application to keep track of nonces and implement an anti-replay attack mechanism. The OAuth specification makes it easy to devise a mechanism that prevents replay attacks, but ultimately it’s up to the server application.

Important At this point, it’s important to understand that OAuth allows client applications to access end user resources using access tokens. It is not a sign-in protocol that issues sign-in tokens that can be used by end users to log in to SharePoint. That is a huge difference to SharePoint claims authentication that focuses on providing a powerful and flexible way to allow end users to sign-in to SharePoint as well as other applications.

OAuth Protocol Communication Flow

The communication flow of the OAuth protocol generically looks like this:

1. The client application registers itself once with the authorization server and doesn’t have to do this each time anew when it wants to use OAuth. This registration can take place in many forms, such as involving end-user interaction with an HTML registration form, or the opposite, and administrator executing a PowerShell cmdlet on the application server to establish a trust relationship with the client application (this is the variant that is used in SharePoint 2013).

Note App registration information can be retrieved via the following URL: http://%5Bserver name]/_layouts/appinv.aspx. This page allows you to do a lookup based on the App ID used to register the App. It returns App title, App domain, the redirect URI, but not the App Secret.

2. The client application requests authorization from the end user to access end user resources. This request can be made directly, but preferably indirectly via the authorization server.

3. If the end user accepts, the client application receives an authorization grant that represents the permission set granted by the end user.

4. Using this authorization grant, the client application requests an access token from the authorization server.

5. The client application requests end user resources from the server application, and includes the access token in the Authorization HTTP header of each request. The access token is used by the server application to authenticate this request and, if all is well, responds by presenting the protected resource.

When translated to the SharePoint 2013 world, the OAuth model looks like this: end users are the resource owners. They have to grant SharePoint Apps (the client application) the permissions to access end user resources hosted on SharePoint 2013 (the server application). SharePoint Apps use ACS as the authorization server to obtain their App identity from ACS in the form of the access/security token which is also known as the OAuth token, which gets included in any request made by the SharePoint App. This makes it possible for the SharePoint App to interact with a particular SharePoint site using the permissions that were granted by the end user for a specified duration. Access tokens will expire (based on the nonce and timestamp information discussed earlier). When that happens, the SharePoint App will send a refresh token to the authorization server to obtain an updated OAuth access token.

Security Alert The App is itself responsible for storing OAuth tokens, the SharePoint infrastructure doesn’t provide facilities for this. Potentially, this can be a risk. The App vendor has to deal with this adequately. As an administrator: always ask developers and third parties how they handle token storage.

SharePoint App Communication Flow

The SharePoint App communication flow in SharePoint 2013 looks like this:

1. The end user (the resource owner) uses a browser on a device (such as a desktop computer, smart phone, or tablet) to go to a page in a SharePoint site (part of the resource server). If the end user isn’t logged on automatically and isn’t logged on yet, the end user will be prompted to log on. As a result, SharePoint will create a claims based identity in the form of a SAML token.

Important The OAuth protocol flow requires the use of claims authentication.

2. The SharePoint page contains a SharePoint App (the client). As a result, SharePoint asks ACS (the authorization server, or, in SharePoint terminology, the Security Token Service (STS)) to create a context token that contains information about current end user, current App, and current SharePoint context (such as the URL of the SharePoint site). The context token is signed using the App Secret that only the ACS and the SharePoint App know about. The SharePoint App already knows about this client secret, because it received it from ACS during the App registration process in the cloud. The SharePoint App will use the context token later to request an Access token from ACS.

3. ACS returns the context token to SharePoint.

4. SharePoint renders the page including the App. When it gets to the rendering of the SharePoint App, either as a separate full page or in an IFrame, it will do so by creating a so-called App Launcher which runs in the end user browser and uses JavaScript to provide its functionality. SharePoint will pass the context token to the App Launcher which posts this information to the App URL via the browser via a HTTP POST.

5. The application server hosting the SharePoint App validates the context token and, if the App needs to communicate with SharePoint, extracts a refresh token (which remains valid for almost a year) from the context token which gets then signed using the App Secret. After that signing it, the application server uses the refresh token to get an OAuth Access token (which remains valid for a couple of hours to prevent replay attacks) specific for the current end user from ACS, which can be used by the SharePoint App to request end user resources hosted in SharePoint. Based on the Access token, SharePoint is able to validate that the Access token indeed originated from ACS.

6. It is up to the application server hosting the SharePoint App to decide what to do when it retrieves an Access token from ACS. Typically, it should cache it in order to prevent it from having to ask ACS for it time and time again.

7. The SharePoint App uses the Access token for any SharePoint resource requests it makes, using CSOM or REST.

8. SharePoint returns site content to the SharePoint App, which is rendered to HTML and displayed in the browser.

Important SharePoint Apps written in .NET can leverage the TokenHelper class that is available for making the responsibilities for SharePoint Apps (such as calling ACS, or obtaining token information) a lot easier to do, although the TokenHelper class is not supported officially. For non .NET Apps, such tasks have to be coded by hand and are therefore a lot more error prone. As an administrator, this is something to look out for. Non .NET Apps have to be screened more carefully in order to check if they’re able to handle to OAuth communication flow correctly. The source code for this TokenHelper is available, and should be used as either a starting point or a reference for manual implementations. For .NET Apps, you should also check with the developers or vendor whether they’re using the TokenHelper class or some custom application.

The OAuth communication flow in SharePoint 2013 is shown in Figure 9.

Figure 9 A detailed overview of the OAuth Protocol flow in SharePoint 2013.

More Info The following MSDN article contains more information about OAuth and remote Apps for SharePoint 2013: http://msdn.microsoft.com/en-us/library/fp179932(v=office.15).aspx.

Managing Apps

One of the biggest advantages of the new SharePoint App model is that it makes for a much cleaner and simpler installing, updating and uninstalling process. This doesn’t mean to say that you can just sit by idly while end users are interacting with Apps all over your SharePoint farm, so in this section you will learn how to manage SharePoint Apps.

Configuring the App environment

Before end users are allowed to install online SharePoint Apps in your environment, you must perform some configuration involving domain names, service applications, and App URLs. If you install a SharePoint App from the SharePoint Store, each App get its own unique URL, separate from the URLs of the SharePoint sites and other Apps. This is made possible by the use of Host headers. The format of App URLs looks like this: http://[App prefix][App hash].[App domain]/[relative site URL]/[App name]. The next example is a valid App URL: http://myappprefix-f7e14f7b0643e5.contosoapps.com/TheAppName/Pages/Home.aspx. The feature is implemented this way, because unique URLs prevent cross-domain JavaScript attacks. This makes sure SharePoint Apps won’t steal information from each other.

Warning If you get the following error message: “Sorry, apps are turned off. If you know who runs the server, tell them to turn on the App Management Shared Service.”, you probably didn’t follow this procedure or have not yet created a Corporate Catalog.

In the next procedure, you will learn how to create a subdomain that’s going to be used for hosting SharePoint Apps.

Create a Subdomain

1. Select Start > Administrative Tools > DNS. This opens DNS Manager.

2. Select [server name] > Forward Lookup Zones > [domain name].

3. Right-click the domain name node, and choose New Alias (CNAME)…. This opens the New Resource Record dialog window.

4. In the Alias name text box, enter *.app. This will be the sub domain name for all the SharePoint Apps that get installed in your environment.

5. Click Browse…. This opens the Browse dialog window.

6. Select [server name] > Forward Lookup Zones > [domain name] > (same as parent folder) node, and click OK twice. The DNS Manager Details pane should display the *.app entry.

Now that you have configured the required DNS settings, you need to configure SharePoint as well. First, add the following code to a file called Config.ps1 (the code can be obtained from http://msdn.microsoft.com/en-us/library/fp179923(v=office.15)

$account = Get-SPManagedAccount “[administrator account]”

$appPoolSubSvc = New-SPServiceApplicationPool -Name SettingsServiceAppPool -Account $account

$appPoolAppSvc = New-SPServiceApplicationPool -Name AppServiceAppPool -Account $account

$appSubSvc = New-SPSubscriptionSettingsServiceApplication –ApplicationPool $appPoolSubSvc –Name SettingsServiceApp –DatabaseName SettingsServiceDB

$proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy –ServiceApplication $appSubSvc

$appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $appPoolAppSvc -Name AppServiceApp -DatabaseName AppServiceDB

$proxyAppSvc = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc

Open the SharePoint 2013 Management Shell and execute the Config.ps1 file. This creates two service applications called AppServiceApp (of the type App Management Service Application) and SettingsServiceApp (of the type Microsoft SharePoint Foundation Subscription Settings Service Application).

In the next procedure, you will verify that these service applications are ready for use and configure the App URLs so that Apps can be downloaded from the SharePoint Store.

1. Start SharePoint 2013 Central Administration.

2. Go to Application Management > Manage service applications to verify these service applications are present and started.

3. Select Apps. This opens the Apps page.

4. Click Configure App URLs. This opens the Configure App URLs page as shown in Figure 10.

Figure 10 Configuring App URLs is essential for running Apps as each App gets its own unique URL.

5. In the App Management section, click Configure App URLS. This opens the Configure App URLs page.

6. In the App Domain textbox, enter the URL of the APP domain: app.[domain name], e.g. app.contoso.com.

7. In the App prefix textbox, choose a prefix that will be prefixed to the subdomain of App URLs. Normally, a prefix such as app will do. In this case, myappprefix is used for educational purposes.

8. Click OK.

At this point, online Apps can be deployed to your SharePoint environment. If you’re getting an error stating the following: “Everything is fine, but we had a small problem getting your license. Please go back to the SharePoint Store to get this app again and you won’t be charged for it.”, it probably means you’re trying to add Apps using the SharePoint System Account. You can’t install Apps using this account by design, as importing App licenses under this account could lead to performance problems (http://technet.microsoft.com/en-us/library/fp161231(v=office.15).aspx). Use a regular end user instead.

It’s not as easy to sign in as a different user account as it used to be. In SharePoint 2013, the quick shortcut Sign in as Different User is missing, so one thing you can do is go to Start > click Shift + Internet Explorer and choose Run as Different User to run the browser in a different user context. If you’re working on a virtual machine and the SharePoint Store has trouble detecting your language settings, you’ll have to actually log out and log in again as that end user to test it out, or access the SharePoint site from your host computer using that user account. After that, go on to the next section and create a Corporate Catalog. Then, adding Apps from the SharePoint Store should work fine.

More Info See TechNet article “Configure an environment for apps for SharePoint 2013” at http://technet.microsoft.com/en-us/library/fp161236(v=office.15) for more details.

Managing the Corporate Catalog

App Catalogs are special SharePoint document libraries that contain SharePoint Apps. There are special site collections containing App Catalogs, called App Catalog sites. Each SharePoint web application is associated to a single App Catalog site, and each SharePoint farm can have multiple App Catalog sites. Every App Catalog site has two App Catalogs: one document library that is intended for SharePoint Apps, the other one is intended for Office Apps. App Catalog Sites are a great thing, because they allow you to set up a Corporate Catalog for Apps that you want to make available throughout your entire organization, or throughout certain parts in your organization. So, whereas the SharePoint Store provides a public marketplace, a Corporate Catalog provides an internal App catalog for Apps that are approved for use within the organization.

In the next procedure, you will learn how to create an App Catalog site (you do need to be a member of the Farm administrators group).

1. Start SharePoint 2013 Central Administration.

2. Click Apps > Manage App Catalog. This opens the Manage App Catalog page, seen in Figure 11.

Figure 11 App Catalogs give administrators control over the set of Apps they want to make available within the enterprise.

3. In the upper right corner, select the Web Application for which you want to create an App Catalog site. Make sure the web application is not yet associated to an App Catalog site, otherwise you won’t get the option to create a new one. If necessary, create a new site collection for this.

4. You’ll see a message stating that the selected web application does not have an app catalog site associated to it. Select Create a new app catalog site and click OK. This opens the Create App Catalog page.

5. Enter the required information. For this example, we are creating an App Catalog called TestAppCatalog. Note that you can select a predefined quota template.

6. Also note that in the End Users section you need to specify which users or groups are allowed to see Apps from the App Catalog. For testing purposes, add Everyone.

7. When you’re done, click OK.

Note Alternatively, you could have reused an existing App Catalog by entering its URL on the Manage App Catalog page.

Now, you have successfully created a new App Catalog site and associated it to a SharePoint web application. By default, the App Catalog site contains document libraries for App Requests, Apps for Office, and Apps for SharePoint, as shown in Figure 12. You can delete App Catalogs by deleting the App Catalog site collection, this is not different from deleting normal site collection. Unfortunately, it’s not possible to update the association between a web application and its App Catalog site: once associated, it stays associated.

Figure 12 Every App Catalog has document libraries for App requests, Office Apps, and SharePoint Apps.

Adding Apps to the Corporate Catalog Site is simple. You can do this by going to the Apps for SharePoint list (if it’s a SharePoint App) and click new item or drag the files to the list. Now, you can browse and upload the SharePoint App to the Corporate Catalog.

Note For testing purposes, it is allowed to upload any kind of file, so you’re free to create a .txt file to play around with the Apps for SharePoint user interface.

Edit App Settings by clicking the Edit button, and remove the App by selecting it, clicking the File ribbon and selecting Delete Document. After deletion, the App is moved to the site Recycle Bin.

Buying Apps from the SharePoint Store

For each web application scope, it’s possible to determine whether end users are allowed to purchase Apps from the SharePoint Store and whether they can make requests for Apps. Farm administrators and the App Catalog site owner review such App requests. In the next procedure, you will learn how to configure End User App Purchasing.

1. Start SharePoint 2013 Central Administration.

2. Click Apps. This opens the Apps page.

3. In section SharePoint and Office Store, click Configure Store Settings. This opens the SharePoint Store Settings page, shown in Figure 13.

Figure 13 The SharePoint Store settings define centrally how end users interact with Apps and allow administrators an easy way to keep track of current end user App requests.

4. In the App Purchases section, you need to decide whether end users are allowed to buy Apps in the SharePoint Store.

5. The App Requests section contains a link to the AppRequests document library of the App Catalog Site associated to the web application you have selected (you can change the selected web application in the upper right corner). This will help you to decide how much interest in SharePoint Apps currently exists.

6. In the Apps for Office from the Store section, you need to decide whether Office Apps are allowed to start.

7. Click OK.

Note The last setting doesn’t affect Office Apps located in App Catalog Sites, it only pertains to Office Apps purchased online.

Now you have successfully adjusted the SharePoint Store configuration settings. SharePoint Central Administration also provides direct access for administrators to the SharePoint Store, which makes the purchase of SharePoint Apps quite easy, as is demonstrated in the next procedure.

1. Open SharePoint 2013 Central Administration.

2. Click Apps. This opens the Apps page.

3. In the SharePoint and Office Store section, click Purchase Apps.

This opens the SharePoint Store where you can choose from a wide range of available SharePoint Apps.

Requesting Apps

The number of SharePoint Apps that are available in the public market place, the SharePoint Store, will continue to grow rapidly. It will be undoable for administrators to keep track of each and every new SharePoint App and evaluate it. Yet, it’s quite possible that there are Apps that are quite beneficial for end users. Therefore, SharePoint contains a mechanism that can be enabled that allows end users to request SharePoint Apps from the SharePoint Store. App requests (a mechanism which is a nice example of a governance feature) can be tracked by administrators, and after some internal validation process, can be made available in a controlled way.

In the next procedure, you’ll see how to check App requests via the SharePoint Store Settings (note that the User Account needs to be a member of the Farm Administrators group and member of the Site Owners or Designers group for the App Catalog site collection).

1. Open SharePoint 2013 Central Administration.

2. Click on the Apps link. This opens the App page.

3. In the SharePoint and Office Store section, click Configure Store Settings. This opens the SharePoint Store Settings page for the selected web application (change this in the upper right corner).

4. In the App Requests section, click Click here to view app requests. This opens the App requests page of the App Requests list of the App Catalog site.

Alternatively, you can manage requests directly by going to the App Catalog site collection and opening the App Requests list. On the App Requests page, each end user is required to fill in information why the App is needed, as shown in Figure 14.

Figure 14 End users can make requests for Apps that are useful but unavailable within their company.

Every App request goes through a workflow process that allows the administrator to communicate what happens with each request. The next procedure shows how to handle App requests.

 

1. Open the App Requests list, as shown in Figure 15.

Figure 15 End user App Requests can be tracked and managed via the App Requests list.

2. Click on the Edit button of a request (if there are no requests available just go ahead and create a new request yourself).

3. Fill in Approval details, as shown in Figure 16, and click Save.

Figure 16 Interaction with the end user is an important part of the App Request approval workflow.

As you can see, the App Request page now contains a section that allows you to change the status of the App (to New, Pending, Approved, Declined, Withdrawn, Closed as Approved, Closed as declined), explain your decision making, or find out more details about the App requested. Once the App status is approved, end users are allowed to purchase the App.

End users can make new App Requests and track the status of current App requests using the following procedure:

1. Go to Site Settings > Add an app. This opens the Your Apps page.

2. Click Your Requests. This opens the Your Requests page.

On this page, you can request the purchase of new App requests and track the status of your current requests. In Figure 17, you see how an end user has placed a pending request for the purchase of a SharePoint App.

Note The SharePoint App that was used was picked randomly from the available amount of SharePoint Apps in the Preview.

Figure 17 On the Your Requests page, end users can check the status of the App requests they’ve made.

Installing Apps

End users can install Apps coming from various places, if they have the Manage Web site and Create Subsites permissions that are by default part of the Full Control permission level or available to all members of the Site Owners group. Also, you need to enable Apps, as described in section “Configuring the App environment”. Only real end users can install Apps, you can’t install them while you’re logged in using the System account.

Apps are installed to SharePoint site collections. As a result, if you want to reuse Apps, you’ll need to reinstall them for each site collection. Another gotcha is that you need to be aware of the various sources where Apps are coming from. There is a set of default Apps, such as the standard SharePoint lists and libraries or Apps you’ve already purchased, there are Apps from a Corporate Catalog, and then there are Apps from the SharePoint Store.

In the next procedure, you will learn how to add Apps coming from the default set to a SharePoint site.

1. Open your SharePoint site.

2. Click Settings > Add an App. This opens the Site Contents > Your Apps page. Here, you see the Apps that are available by default, as shown in the Figure 18.

Figure 18 The Site Contents – Your Apps page contains an overview of all the Apps that are available by default.

3. Click the App you want to add and specify a name for SharePoint Apps, or follow the instructions for custom Apps.

Once the App is added, it appears in the Site Contents list (Settings > View Site Contents). This page is not opened automatically after App installation, so this may be confusing the very first time.

Note Once the App is added, it is added for all end users within the same site collection at the same time.

The next procedure discusses how to add Corporate Catalog Apps to a SharePoint site.

1. Open your SharePoint site.

2. Click Settings > Add an App. This opens the Site Contents > Your Apps page.

3. Click the From [App Catalog name] link.

4. Choose an App, this opens the Grant Permission to an App dialog box.

5. Click Allow Access.

Again, the App appears in the Site Contents list.

In the next procedure of the section, you will see how to add SharePoint Store Apps to a SharePoint site.

1. Open your SharePoint site.

2. Click Settings > Add an App. This opens the Site Contents > Your Apps page.

3. Click the SharePoint Store link.

4. Choose one of the Apps and click Buy It.

5. Then, follow the instructions and Allow Access to the App.

Again, the App appears in the Site Contents list. If you have saved the App package on a file system, you can also use PowerShell to install the App to the SharePoint site collection. Before you do so, check that you’re a member of the securityadmin fixed server role on the SQL Server instance, db_owner fixed database role on all databases that are to be updated, server Administrators group, and SharePoint Site Owners group of the site collection where the App is installed.

In the final procedure of the section, you will see how to install an App package from the file system to a SharePoint site collection and add the App to a SharePoint site.

1. Start the SharePoint 2013 Management Shell.

2. Import the App package using the following command (replace [Path] with the file system path pointing to your App, replace [URL] with the site collection URL, and replace source with one of the following options Marketplace, CorporateCatalog, DeveloperSite, ObjectModel, RemoteObjectModel, or InvalidSource.:

Copy $spapp = Import-SPAppPackage -Path [Path] to app -Site [URL] -Source [Source]

3. Type Y to import the app.

4. Add the App to a site by entering the following command (Replace [URL] with the SharePoint site URL):

Copy Install-SPApp -Web [URL] -Identity $spapp

The App is successfully added to the SharePoint site.

Note If you want to learn more about using PowerShell and SharePoint 2013, and in particular PowerShell and SharePoint 2013 Apps, there are TechNet resources available for you. http://technet.microsoft.com/en-us/library/jj219772(v=office.15).aspx provides an overview of all App Management Service cmdlets in SharePoint 2013, and http://technet.microsoft.com/en-us/library/ee890108(v=office.15).aspx contains the Windows PowerShell for SharePoint 2013 reference.

Uninstalling Apps

To remove Apps, end users need to have Manage Web Site permissions which by default are handed out to Site Owners or end users with Full Control permissions. One of the biggest advantages of the SharePoint App model is that it guarantees a clean uninstall, since all App specific resources such as lists, site pages, and JavaScript files are created in a separate AppWeb. In this section, you will learn how to uninstall Apps.

The next procedure explains how to uninstall Apps via the user interface.

1. Open the SharePoint Site where the App is added.

2. Click Settings > View Site Contents. This opens the Site Contents page.

3. Select an App > … > Remove. This opens the Message from webpage dialog window asking if you’re really sure about removing the App.

4. Click OK.

The App is removed from the SharePoint site.

If you want to remove Apps via PowerShell, you need to have the same permissions that are required to install Apps via PowerShell. Please refer to section “Installing Apps” for more information. The next procedure explains how to uninstall Apps via PowerShell.

1. Open the SharePoint 2013 Management Shell.

2. Get all installed Apps of a specific SharePoint site using the following command (replace [URL] with the SharePoint site URL):

$instances = Get-SPAppInstance -Web [URL]

3. Get the App you’re looking for using the following command:

$instance = $instances | where {$_.Title -eq ‘[App_Title]’}

4. Uninstall the App using the following command:

Uninstall-SPAppInstance -Identity $instance

5. Type Y to indicate that you really want to uninstall the App.

Now, the App is uninstalled.

Updating Apps

Eventually, Apps will get updated. Either because new functionality is added or because of some bug fix. SharePoint 2013 has its own Upgrade framework for handling these situations. Under water, an App upgrade means a new App package is created that contains an App manifest file that contains an increased version number. Once this new App version is deployed to either the SharePoint Store or Corporate Catalog, the Site Contents page of every SharePoint site where the App is installed shows a link that can be clicked by end users or administrators to update the App. If the App requires a different set of permissions, the end user will be asked to approve these changes.

Important This also means that as an administrator, if there’s a new version of an App available, you need to upgrade it for every SharePoint Site separately.

Updating an App is an all or nothing approach. Once a new App version is installed, let’s say v1.1, an entire new AppWeb is created for the new version. Once that has been completed, the AppWeb v.10 becomes read-only, and any content from the v1.0 AppWeb is copied to the v1.1. AppWeb. Once that is completed, the AppWeb v1.0 gets deleted. All these actions happen in the background and are seamless for end users and administrators. It’s the responsibility of each App itself to make sure a new version is compatible with older App versions.

More Info The following resource contains more information about the updating SharePoint Apps: http://msdn.microsoft.com/en-us/library/fp179904(v=office.15).aspx.

Managing Licenses

Apps that are purchased via the SharePoint Store require licenses, which can be managed via SharePoint Central Administration. The next procedure explains how to do this.

1. Open SharePoint 2013 Central Administration.

2. Click Apps.This opens the Apps page.

3. In the SharePoint and Office Store, click Manage App Licenses. This opens the App Licenses page. Here you will seean overview of all the Apps you’ve obtained from the SharePoint Store.

4. Select an App > Manage License. This opens the Manage App License page.

5. In the Actions drop down box, you can choose to view the App in the SharePoint Store, Recover the App license, or Remove the App license.

6. In the License Managers section, you can add and remove people who are responsible for handling the Licensing for the given App.

Mote Info The following TechNet article contains more information about this topic: http://technet.microsoft.com/en-us/library/fp161235(v=office.15).aspx.

Monitoring Apps

It’s possible to monitor Apps within SharePoint Central Administration, or in the SharePoint site hosting the App. The data about monitored Apps is collected by the ECM analytics timer job and can be delayed for up to 29 hours. When this timer job is run, it collects all App events about the previous day. In this section, you will see how to set up App monitoring.

Important The Monitor Apps page only works correctly if the following timer jobs are active: the Usage Analytics timer job for Search Service, and the Microsoft SharePoint Foundation Usage Data Import timer job.

The next procedure explains how to set up App monitoring in SharePoint Central Administration.

Note The user account must be a member of the Farm Administrators SharePoint group.

1. Open SharePoint 2013 Central Administration.

2. Click Apps. This opens the App page.

3. In the App Management section, click Monitor Apps.

4. Click Add App and select the checkbox for the App that you want to monitor, or search for an App using the Search for App name textbox, and then select the App that you want to monitor.

Note Only Apps that have not been added to the Monitored App list will be displayed in the search results.

This allows you to be build a centralized list of Apps that you want to monitor via SharePoint Central Administration. For each App, the following information is tracked: Name, Status, Source, Licenses in Use, Licenses Purchased, Install Locations, and Runtime Errors. Apps can be removed again by checking a specific App and clicking Remove App in the ribbon.

The next procedure explains how to monitor Apps in a SharePoint site (you need to have site owner permissions in order to complete the steps).

1. Go to Settings > View Site Contents. This opens the Site Contents page and all Apps that are installed on this site are displayed. This page allows you to start monitoring Apps, as shown in the Figure 19.

Figure 19 You can start monitoring Apps via the Site Contents page to get insight in its health.

2. Click the icon next to the App you are interested in and select MONITOR. This opens the App Details page for the selected App, shown in Figure 20.

Figure 20 The App Details page displays interesting information about App’s everyday life.

The App details page, contains information about its version, installer, install data, possibly licensing information, any install, runtime or upgrade errors about the last four days, and shows usage data about the last days, months, or years. Some of this information allows you to see more details by clicking on it (the various error metrics are good examples of this). For Apps that leverage Business Connectivity Services (BCS), there’s even a graph showing the number of calls made to external data sources.

Note After Apps are provisioned, each App gets its own permissions and App Identity. The App Identity can be used to find out about the activity of Apps in the audit trail.

The final procedure of the section discusses how to check App permissions.

1. Open SharePoint 2013 Central Administration.

2. Click Apps. This opens the Apps page.

3. In the App Management section, click App Permissions. This opens the App Permissions page.

Now, you can lookup App permissions by entering the App ID that was used to register the SharePoint App.