locked
Restricting Web Service to localhost

    Question

  • Hi,
      I am trying to restrict the web service to only respond to clients from the same server.  In other words, I am checking the 'HttpContext.Current.Request.UserHostAddress'. 

    I have couple of questions,
      1.  Is it possible for the client to manipulate the value of 'UserHostAddress' so that it looks as though the request is originating from the local machine even though actually it is not?

      2.  Is there any other config way of saying that this webservice can only be invoked from the local machine?


    Here is the code in VB.NET,

    Private Function CheckIfRequestIsFromLocalMachine() As Boolean

    ' make sure the request is for localhost

    ' user host address of the user to determine where the call is made from

    Dim bReturn As Boolean = False

    Dim objClientIPAddress As System.Net.IPAddress = System.Net.IPAddress.Parse(HttpContext.Current.Request.UserHostAddress)

    ' first check by server machine name

    Dim arrServerIPAddress As System.Net.IPAddress() = System.Net.Dns.GetHostByName(Server.MachineName).AddressList

    For Each objIPAddress As System.Net.IPAddress In arrServerIPAddress

    If objIPAddress.Equals(objClientIPAddress) Then

    bReturn = True

    Exit For

    End If

    Next

    ' then check by 'localmachine'

    If bReturn = False Then

    arrServerIPAddress = System.Net.Dns.GetHostByName("localhost").AddressList

    For Each objIPAddress As System.Net.IPAddress In arrServerIPAddress

    If objIPAddress.Equals(objClientIPAddress) Then

    bReturn = True

    Exit For

    End If

    Next

    End If

    Return bReturn

    End Function

    Thursday, November 03, 2005 1:24 AM

Answers

  • I think you can restrict access to the web service to only the local machine by setting the IIS IP address to the loopback address (127.0.0.1)

    Hope this helps.

    Rich

    Friday, November 04, 2005 11:22 AM
  • I think you have three options:

    1) Separate your app into two parts, and host each part in a separate IIS Site. The Site that hosts the localhost-only functionality would be bound to 127.0.0.1 in the manner previously suggested. You can still host both Sites on the same box and even in the same AppPool in IIS6 but it does mean that you now have two applications instead of one. Advantages: easy. Disadvantages: you might have to rework your app architecture if you're keeping a lot of application state around in process-wide statics.

    2) Write code at the application level to assert the localhost-only restriction. You seem to have the mechanics of this part taken care of. Advantages: preserves your current application architecture. Disadvantages: extra code you have to maintain and call on every request.

    3) Tie the security restriction to the identity of the calling party and not which box they're sending the message from. I think this is likely the best choice.

    You didn't say what this web service does or why it can't be accessed off-box, but I suspect it's because this endpoint exposing some sort of administrative functionality that you don't want the whole world being able to access. If so, you really want to be thinking about role-based rather than location-based security model. There are a range of options for doing role-based security within a web service world -- from simple Windows Authenticaiton at the HTTP transport level all the way up to message-level security using WSE 3.0 or WCF. That's getting outside the bounds of this discussion, though.

    Hope that helps a bit
    -steve



    Monday, November 07, 2005 9:51 PM

All replies

  • I think you can restrict access to the web service to only the local machine by setting the IIS IP address to the loopback address (127.0.0.1)

    Hope this helps.

    Rich

    Friday, November 04, 2005 11:22 AM
  • But the web service is part of a web application.  The web application will be accessed from various clients.  I am not sure if I can change any IIS settings.

    Chakra
    Monday, November 07, 2005 6:44 PM
  • I think you have three options:

    1) Separate your app into two parts, and host each part in a separate IIS Site. The Site that hosts the localhost-only functionality would be bound to 127.0.0.1 in the manner previously suggested. You can still host both Sites on the same box and even in the same AppPool in IIS6 but it does mean that you now have two applications instead of one. Advantages: easy. Disadvantages: you might have to rework your app architecture if you're keeping a lot of application state around in process-wide statics.

    2) Write code at the application level to assert the localhost-only restriction. You seem to have the mechanics of this part taken care of. Advantages: preserves your current application architecture. Disadvantages: extra code you have to maintain and call on every request.

    3) Tie the security restriction to the identity of the calling party and not which box they're sending the message from. I think this is likely the best choice.

    You didn't say what this web service does or why it can't be accessed off-box, but I suspect it's because this endpoint exposing some sort of administrative functionality that you don't want the whole world being able to access. If so, you really want to be thinking about role-based rather than location-based security model. There are a range of options for doing role-based security within a web service world -- from simple Windows Authenticaiton at the HTTP transport level all the way up to message-level security using WSE 3.0 or WCF. That's getting outside the bounds of this discussion, though.

    Hope that helps a bit
    -steve



    Monday, November 07, 2005 9:51 PM
  • Thank you for your response.

    Option (1) is not going to work because I want the web application and the web service to run on the same AppDomain.  I have some concurrency issues between the web application functionality and the web service.  Hence to make sure that I execute critical sections properly, I need to run them under same appdomain.  I am assuming that if we split in to two IIS sites, then the web service and the web application would be running under different appdomains.

    Option (2) is best because of the security model that we have adopted.

    Option (3) might work also. But I don't want to tie the access to particular user as opposed particular machine. This is mainly because of the security model that we follow.

    Chakra
    Tuesday, November 08, 2005 6:11 PM
  • May I ask the weird question? Why would you want to do this?

    From what I see, you're basically saying you want to use a WebService just from the local machine, and since you require it to run inside the same app domain as the rest of the app because of synchronization issues, then you have also several other issues that affect them.

    It seems to me, imho, that a webservice here is probably a wrong choice of technology for what you're doing, and it's giving you more trouble than it is worth. At the least, it will be far more innefficient than necessary, given as how you're basically doing basic IPC and that, it would appear, you are even esentially staying in the same appdomain (is the web application itself that is calling the webservice?).

    Then again, that's just my opinion :)
    Wednesday, November 09, 2005 10:45 PM