Cedmundo
Cedmundo

Reputation: 781

REST with complex permissions over resources

Background

I'm having a trouble with the design and implementation of a REST service which publishes content that some users cannot view (medical information, you know, country's laws), I'm using a ABAC-like/RBAC system to protect them, but what causes me concern is that I may be violating the REST pattern. My services does the following process for each query:

  1. The security middleware reads a token from a session that an app/webpage sends using authorization header or cookies.
  2. ABAC/RBAC Rules are applied to know if user can access the resource.
  3. After authorize the token, my service executes the query and filters the results, hiding content that requesting user cannot see (if needed. POST, PUT and DELETE operations are almost exempt from this step). The filter is done using ABAC/RBAC rules.
  4. An operation report is stored in logs.

I already know that sessions violates REST pattern, but I can replace it using BASIC/DIGEST authorizations. My real question is the following:

Question

Does hiding resources from list/retrieve operations violates REST pattern? As far I know, REST is stateless, so ... What happens if I use some context variables to filter my results (user id)? Am I violating REST? Not at all?

If I do, What are your recommendations? How can I implement this without breaking REST conventions?

Upvotes: 1

Views: 337

Answers (3)

Pedro Werneck
Pedro Werneck

Reputation: 41928

First of all, client-side sessions don't violate REST at all. REST says the communication between client and server must be stateless, or in other words, the server should not require any information not available in the request itself to respond it properly. If the client keeps a session and sends all information needed on every request, it's fine.

As to your question, there's nothing wrong with changing the response based on the authenticated user. REST is an architectural style that attempts to apply the successful design decisions behind the web itself to software development. When you log in to Stack Overflow, what you see as your profile is different from what I see, even though we are both using the same URI, right? That's how REST is supposed to work.

Upvotes: 1

WW.
WW.

Reputation: 24311

A GET is meant to return a representation of the resource. Nowhere does it say that you must return everything you know about that resource.

Exactly what representation is returned will depend on the request headers. For example of you might return either JSON or XML depending on what the client requested. Extending this line of thinking; it is ok to return different representations of a resource based on the client's authentication without violating REST principals.

Upvotes: 0

flup
flup

Reputation: 27103

I'd recommend returning status codes 401 (Unauthorized) if the user is not authorized to access a resource. And 404 (Not found) if you cannot confirm that the resource even exists.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.4

Upvotes: 0

Related Questions