We have a requirement to control access to our SaaS based web application based on IP addresses (that is, we will have to limit access to Company A users only if the request originates from the PCs in their subnet). How do you solve this issue?
Use a Virtual Private Network solution. This allows you to separate the authorization from the application logic. It will also encrypt the communication so eavesdroppers cannot read the data being sent back and forth.
You have two options (ok, just seen @Mark's answer, so at least three options), my two are both whitelist:
- You configure the server hosting the service so that it only accepts requests from the designated ranges
- You put the whitelisting into the software and validate the IP address for each request as you receive it
Technically the first is probably the easiest (assuming a standard web server that you have control over) as its already there. In IIS for example you'd deny access to except specified. The problem is one of maintenance and that becomes a bigger issue if you have multiple servers as they have to be kept in sync and (if we're keeping it simple) those responsible have to have admin access to the server.
So the better solution of the two long term (because the above you can implement immediately) would be to check the requests as they arrive at your service and validate the requests against a "database" of valid IP addresses and then just reject any requests you don't like with whatever response you feel appropriate. This has the advantages of a) giving you more control (for example you could choose to allow less restricted access to some services if appropriate) and b) allowing you to provide your own tools for maintaining the IP address table since one would hope - if your SaaS is successful - that this will be an important and ongoing task.
There is no single right answer here - if a VPN is a workable solution then that has considerable merit but in turn that comes with its own set of configuration and maintenance issue.
If it's a pure web-based service, why not use https and restrict access to only those with proper client certificates? Granted, it's more complex to roll out than just having IP-range rules, but it should be more stable (plus secure, so depending on your setup there would be no need to have a separate "log in" step).