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:
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:
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:
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:
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:
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:
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.
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:
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.
I think I would rather just hire better SharePoint developers than attempt this mess.
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.
Brilliant brilliant article.. Just love reading it.. Awesome stuff Steve...
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 ?
I would love to read more about The security model as well.. I would like to hear your view on OAuth model or High Trust model for cloud hosted apps...
Stay tuned Nik; I'm just starting to talk to one of our writers about putting together an article on OAuth and High Trust Apps. We hope to flesh it out over the next few weeks and if we get lucky, maybe publish something before the end of the year.
In this article you have mentioned "sharePoint Apps do not work on web applications that use SAML".
You have mentioned the issue would be resolved by some service pack that will be applied to SP2013 RTM.
You also published another blog "Using SharePoint Apps with SAML and FBA Sites in SharePoint 2013" , where you advocated about SAML based authentication for provider hosted APP (S2S). You covered that SharePoint application and .Net Web application( remote web) to have claims based authentication in order to attain the functionality.
Please clarify whether apps for Sharepoint would work on Sharepoint site that has Claim based authentication using ADFS 2.0?
I could not understand the line "SharePoint Apps do not work on web application that uses SAML", Please clarify...
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?
I have the same issue as above. I am prompted for a password for each app
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.
So for the DNS entry for *.contosoapps.com, you do NOT create a forward lookup zone and CNAME entry rerouting to contoso.com, as Microsoft instructs us to here? technet.microsoft.com/.../fp161236.aspx
That is the only thing left I can think of to explain why my apps aren't working (they were working before I changed the IP to add the *.constosapps.com cert, I just got a cert error which was fine)
Great article Steve. I'm wondering if the March update changes any of your guidance. Thanks!
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.
Aaron, yes, the March update changes the Host Header limitation.
This article is the first time I heard about the "4th web application". I manually edited my web applications IIS website binding to allow the dynamic app url and it worked. Seems a bit of a work around to create an entire IIS website with a second internal IP as a catch-all. Is there any official guidance from MS about how this should be architected from a DNS/Web Application/IIS point of view?