2

I'm developing a mobile app which needs to access a specific server inside a company network, and should be able to do so from anywhere in the world. The app communicates via HTTP to a Web service on the server. The first call is a login message and and successful login returns a session ID that is used to retrieve data.

How can the infrastructure in the company be setup to allow the app to always reach the server, yet at the same time be secure?

The Web service runs in an IIS and the security team doesn't seem to like the idea to make the Web service available to users outside the company network as is. The idea right now is to introduce a TMG in the middle between the app and the Web service, but more suggestions are very welcome.

I'm looking for a solution that emphasize simplicity and ease of access from the user perspective.

Improve this question
1
  • Is this a corporate app or a public app? Will it be available in public app stores?
    – k1DBLITZ
    Jan 26, 2016 at 20:05

4 Answers 4

Reset to default
1

My vote is TMG.

This will allow the service to be exposed while still allowing inspection of the traffic before it reaches the internal server.

Much like the VPN, it can be configured to require a client side certificate and/or a password for authentication as well as supporting a variety of encryption methods. This will prevent random scanners and script kiddies from poking at the service.

Utilizing TMG also has the benefit of 3rd parties not being "on" your network like they would with a VPN connection.

Improve this answer
1
  • We will stick with TMG and a ssl connection for now
    – MortenGR
    Jan 26, 2016 at 20:31
5

I would personally use a VPN and make the service accessible from the local network (VPN connections would appear to be local).

When using a VPN connection everything is encrypted and you require credentials to use the VPN. These credentials could change on a weekly, monthly basis, etc, etc.

Very short answer but it is very black and white.

Improve this answer
7
  • +1, keeps the security guys happy because it's no longer open to "users outside the company network", and keeps the requestor happy because it's available from anywhere in the world.
    – AlexH
    Jan 26, 2016 at 11:00
  • This is the best option.
    – Xander
    Jan 26, 2016 at 14:28
  • 1
    I don't see this as the best option. The app should not be considered "trusted". It will be installed on a device that is out of your control. Anything embedded in the app (keys, passwords) is up for grabs. Speaking of, how do you propose password changes to occur? Will he have to push out an app update every time the password is changed for the VPN?
    – k1DBLITZ
    Jan 26, 2016 at 15:04
  • @k1DBLITZ from what I understand is that this is a corp app, you can even give each user their own account to log into the VPN. vlan the web service so the VPN can only touch the service and then for the suggestion of changing passwords every time a password is changed for a user they have to change their VPN settings on their phone, if you want to build that into the app then you simply keep the password away from hard coding. though you would use certs bundled with the app just as an extra layer for when it hits the web service. modern phones can VPN without apps btw.
    – TheHidden
    Jan 26, 2016 at 15:17
  • 1
    @silverpenguin What you're suggesting is a support nightmare and does not fit the need for "a solution that emphasize simplicity and ease of access from the user perspective." I assure you first hand the overwhelming majority of users have no clue how to create/modify and manage a VPN connection on their phone, not to mention that you are now split tunneling with cell carrier networks and wi-fi hotspots.
    – k1DBLITZ
    Jan 26, 2016 at 20:13
0

You can use TLS with client authentication. The communication is encrypted and both server and client have to prove their authenticity by providing valid certificates. You can install a reverse proxy in front of the existing server to handle encryption.

Improve this answer
0

My thinking would be to keep it as simple as possible. Use a reverse proxy in your DMZ with ssl termination for encryption.

I personally use nginx on Centos but have used HAProxy before and they are both straightforward to set up. Both of them have community and commercial editions.

You might be able to find Docker images of nginx or HAProxy.

Your app would communicate with the reverse proxy encrypted on 443 and then the reverse proxy would communicate with the backend on port 80.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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