Role based access to resources for a RESTful service

Question

I'm still wrapping my head around REST, but I wonder if someone can help with any suggestions or approaches to role based access control for a RESTful service, particularly from the point of view of securing the data and how the URLs might look. It's probably best to consider an example:

Say I have a REST service for Customers, and want to split the users of this REST service into Admin, Editor and Reader roles:

• Admins can change all attributes of a Customer resource
• Editors can change only some
• Readers can only view them.

Access control rights are assigned to the Customers entities individually. So for example a user of the service might have admin rights to Customers 1,2 and 3 but Editor access to 4,5 and Reader access to 7,8,9.

Now consider the user calling the service. What is a good way to seperate the list of Customers for the current User?

GET /Customer - this might get a list of all customers that the current user has Admin\Editor\Reader access to. But then on each Customer the consumer would need an indication of what role they have.

Or would it be "better" having something like

GET /Customer/Admin - return all customers the current user has Admin access to.

Just looking for some high level pointers or reading on a decent way to secure\filter the resources based on roles of the current user.

Answer 1

A method I have used to great success to expose the access level or roles the authenticated user has with respect to a particular resource is to expose it as HTTP verbs on the entity itself.

For instance requesting a list of all customers:

GET /customers
{
   customers: [
     {
        id: "/customers/1"
        allowed: ["GET", "UPDATE", "PUT", "DELETE"]
     },
     {
        id: "/customers/2"
        allowed: ["GET"]
     }
   ]
}

GET indicated read access UPDATE, PUT, DELETE would indicated Editor and or Admin access based upon the semantics of your API. If this sort of abstraction doesn't work in your case you could call the rolls out directly.

Additionally, you could provide a filter to the customers request

GET /customers?role=admin

Would return only the customers for which the authenticated user has the "admin" role.