RESTful API authorization on entities/resources?

Question

I am working on an API in a system that has very complex access control rules. Often times there are complex SQL queries required to determine if a user has read or write ac

Answer 1

What you are looking for is fine-grained, externalized authorization:

• fine-grained: you want to create authorization policies that take into account multiple parameters or attributes and possibly relationships between the client (the requestor) and the targeted entity e.g. a listing in your case.
• externalized: you want to decouple the business logic from the authorization logic. In your question you complain about how complex the code and the SQL statements are becoming. This is a direct consequence of not clearly separating business logic from authorization logic.

There is a model called attribute-based access control (ABAC) that defines an approach to fine-grained externalized authorization. NIST, the National Institute of Standards and Technology, has produced a report on ABAC which you can read online.

OASIS, the organization for the advancement of structured information standards, has defined a standard called XACML (eXtensible Access Control Markup Language) to implement ABAC.

XACML brings you:

• an architecture as illustrated below
  • The policy enforcement point (PEP) intercepts your API calls. It protects your API, inspects the messages and sends an authorization request to the policy decision point (PDP).
  • The policy decision point (PDP) evaluates incoming authorization requests from the PEP against a set of authorization policies written in XACML. The PDP eventually reaches a Permit or Deny decision. To reach decisions it may need to look up additional attribute values from databases, web services, LDAP, or files. These are called policy information points in the architecture.
• a policy language: the XACML policy language is attribute-based which means it uses attributes to define what can be allowed and what is not. For instance, you could define rules such as:
  • a real estate agent can see all the listings if and only if the listing location == the agent location
  • a real estate agent can edit a listing if and only if he/she owns the listing
  • a real estate agent can close a listing if and only if the listing's item is sold and if and only if the agent is the person that sold the item.
• a request/response scheme: XACML also defines a way to query the PDP and to get responses back. A PDP can be queried either via single questions or via multiple questions in a single request e.g.:
  • Can Alice view listing 123? Yes, permit.
  • Can Alice view, edit, or delete listing 123? Permit; Deny; Deny.

With a XACML-based approach, you get to maintain your business logic and your API separate from the authorization logic. This has several benefits:

1. you can always reimplement the API and keep the same authorization model
2. you can easily expand your API without having to rewrite the authorization
3. you can change your authorization logic independently of your code
4. you can audit your authorization logic more easily
5. your authorization logic is technology-neutral. It works for REST APIs, web services, databases, and more

I recommend you check out the following resources:

1. the OASIS XACML website
2. the ALFA plugin for Eclipse - a free tool to write XACML policies.
3. The XACML developer community

There are both vendor and open-source implementations of XACML:

• Axiomatics is a vendor solution that provides both .NET and Java XACML implementations
• SunXACML is a long-standing open source Java XACML implementation

HTH, David.

Answer 2

Not trying to resurrect an old question, but I came here searching for almost exactly the same thing and wanted to add a solution that I think is more RESTful.

I haven't actually implemented this but think it may help others who come here...

Your second option is very nearly what I think should be done, but instead of a get use the OPTIONS verb to your resource which will then return an "allow" header with a list of available verbs for that resource.

OPTIONS /listing/5

Assuming your resources are fine-grained enough for this to make sense, then you would know if you can make a POST/DELETE