Background

ArkCase is a framework for developing case management applications.

Data Access Control ensures each user sees only records they are authorized to see, and are prevented from seeing unauthorized records.  Data access control is applied to individual business objects, as opposed to role-based access control, which is only based on the user identity.

Role-based access is usually applied to each URL in a REST-oriented application.  It ensures the user is authorized for that URL; for example, that only document approvers can invoke the “/approveDocument” URL.  But role-based access by itself means any document approver can approve any document.

Spring Security easily integrates with Spring MVC to enable URL-based access control.  How can we easily add the logic to ensure that only Document A’s approver can approve Document A, and only Document B’s approver can approve Document B?  Not to mention ensuring that, until the document is approved, only users involved in the draft and approval process can even see it – so that it does not appear in anyone else’s search results or queries?

Straightforward Custom Applications

If the application is written for a single customer and implements a straightforward process with the same rules for everyone, the easy path is to build these controls into the application code.  Embed the rules in the query logic such that the database only returns appropriate rows; add checks in the document approval logic to ensure the user is on the approver list for that document.

If you design and build this application very carefully, and you understand the customer very well, and their requirements do not change faster than you can update the application; then this approach can work.  I’ve written many such applications and they were very successful; the users were happy, and all was well.

Larger, More Diverse Customers

The larger the customer organization, and the more departments and geographic regions being served, the harder it gets to implement data access logic in code.  I tried this approach for a large government agency where each region had slightly different rules.  The implementation got pretty difficult.  The queries become long, and the results came back much slower; the database isn’t really meant to apply sophisticated access control rules over very large data sets.  Let’s just say the customer was less happy.

Many Different Customers with Different Problem Domains

Let’s just extend the previous scenario to the ArkCase arena, where the framework has to satisfy entirely different customers, each of whom has radically different rules and even different types of business objects.  Now the straightforward approach of implementing access logic in code amounts to a commitment to rewrite the entire application for each customer.  Now my Armedia leadership team (the people who sign my paychecks!) are less happy!

The ArkCase Solution

In ArkCase, we have a flexible solution.  We have a fast way to implement the most common types of rules and we also provide a mechanism to implement more complicated rules.  And we have a fast, reliable way to evaluate the data access controls at runtime.

My next few blog posts will explore this solution in more detail.

In a nutshell, ArkCase requires the results of all data access control rules to be embodied in a database table.  Not the rules themselves; but the results of each rule as applied to each domain/business object.  This table holds all the access rules for each individual domain/business object.  Each domain/business object’s rules are also indexed in the Apache SOLR search engine.  This allows ArkCase to encode the current user’s access rights (group membership and any other access tokens) as a set of boolean restrictions in the SOLR search query.  SOLR is designed to efficiently evaluate multiple boolean search conditions.    This gives us fast search results including only domain/business objects the user is allowed to see.

More to come – stay tuned!