Share via

Planning the Infrastructure Required for the new App Model in SharePoint 2013

  • Article

SharePoint 2013 brings with it a brand new application model, which we euphemistically refer to as the “app model” or “cloud app model”. While it brings a whole new set of opportunities from a development perspective, it also carries with it infrastructure requirements that you need to plan and build to support them. When I think about the app model in fact there are really three big pieces that I look at:

 

  1. The development model – this all about the how I’m going to develop my application, what new features am I going to take advantage of, etc. This is primarily a developer activity.
  2. The security model – the security model for these new applications is an interesting combination of “stuff”. You have the new concept of an app-principal, which is how you define rights for your applications. There’s the OAuth model which defines what content you can get at, as well as a mechanism for presenting SharePoint with a token that describes who you are – it’s very much like claims for applications. The security model and means by which these tokens are created and presented varies significantly depending on whether your application is hosted in SharePoint or somewhere else, and whether you’re using Access Control Services (ACS) as a trust broker or not. Lots of stuff there, and not something I’ll be covering in this blog post, but it’s something that is both a developer and an IT Pro activity.
  3. The infrastructure – here we’re talking about all of the “goo” that makes applications work within an organization. It includes the service applications, application domain and prefix, DNS, SSL, and web application configurations. It is primarily an IT Pro activity and is the basis of this blog post. This posting is also going to be focused on applications that are hosted in SharePoint itself, versus an application that is hosted externally in another site or cloud like Windows Azure. When you install an application hosted in SharePoint, a new SPWeb is created for it. That way each application gets its own set of data and it cannot write over the data for another application. It also provides a layer of security so that someone who has rights to one application cannot have malicious code that uses the rights of the current user to access data in another site in the farm. This is an important basic principal of applications based on the new app model to remember – when they are hosted in SharePoint, one app = one SPWeb.

Now let’s start working through the list of these different infrastructure components. First and foremost, you need to make sure that you have an instance of the App Management and Subscription Settings service applications created and running in the farm. The App Management service is used for things like keeping track of applications and deployments, licensing, etc. The Subscription Settings service is the same service application that is used for multi-tenant deployments, and it is also used by the app model to create the unique Urls that are used by applications.

So how are these Urls created? Well it starts with the Apps configuration that you do in Central Admin. When you go into Central Admin you will find a new section called Apps. If you click on it you will see an option to Configure App Urls. In there you will find two values that are used to create an application Url – the App Domain and App Prefix. The App Domain is analogous to the host name that is going to be used for all applications in the farm. Here are three things to consider when you plan for this name:

  1. Because it is used for the whole farm it should get the same level of planning and thought as you use for your other web applications. 
  2. In addition to that it needs to be a fully-qualified domain name – you will find trying to use a NetBIOS style name for this doesn’t work well for name resolution. 
  3. Finally, it should NOT be a child domain of your web applications.

So let’s look at a specific example. Suppose your web applications are something like team.contoso.com, my.contoso.com and portal.contoso.com. First of all, you probably don’t want to use just “contoso.com” for your App Domain, because doing so will require you to create a wildcard DNS entry for ALL of contoso.com that points to your apps endpoint (more on that in a minute). Also you don’t want to use something like “apps.contoso.com” because that is a child domain to what you are using for your web applications (which are all rooted in “contoso.com”). So a better choice based on these rules would be something like “contosoapps.com”. 

The App Prefix value can be anything you want – it’s plugged into the first part of the application Url, which we’ll talk through next.

I mentioned using a wildcard DNS entry above, and that’s the next part to cover. When an application is installed and that application is hosted in SharePoint it will have a Url that is something like this: https://apps-87e90ada14c175.contosoapps.com/myapp/pages/default.aspx. The elements of the Url break down like this:

  • “apps” – this is the App Prefix value I mentioned above that you entered in central admin.
  • “87e90ada14c175” – this is a unique value that is based on the site collection and web where the application is installed
  • “contosoapps.com” – this is the App Domain that you entered in central admin.
  • “myapp” – this is the name of the application that has been installed. The rest of the Url – pages/default.aspx – is what is contained in the SPWeb where the application is installed.

As you look at the Url and how it’s formed, hopefully you understand why you will want to use a wildcard DNS entry. Because the first part of the Url is going to be different for every single application instance that is installed – even if the same application is installed in multiple site collections – it is not feasible to continually update your DNS for every single instance. So that being said, that means for DNS for the scenario I’ve described here, you are going to want a wildcard DNS entry for *.contosoapps.com. Now the IP address that it points to is something we’ll discuss in just a bit.

