Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

(Please forgive if this is posted in an incorrect forum. We didn’t know exactly where to post it.)

We have an ASP.NET Web API single page application - a browser-based app running in IIS to serve up HTML5/CSS3/JavaScript, which talks to the ASP.NET Web API endpoint only to access a database and transfer JSON data. Everything is working great in our development environment - that is, we have one Visual Studio solution with an ASP.NET Web API project and two class library projects for data access. While development and testing on development boxes, using IIS Express to a localhost:port to run the site and access the Web API, everything is fine.

Now we need to move it to a production environment (and we’re having problems - or just not understanding what needs to be done).

The production environment is all internal (nothing will be exposed on the public Internet). There are two domains. One domain, the corporate domain, is where all users login normally. The other domain, the process domain, contains the SQL Server instance that our app and Web API will need to access.

The IT staff wants to put a DMZ between the two domains to house the IIS app and shield the users on the corporate domain from having access into the process domain directly. So, I guess what they want is:

corp domain (end users) <–> firewall (open port 80) <–> DMZ (web server running IIS) <–> firewall (open port 80 or 1433????) <–> process domain (IIS for Web API and SQL Server)

We’re developers and don’t really understand all the networking aspects, so we’re wondering how to deploy our browser/Web API application in this scenario.

  1. Do we need to break up our application so that all the client code (HTML5/CSS3/JavaScript/images/etc.) is on the IIS server in the DMZ, while the Web API gets installed on the server in the process domain?
  2. Or, does the entire app (client code and Web API) stay together on the IIS server in the DMZ, which then somehow accesses the SQL Server instance to get data?
  3. From the IIS server and app in the DMZ, would you simply access the Web API on the server in the process domain by going to "http://server/appname/api/getitmes"?
  4. In the second firewall between the DMZ and the process domain, would you have to open port 1433 or just port 80 since the Web API is a HTTP endpoint?
  5. Or, is there some better way of deployment (i.e., how ASP.NET Web API single page applications written all in HTML5 and JavaScript supposed to be deployed to production environments?)?

I’m sure there are other questions, but we’ll start with these. Thanks!!!

(Note: the servers are Win2k8 R2, SQL Server 2k8 R2, and IIS 7.5.)

share|improve this question

closed as not a real question by Tim Brigham, SvW, Magellan, mdpc, Scott Pack Nov 13 '12 at 18:28

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

    
I've dealt with similar requirements in the past and would be happy to help, however this question is way to broadly scoped at the present time. There at least a dozen different approaches you could take at this point. Outlining the strengths and weaknesses of each could easily take a full days work. –  Tim Brigham Nov 12 '12 at 22:30
    
Hi Tim. Thanks for replying. Yeah, you're probably correct about the question being broadly scoped. I had a difficult time writing it, trying to convey all the pieces and information without writing a book. Since I'm no networking/security expert (I'm a developer and, up until now, we've only had to worry about installing our Windows forms apps on a single server with simple Windows authentication), I'm just trying to understand some things so I can speak somewhat intelligently to IT people, and figure out if we have to change our application in any way. Thanks again. –  lmttag Nov 13 '12 at 15:45

1 Answer 1

up vote 0 down vote accepted

I can understand your IT group wanting to break this out, but it seems they too also don't fully understand how this setup works. I won't go into that too much but essentially the only traffic you will be exchanging with the servers up to the process domain is standard HTTP traffic (assuming you are using the Web API for REST calls)

Essentially you end up with the following:

           Initial Request
SPA Web Server ---> Client (Running SPA)
                      |
                      | - REST Call
          Firewall -> | - Port 80 Only
                Web API Server
                      |
                      | - SQL (1433) .NET Connection/Data Source
          Firewall -> | - Port 1433 / 1434
             Backend SQL Servers

Remember that with a SPA the only communication the client has with the SPA web server is the initial request to get the HTML, JS and CSS. After that (depending on how you wrote it) it should be directly issuing REST calls to the Web API server.

The Web API server issues SQL queries directly to the database from there.

So the long and short of it is as follows:

TL;DR: You should have a firewall between your clients and your two IIS instances (they can be the same server btw) to allow either/or HTTP and HTTPS traffic. Then on another interface of that web server(s) you have a connection to the Process domain and only SQL traffic is allowed to come in (1433 and 1434).

Hope that helps.

share|improve this answer
    
Hello Brent. Thanks for replying. You are correct in your assumptions; that is, the application as it stands right now is a SPA in which the client gets all the HTML/CSS/JS on the initial request and after that only REST calls are made to the Web API. The Web API controllers on the server issue SQL queries directly to the database and return JSON data (in the case of GETs, for example). To clarify, you're suggesting putting everything (the HTML, CSS, JS, Web API assemblies, etc.) all on the IIS server in the DMZ and then send only queries to the SQL Server through port 1433? ... –  lmttag Nov 13 '12 at 16:17
    
... I was having trouble with this scenario. From a client browser (mobile Safari since this app is intended for mobile devices), I type in the URL to the IIS server (e.g., servername/appname) and get the HTML/CSS/JS downloaded to the browser. Inside one of my JS files, I make an AJAX call to the Web API (e.g., servername/appname/api/getitems). This all work locally when IIS and SQL Server are all on the same machine. Is there something else I need to do different to work in production where IIS and SQL Server are on two separate servers? ... –  lmttag Nov 13 '12 at 16:17
    
... Assuming the firewall stuff between the two servers is correct, do I just need to change my DB connection string to find the SQL Server? Or? Thanks again! –  lmttag Nov 13 '12 at 16:18
    
Yes, should just be able to update your SQL connection strings to whatever IP or server name your IT group provides to you. –  Brent Pabst Nov 13 '12 at 16:19

Not the answer you're looking for? Browse other questions tagged or ask your own question.