views:

252

answers:

5

Some existing web services I consume have methods that look something like this:

List<Employee> employees = 
        employeeService.GetEmployees(accessKey, allDepartments);

The accessKey serves two purposes; it acts as both authentication and identification. Only valid access codes are responded to (authentication) and it services as a link to a particular client's data.

If the services were to be done a restful manner I'm not sure how this would be achieved. I definitely would not want to do something like this:

http://www.business.com/&lt;GuidHere&gt;/Employees/

Since this would show the accessKey, which is somewhat secret, (ie, its usually in an encrypted file on the client which uses this) we can't show the GUID in a URI. How is something like this achieved using a restful architecture?

+4  A: 

You could send the authentication token using HTTP headers.

Mehrdad Afshari
+1  A: 

A solution would be to POST over HTTPS the identifier.

Vinko Vrsalovic
+1  A: 

Use http://www.business.com/employees and have the caller do an HTTP POST with the guid in it. Your controller action will be able to access this either through its parameter (assuming you're using the same name as that in the post) or by using Request.Form collection.

As Vinko pointed out, you may also want to use https if you want to keep the guid safe from inspection.

Kevin Pang
+1  A: 

If this is a RESTful web service I'm assuming it's being consumed by a machine so why not pass the access key in the url?

At then end of the day you need to put it somewhere and hiding them in hidden form fields in the browser (if the service is to be browsable) isn't much in the way of security.

If the key is so sensitive, why not symmetrically encrypt on the server per session and pass that value around instead?

Just some thoughts.
Kev

Kev
You're probably right... the average user wouldn't see the URL. Perhaps I'm worried about nothing.
Sailing Judo
A: 

If time isn't an issue implementing OAuth security may be useful. OAuth uses a public key, and also a secret. The mess is hashed (in most cases) and the server will use the public key + it's copy of the secret to do the same hashing and make sure its result matches the requests.

The benefit is you wouldn't need to use HTTPS or POST. Get* REST api methods should be using the HTTP GET method (I'm not sure if being RESTful is your goal, just thought I would point that out). I agree with Mr. Pang, use http://www.business.com/employees. The query string could contain the list of department ids.

For your case the service call wouldn't have the 'accessKey' argument, rather it would become the public key (I imagine) and be used in either the headers, query string, or as a POST param.

Some good info on OAuth: http://www.hueniverse.com/hueniverse/

Rob Ottaway