How to tell who is calling web service (PHP on Apache)

views:

127

answers:

+2 Q:

How to tell who is calling web service (PHP on Apache)

I am creating a web service using php's SoapServer built-in class. I have run some basic tests and it seems to be working fine, but now I need to limit who can use the service.

Assuming that only other scripts on the same server are trying to consume my service, and that they would do this server-side (as opposed to with AJAX or similar means), does my service have any means of identifying the owner of the requester?

I could limit access the service to only requests coming from a specific origin, but this seems either very strict or very unreliable, depending on if I allow access to any script in a directory vs. only specific scripts.

I'm just not clear if I can limit access by the user on the server since the user that the original requesting script will be www.

You could use a registration key as most famous API's do, like weather bug....

so when a request comes in, you could check the the code and see whether the user has registered to use your API.

Vivek Bernard 2010-01-11 13:33:02

Do I set it up like a GET variable to the actual service? A user would call the service like `mywebservice.php?key=1234`? And then I would check against the key in the service itself?

Anthony 2010-01-11 13:38:32

@Anthony, thank you for the vote down, As far i know, many public webservice APIs, (Yahoo, Weather Bug) require a developer to register after that they will be provided with a Key, which when I request for a service Will have to pass as an argument.In .net the method 'called' is called a web method, (if you're a .net devpr forgive me)and so , when the method is called at the webserver it kindof athenticates me as a resgitered user of the API. Thats what I meant not "mywebservice.php?key=1234?"But through XML

Vivek Bernard 2010-01-11 16:18:39

@Vivek: No vote down here. I don't know enough about the topic to know good from bad, or I wouldn't be asking (or asking follow up questions). Sorry that someone else felt it was off. But Nir is giving your method a strong endorsement.

Anthony 2010-01-11 19:27:05

You can always implement HTTP authentication against a data source of your choice. Apache has various options for doing Digest and Basic auth against a myriad of sources (we use mod_auth_mysql to secure a php webdav solution) but PHP also has good documentation about how to do it at the app level.

http://php.net/manual/en/features.http-auth.php

philjohn 2010-01-11 13:40:21

I'm reading over the info at the above link, but my initial impression from their example is that this is for authenticating end users. I want to authenticate server-side access to the service, meaning that were a user to happen across a page that attempted to use the service, and the owner of the page had not registered, the user would only see some generic "access denied" error returned from the service, not a prompt for credentials, etc. My main hesitation with using an authentication method (at least at this point) is that if the service use is limited to the server, I'm not sure...

Anthony 2010-01-11 13:51:02

that I'll need the developer to require a password. I simply need to know that the owner of the script making the call is on the registered list. Or am I making a security hole with such a simple criteria?

Anthony 2010-01-11 13:53:59

To make the problem much simpler, what I'd like at this point is the ability to use a .htaccess file to limit access, but I'm not sure what exactly I'm limiting access to, since I'm not sure what the service is seeing in terms of "user". I guess I do need to read more about HTTP authentication.

Anthony 2010-01-11 13:57:14

Hi Anthony, just because HTTP Auth can be used for user access doesn't mean you can't use it to secure a web-service too.All you'd need to do is catch the exception thrown by Soap_Client, which would contain the HTTP 401 (unauthorised) code somewhere in there and then display a nice message to the user, the only entity ever logging in to the web service is the code that consumes it.

philjohn 2010-01-13 09:54:28

+1 A:

here are some of your options:

as vivek mentioned, a key in the url could do the trick, i have used this many times, and it works nicely, and also allows you to monitor who's consuming the service (different consumers, different keys)
you could restrict usage of the scripts by IP. this is like the nuke of restrictions, i've seen it used mostly in places where service is granted outside the original server, but where a VPN would be an overkill.
of course, you may require full authentication, but this has too much overhead, both in terms of programming, and in terms of usefulness.

however, i must ask:

if only scripts on the same server are consuming the service, why make it a service at all?
if you have (unrestricted) pages that consume this (restricted) service, what's stopping anyone from scraping those pages - no matter how hard you protect the service?

Nir Gavish 2010-01-11 14:11:46

It is a service because it will have access to items on other servers. To be honest, I'm not totally clear on why my client says it needs to be a Web Service, but I do know that the service has access to info otherwise limited to an admin doing with their credentials. In terms of why its a service even though it's limited to the same server: it is a very big server with a lot of developers and the goal is to limit the info being made available to developers who register for the service (and thus establish a legit need).

Anthony 2010-01-11 14:27:09

As to point 2: I'm not sure what you mean by unrestricted pages. The service would be used in one of two scenarios: 1) End-User logs in, server-side script queries service for end-user data and returns it (so the only scrapping done there is by an end-user logging in to get their own info); 2)agent logs in to very restricted page and does queries about various end users, which is returned by service. So neither scenario is public, but neither implies a limitation to the script/developer using the service. At best it is limited to the user logged in.

Anthony 2010-01-11 14:31:15

Which I'm not sure is enough for the client, since I think they also want to limit who gets to use the service as well. I'll investigate, in case I misunderstood.

Anthony 2010-01-11 14:33:28

well, if it's a requirement then it's a requirement :) from the details you added, i'm pretty sure you'd have to go with key-in-url if you want it simple - or full-http-authentication, if you want it enterprise-ready.

Nir Gavish 2010-01-11 16:24:51

Why not just make the web service available on the localhost vhost?

Not completely water-tight, admittedly but relatively simple to implement.

Or on a vhost running on a firewalled port?

symcbean 2010-01-13 13:18:52

ansaurus

tags:

views:

answers:

How to tell who is calling web service (PHP on Apache)

related questions