2

I'm new to Web API, HTTP and security in general, but I just want to know if this is possible: for a controller to relax security requirements when the HTTP request originated from within the local area network.

My particular application has very low security requirements for clients inside the firewall. For instance, I want internal client apps to be able to make requests of controller actions marked with [AllowAnonymous] so that they don't need to deal with OAuth, etc (which just seems like complete overkill for my internal use scenario).

However, if the same controller actions are available to the public Internet, of course strict security requirements should apply.

Can security be handled differently based on origin? Or is the standard practice to expose both a public-facing and an Internal API?

Ashish Tiwari
  • 2,168
  • 4
  • 30
  • 54
BCA
  • 7,776
  • 3
  • 38
  • 53

2 Answers2

3

When you use the [AllowAnonymous] attribute on your controller or action, you tell ASP.NET that it should not check the user's identity at all. That is not what you want for users coming from the internet.

You could remove the [Authorize] attribute from your controller and manually check inside the action if the user is authenticated using:

if (User.Identity.IsAuthenticated || IsLocalUser())
{
    // action implementation
}

You can implement this check in a custom authorization attribute.

This still leaves you with the task to determine whether the user is local or coming from the internet. You could check the client IP-address to determine this of course.

Another option would be to enable both Windows authentication and bearer scheme authentication if your local users are part of an Active Directory domain. Users from your intranet could use Windows authentication to talk to the service, while internet users need to bring a JWT token. This would only work if the client application for users coming from the internet is different than for local users. DISCLAIMER: I've never tried this last option.

Community
  • 1
  • 1
MvdD
  • 22,082
  • 8
  • 65
  • 93
1

Identifying a request as one from "inside the firewall" isn't always as simple as just investigating the IP address. Although, this may work for you now, it may make it difficult to move environments or modify the environment without affecting application logic.

I would recommend developing a simple middle layer application that simply has the job of calling your main application with enough authorization data to handle security in the same context as your regular app, but this middle layer would in itself not be authorized. You will then just have to make sure that this app is not accessible to users outside of the firewall.

boosts
  • 605
  • 1
  • 7
  • 15
  • Can you elaborate on why the local-IP-check might break if the environment changes? Even if I change the network's subnet address or machines' addresses, wont a check like [this](http://stackoverflow.com/a/8113687/1628429) still continue to do its job? – BCA Jun 24 '16 at 12:34
  • The security of the app shouldn't be based on hard coded IP address segments in an authorize attribute. Chances are that there will be a need to change network later on and having to update the application source code to adjust to that is one more thing that you or someone else who maintains the app has to remember. In any case, simplicity of a local IP address check is nice, but as I said it depends on whether you foresee a need to change network at some point in the future. – boosts Jun 24 '16 at 22:21
  • I must be missing something here. If I start out with a LAN of 192.168.0.x, with that `IsLocal()` check working, then a year later am forced to change the LAN to 192.168.1.x, I won't have to recompile anything; `IsLocal()` will continue to work because I'm always using private addresses for all machines on the LAN. So am I missing something? – BCA Jun 25 '16 at 14:12
  • 1
    Just recently my network needs changed in the office, so I introduced 2 other local networks, 192.168.2.* and 193.168.3.* and had to migrate some sites to the other networks. Under these circumstances, or similar ones, you will just have to remember that your code is dependent on user's IP address for security. Another reason why not to go with the IP solution is that if a local device is affected by intrusion, your app could easily be affected as well. Basically, what it comes down to is that the practice of having open back doors in an app is not advised. As I said previously too though, it – boosts Jun 26 '16 at 16:09
  • "open back door"... I think I get what you're saying now. Thanks for the help – BCA Jun 27 '16 at 13:15