Related to the wildcard DNS entry is a wildcard SSL entry. Just so we’re perfectly clear on this point – if you’re using apps, you should be using SSL. The app model involves passing around OAuth access tokens, which describe who the current user and application are. Just like if you were passing around SAML tokens for a user, you want to encrypt the channel that these tokens flow over to prevent any kind replay style attack that would grant access to content by someone who might be out there sniffing your network traffic. Using SSL prevents those scenarios from happening, and since you’ve seen the Urls for these applications are going to be different for every installed instance, it also means that in order to be manageable you will need a wildcard SSL certificate. Again, in our scenario, we would get a wildcard SSL certificate for *.contosoapps.com.

Okay, so far we’ve talked about the service applications that are required, the configuration that is required for the App Domain and Prefix, how the Urls are formed, and the DNS and SSL entries that are needed. Now to tie everything off we need to talk about how application requests get routed. Generally speaking, you will need a separate SharePoint web application just to do the routing of application requests. Let’s take a look at why that is. Suppose again that you have three web applications that are defined as follows; they are all using SSL so we are using unique IP addresses for each one:

  • team.contoso.com – 192.168.1.10
  • my.contoso.com – 192.168.1.11
  • portal.contoso.com – 192.168.1.12

Now as described above you can only have one App Domain in the farm, and it should not be a child domain. This opens up two very real problems with the applications above:

  • If we install applications in each of these web apps, how do we get the right application request routed to the right web app? We only have one App Domain but three web apps.
  • If we try and route an application request to one of these existing web apps, then SSL will break. Why? Because since we are using SSL on all our web apps (since we’re using Apps), then they all have an SSL certificate that is something like *.contoso.com. So we can’t route application requests to them anyways, because you can’t get an SSL wildcard that works on both *.contoso.com and *.contosoapps.com, which is what our apps are going to be using.

The solution then is to create a fourth web application. SIDE NOTE: Technically you could create a second IP and SSL binding on an existing web application as long as that web application does not use a host header. You would of course then need to bind the SSL wildcard certificate for your apps namespace to that SSL binding. I do not cover that in the description below, but if you are doing a PLA-style deployment (i.e. one web app and only use host header site collections) that would be another option. This is already fairly complicated so I don't want to try and work that into the rest of this content, but wanted to point it out for completeness. You can create it without a host header name and assign it a shared IP of 192.168.1.13. In DNS then your wildcard entry for *.contosoapps.com will point to 192.168.1.13. What ends up happening is that your apps web application “listens” on that IP address and the SharePoint http module that is responsible for routing will pick up the request for the application. It will then use the App Management service application to determine what web application is actually hosting that application and request all of the information about the app, security, etc.. The request is then served from the web application that was listening, which is why it needs to be using the same app pool account as the other web applications are using - so it can access the content databases for those web apps.

Now our farm configuration looks like this:

  •  Apps Configuration

    • App Domain – contosoapps.com
    • App Prefix – apps

  • Web Applications

    • team.contoso.com
    • IP Address: 192.168.1.10
    • SSL Certificate: *.contoso.com

  • my.contoso.com

  • IP Address: 192.168.1.11
  • SSL Certificate: *.contoso.com
  • portal.contoso.com
  • IP Address: 192.168.1.12
  • SSL Certificate: *.contoso.com

  • No host header, or you could use something like contosoapps, etc. – it doesn’t really matter since we aren’t routing based on host header, we’re routing based on IP address. 

    • IP Address: 192.168.1.13
    • SSL Certificate: *.contosoapps.com
  • DNS
    • team.contoso.com – 192.168.1.10
    • my.contoso.com – 192.168.1.11
    • portal.contoso.com – 192.168.1.12
    • *.contosoapps.com – 192.168.1.13

Now, that we have all of the infrastructure configuration aspects of apps covered, there are a couple of other considerations you need to remember when planning for the rollout of new apps for SharePoint 2013:

  • SharePoint-hosted Apps do not work on web applications that use SAML; they DO work if you use a provider-hosted app - for more details see https://blogs.technet.com/b/speschka/archive/2012/12/07/using-sharepoint-apps-with-saml-and-fba-sites-in-sharepoint-2013.aspx. If you are using SAML authentication then you will not be able to use SharePoint-hosted Apps on those web applications. This might be resolved in a future service pack or some other type of patch, but this is a limitation right now.
  • SharePoint Apps do not support multiple zones (i.e. AAM); all requests are served out of the default zone. UPDATE: The March PU eliminates this restriction AS LONG AS you have a load balancer that can redirect to a different port number; Windows Load Balancing will not do this. If you are using AAM to support multiple zones then you will likely not be able to use SharePoint apps. All apps get served out of the default zone, so in theory if you had the default zone exposed so that everyone could reach it, and you were using the same exact authentication mechanism on every zone (with some possible limitations that are too detailed to go into here and now), then it’s possible that it would work. But then again, if you are using zones it’s usually because you either a) don’t want every endpoint exposed to everyone or b) you DO want to use different authentication methods. Again, this is something that may change in the future, but for now this what is available for SharePoint 2013 RTM.
  • UPDATE - I just found out today that if the web application that receives the request for an app is different from the web application that the app actually lives in, the web app that receives the request must be using the same app pool as the web app where the app lives. Alternatively, its app pool must use the same identity as the app pool where the application lives. So if you are following the guidance above and you have a separate web application that all of your application requests get routed to, the identity that its application pool uses must have rights to all the content databases for all of the web apps. There are a few different ways you can do that, but the simplest is to use the same app pool for all your web apps. The second easiest is to use the same identity for all your app pools. This also is something that may change in the future, but this is how it currently works for SharePoint 2013 RTM. UPDATE: Again, the March PU can help in this scenario, to the extent that you can redirect to different web apps. Explaining how is beyond the scope of this update note, there is a link to the latest docs explaining this in the comments below (thank you for that folks!)

 

