Rest – Role based access to resources for a RESTful service

Architecturerestweb services

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.

Best Answer

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.

Related Solutions

Web-development – Software architecture for authentication/access-control of REST web service

OpenAM.

http://forgerock.com/openam.html

How should user details and access rights be stored? (data model, location, format)

Identity Manager. Separate from any web server. LDAP-based.

What are good design patterns for representing and tracking these in the server? (sessions in memory, db lookups each time, etc)

Solved by your framework. Think no more. Just use your framework's already-built good design patterns.

What are good patterns for mapping these rights to the services in a secure way in the code base?

Solved by your framework. Each framework uses a slightly different approach. Each language has slightly different features. Django, for example, uses Python's decorators heavily for this.

What architectural choices can help keep the system more secure and reliable?

More? More than what?

Rest – Role-based REST API

You should architect the API around resources, not around roles, e.g.:

/rest/students

should be accessible to anyone with a role that allows them to see students.

Internally, you are implementing role-based security. How you go about that depends on the details of your application, but let's say you have a role table, each person has one or more roles, and those roles determine what each person can access. You have already stated the rules for accessing students:

students can access students in the classes they take
teachers can access students in the the classes they teach

So when a person calls:

/rest/students

you call a method that accesses students, passing in the role of the person. Here is some pseudo code:

roles = person.roles; //array
students = getStudents( roles );
return students;

and in that method, you could get the students for each role with separate calls, e.g.:

factory = getFactory();
classes= [];
students = [];
for( role in roles ){
    service = factory.getService( role );
    // implementation details of how you get classes for student/teacher are hidden in the service
    classes = classes.merge( service.getClasses( person ) );
    // classes[] has class.students[]
    // loop on classes and add each student to students, or send back classes with nested students? depends on use case
  }
}

That's a very rough idea for what you could do and isn't necessarily going to fit your specific needs, but it should give you a sense of the pieces involved. If you want to return the classes with each student listed, this is a good approach. If you just want the students, you could extract them from each class and merge them into a collection of students.

No, you should not have a separate repository per role. All the role does is determine how you get the data, and maybe what you can do with the data (e.g. Teachers can enter Student grades). The data itself is the same.

As for patterns, this approach is using Factory Pattern to abstract away the service that gets data based on role. It may or may not be appropriate to have separate services by role. I like this approach because it minimizes the amount of code at each stage of the program and makes it more readable than a switch or if block.

Best Answer

Related Solutions

Web-development – Software architecture for authentication/access-control of REST web service

Rest – Role-based REST API

Related Topic