SharePoint Apps Setup Theory

What

SharePoint 2013 introduced the concept of 3rd party Apps, which can be remotely added to your SharePoint farm (via the Microsoft SharePoint Store). In order to set this up, an administrator needs to configure SharePoint and their organization’s network settings to allow this integration between their SharePoint farm and the App Store.

There are a couple possible approaches to opening up your SharePoint farm to connect to the Microsoft App store, each with their own set of pros and cons. The two approaches we’re referring to are as follows.

For the examples below, assume your SharePoint 2013 farm is hosted on the domain “itgroove.com”.

  1. Use a unique domain name to host your apps.

    Ex. itgrooveapps.com

  2. Use a subdomain (on the same domain as your SharePoint farm) to host your apps.

    Ex. apps.itgroove.com

So What

Microsoft best practices dictate that you should always choose approach #1, and not choose approach #2 (reference), as #2 poses a security risk. The rationale is that by going with approach #2, you’re opening up your farm to potentially malicious code, from a 3rd party developer. I won’t go into the specifics about how they might accomplish this using approach #2, but to say the least, they’re absolutely correct in their assertion.

There is however a downside to approach #1, which some companies may be willing to accept (the Risk), in order to still allow themselves access to the overall benefit of using the SharePoint App Store. By going with approach #1, you will require an additional external IP address, external domain, and an additional SSL certificate if you plan to expose SharePoint to the Internet, all of which will cost an organization money at an OPEX (operating expenditure) level. Some organizations may not be willing to incur the additional (monthly/yearly) costs, and thus will choose to go with approach #2, in order to avoid said costs, which may be in the range of several hundred to upwards of over a thousand dollars per year, depending on the provider(s).

Now What

itgroove’s recommendation is to always follow Microsoft’s best practices, and use a separate, unique domain for your SharePoint apps. Given that statement, we’re aware that not every organization will be willing or able to afford the additional costs – so it comes down to accepting the risk or paying for the domain and management to mitigate it.

Depending on your organization’s needs, you may choose to accept the additional security risk, in order to save the additional OPEX cost.

3 responses to “SharePoint Apps Setup Theory

  1. I have a question regarding subdomain usage. If I have a farm at spsite.companyname.com, would it be safe to use an app domain of apps.companyname.com? This is technically not a subdomain of the FQDN that is hosting the SP site.

    Your thoughts would be greatly appreciated!

    -Joseph

    1. That’s what we do here. We have “go.mycompany.com” and “apps.mycompany.com”. The subdomain is from the same domain.

      1. So the concern isn’t having them hosted in the same domain, or even having the apps domain as a subdomain of an existing domain… the concern is having the apps domain as a subdomain OF the SharePoint site itself?

        Thanks!

Comments are closed.