3

I have a security layer for providing the security of the requests that come to my server. For all web request that come in a login page is shown if cookie is not present. I am now introducing web service requests to this server which also look like normal web requests. Is there any way to differentiate these requests at the security layer so as to route them to different security implementations.

Both the web requests and web service requests come in as basic http requests.

Sai Pavan
  • 31
  • 2
  • 1
    A web service is just that a service that is accessed via HTTP... Technically the login form is a web service, I assume you mean that you have something replying JSON or XML to JSON or XML POST data, in which case you have to identify it the same way the web application does. Does it use a different ip address, domain name, specific page urlm always a different user agent (only works if there are dedicated clients, wouldn't rely on it at all and a javascript client will show as a standard web browser)... – ewanm89 Dec 18 '12 at 12:51
  • What kind of security layer is it? Application level proxy/firewall or firewall with deep packet inspection properties or just a standard state-full firewall? – ewanm89 Dec 18 '12 at 12:56
  • Define "normal". – Polynomial Dec 19 '12 at 09:10
  • The common way is to use different URLs. For example: If an URL intended for a browser is queried, you can use a form based authentication. But if an URL for a client is invoked, you can answer with an http basic auth request. – Hendrik Brummermann Dec 20 '12 at 22:16

2 Answers2

1

I guess the key question is how is your web service secured? If you are using an http connection for a web service, then it will need some pretty heavy security on the requests and responses itself (such as a signed incrementing HMAC) to validate message integrity. Either way, the best bet is probably to look at the structure of the request itself.

It's really hard to give you a good answer without understanding more about how you are capable of handling routing the traffic though. It could be as simple as setting up two different sites, one to handle the web requests and one to handle the web service. Then each site could have different rules assigned. If you are using a hardware device on the front end, then it would depend on the capabilities of that device.

AJ Henderson
  • 42,081
  • 5
  • 65
  • 112
0

The answer, conceptually, is very straightforward: SOAP web service requests will either be HTTP GET requests with an Accept header of "application/soap+xml", or will be an HTTP POST with a Content-Type of "application/soap+xml". Both of these will have a Request-URI that should be identifiable, either by the file being requested or by simply knowing your own site's architecture, as a service endpoint.

However, exactly how you would check these things depends on the architecture of your system. In a URI-translated system (like the StackExchange sites) or simply an environment in which requests for directories are the norm and are directed to default pages, the Request-URI header will be of no help to you unless you hard-code the location of every service (or place them all in a "services" subdirectory that's easy to check for). If some or all requests are over a secure channel like SSL/TLS, your inspection/security layer has to be behind your endpoint to the secure tunnel, otherwise you're just watching gibberish. These are just a couple of potential problems with just inspecting requests at the edge.

KeithS
  • 6,768
  • 1
  • 24
  • 40