Some time ago I thought about some basic requirements of a permission/authorization system for ChiliProject. The following ideas and concepts are the result of that.

From what I have read, most of the requirements can be satisfied by using https://github.com/stffn/declarative_authorization. We should create a prototype to confirm that. The only thing that seems to be missing is the free declaration of roles. We might need to adapt some code here. But all in all, it looks really impressive.

The basic ideas¶

Permission should be always bound to model objects.¶

Only model objects can reliably check whether then can be seen/updated/deleted by the current user (or any other user). We have two cases here:

• dealing with a single object (like a single issue)
• dealing with aggregations (like a sum of hours of some time entries)

In the first case, it is rather simple: we can can have the model instance check itself using some instance methods, like issue.allow_read_by(User.current). The second case is a bit harder, as we have to express our accessibility restrictions in SQL (or AREL expressions in Rails3). So in the worst case, we have to express the same specification in two different ways.

Enforcing permissions¶

When handling permissions it is critical that they are actually checked. When they actually need to be checked depends heavily on the permission itself.

Let's first focus on single objects. We can basically distinguish the 4 basic CRUD operations, which means we have one read operation and 3 different write operations (create, update, delete).

Write Operations¶

Write operations can easily be checked just before changes are actually written to the database (e.g. as part of object validation).

Read operations¶

When to validate the read permission is a bit harder. I see basically 2 variants when to check those.

The first would be to check permissions at the transition from controller to view. Unfortunately, this might be too late, depending on how the model object is accessed or transformed in the controller. We would either have to traverse the complete object graph of all objects passed from the controller to the view and check permissions of each of them or implement a complex tainting system. There, read permission checks could be enforced if an attribute is accessed in view code, but not in controller code.

Both of the variants are hard to implement and have a few gaping holes nevertheless. The biggest issue is that objects could be serialized to XML or JSON before it even reaches any view code. Or there could be even just a new attributes extracted.

All in all, this sound way too complex and insecure.

The second approach would be to directly check permissions after fetching them from the database, as part of the find or reference traversal on objects. This approach would imply that it is impossible to read objects from the database layer when the current user doesn't has read-permission for it which sounds like a rather secure approach. But it also has a few issues.

How to bootstrap authentication information? This would probably require that user, group, and permission information can be read (rather) unrestricted.

It also restricts the use-case of complex data aggregation in Ruby code, i.e. when the user could see sums of a certain granularity, but not the individual objects, for example in a complex reporting environment. When read permissions are enforced before the controller can get the data to aggregate it, this doesn't work.

We would need a way to gradually turn of read permission checking in a controlled way. That would require extreme caution by the programmer to not let unrestricted objects pass to the user agent. This could be partly mitigated with requiring strict programming guidelines. Another alternative could be to only allow unrestricted read-access in a kind of sandbox (like a block). Objects could be restricted to only pass outside of that block when they are untainted in some way. However, this would still not disable passing of certain attributes to the outside world.

Remaining Issues¶

• check context (@project, ...)
  • is this actually an issue? The model should be absolutely clear about their state for a given user.
• link_to_if_authorized for arbitrary locations?
  • Check general read right when I set the link (issue.allow_read_by(User.current) or Issue.allow_read_by(User.current))
• emulate/adapt *_path style methods