One other important, final note: this seems like a lot of configuration, and it is. However, you should keep in mind that if you are using Office 365 then all of this is taken care of for you - no muss, no fuss, just easy to install and use applications. You should give that some consideration when weighing your options.

So there you have it – SharePoint Apps are a big part of SharePoint 2013, but they require some planning and design work up front to ensure the infrastructure is in place to support them.

 

 

 

Planning the Infrastructure Required for the new App Model in SharePoint 2013.docx

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Let's not pound the author with a bad rating on a well written and timely article because we don't necessary by into the message.

  • Anonymous
    January 01, 2003
    Eric, you got to add the appdomain to list of trusted sites in IE to get rid of password prompt....Manoj

  • Anonymous
    January 01, 2003
    True.

  • Anonymous
    January 01, 2003
    @Anonymous, this solution only works for IE...

  • Anonymous
    September 03, 2012
    I think I would rather just hire better SharePoint developers than attempt this mess.

  • Anonymous
    September 04, 2012
    Brilliant brilliant article.. Just love reading it.. Awesome stuff Steve...

  • Anonymous
    September 06, 2012
    Awesome article Steve... but I'm a bit confused now :) What about publishing the apps to internet with any publishing rules? If you have to publish the web application intranet.contoso.com to internet using url intranet.coolsite.com and this web application uses the apps model (assuming the apps are configured with *.contosoapps.com), could I publish the apps to internet with the url *.apps.coolsite.com ? Cheers

  • Anonymous
    September 18, 2012
    The comment has been removed

  • Anonymous
    January 08, 2013
    Hi Steve, Great Article.  Everything is working in the intranet.  However, our web app is accessible from the internet and when I try to access a SharePoint page that has two apps installed, SharePoint prompts me twice to login to each of those apps.  In the intranet, I have added the app domain (https://*.myappdomain.com) to local trusted zone so I don't get any prompts.  However, accessing from the internet, it is not going to work and as each app has a totally different url, I am going to be prompted each time.  This is a big issue as far as I am concerned.  Once I am authenticated to the SharePoint site, why is SharePoint not trusting those apps and not automatically authenticating them?   Thanks.

  • Anonymous
    January 10, 2013
    I have the same issue as above. I am prompted for a password for each app

  • Anonymous
    February 08, 2013
    I think the login prompts are coming from the listener web application which has to be Windows Authenticated web app which picks of any requests for the apps at first.  Not sure how to get around  this.

  • Anonymous
    April 11, 2013
    Great article Steve.  I'm wondering if the March update changes any of your guidance.  Thanks!

  • Anonymous
    May 15, 2013
    I have the same questions as MarcoR.  Everything works inside the firewall, but really confuse about how to publish this through TMG 2010.  Looks like the redirect.aspx is having a problem through TMG.  Not sure how I can route a *.contosoapps.com to the internal SP server.

  • Anonymous
    June 19, 2013
    The comment has been removed

  • Anonymous
    June 25, 2013
    I have the same issue as above. I am prompted for a password for each app as well.

  • Anonymous
    July 25, 2013
    The comment has been removed

  • Anonymous
    June 04, 2014
    Because of security reasons, you should not add your app domain to IE's Intranet or trusted site zones. Reference:http://technet.microsoft.com/en-us/library/fp161237(v=office.15).aspx

  • Anonymous
    July 22, 2014
    How to do that to point to a SharePoint farm? there is no dedicated IP to share in all servers.

  • Anonymous
    September 18, 2014
    The comment has been removed

  • Anonymous
    October 24, 2014
    Would SSL offloading work with SP hosted Apps?

  • Anonymous
    December 19, 2014
    Hi Eric Schrader,

    Would you mind sharing how did you make IIS website listen on dynamic URLs?

  • Anonymous
    December 19, 2014
    Hi Eric,
    Did you achieve dynamic URL routing using IIS URL rewrite feature?