How the RavenDB Authorization Bundle Operates

the question came up several times in the mailing list with regards to how the ravendb authorization bundle operates, and i think it serves a broader discussion.

let us imagine a system where we have contracts, which may be in several states:

• mine – contracts that an employee signed.
• done – standard users can view, lawyers assigned to the company can sign.
• draft – lawyers can view / edit, partners can approve.
• proposed – lawyers can create / edit, but only the lawyer that created it can view it, partners can accept.

so far, fairly simple, right? except the pure hell that you are going to get into when you are trying to show the users all of the contracts that they can see, sorted by edit date and in the nda category.

why am i being so negative here? well, let us look at what we are going to have to do in the most trivial of cases:

in this sort of system, we are going to have to show the user all of the contracts that they are allowed to see, and show them some indication what operations they can do on each.

the problem is that generating this sort of view is expensive . especially when you have large amount of data to work through. more interesting, from a ux perspective, it also doesn’t really work that well. most users would want a better separation of the things that they can do, probably something like this:

this allows us to do a first level filtering on the data itself, rather than try to apply security rules to it.

in the first case, we need to get all the contracts that we are allowed to see. the security rules above are really simple, mind. but trying to translate them into an efficient query is going to be pretty hard. both in terms of the code requires and the cost to actually perform the query on the server. there are other things that are involved as well, such as paging and sorting in such an environment.  i have created several such systems in the past, rhino security is probably the most well known of them, and it gets really hard to optimize things and make sure that everything works when you start getting more complex security rules (especially when you have a user editable security system, which is a common request).

the second case is cheaper because we can limit the choices that we see in the query itself. we may still need to apply security concerns, but those goes through the query directly, rather than a security sub system. this kind of change usually force people to be more explicit in what they want, and it result in a system that tends to be simpler. the security rules aren’t just something arbitrary that can be defined, they are actually visible on the screen (my contracts, drafts, etc). changing them isn’t something that is done on an administrator’s whim.

yes, this is a way to manage the client and their expectations, but that is important . but what about the complex security that they want?

that might still be there, certainly, but that would be active mostly for operations (stuff that happen on a single entity), not on things that happen over all entities. it is drastically easier to make a single entity security decisions work efficiently than make it work over the whole set inside the database.