More on Context Based Access Control

So I have been doing some thinking about how a good way to implement a context based access control system might look. The one thing that keeps breaking interface is how exactly does one define a context in terms of code. Then it came to me, what if context was not defined in terms of code at all, but was defined in terms of a natural parsable language?

Let's start at the beginning, first let's talk about what the interface for this CBAC might look like. Since my last post on this subject used java, I will continue with that language:

public interface AccessController {
   boolean hasAccess( User u, Request request, Context ctx );

Pretty simple interface I would say. And pretty self explanatory to boot. Now, to define the parameters. User is obvious, this is the user making the request. Request is the request itself and the pertinent details of the request. Context is the tricky one to define here, but perhaps the interface will make things a little clearer.

public interface Request {
   String getAction();
   Object getParameter(String key);

public interface Context {
   T getSubject();
   void setSubject(T);
   User getRequestOnBehalfOf();
   void setRequestOnBehalfOf(User u);

The Subject is a generic reference to the subject of the request. For example, the subject could be a Customer record or a MenuItem on the UI. You'll notice that I have also introduced the idea of performing actions on behalf of another user. This is something that I think is lacking from most AC implementations, and is something that is very important. To illlustrate let's take the example of a Medical Records System in a hospital. HIPAA places strict rules on who has access to a patients medical records. Although I am not 100% up on what all the rules around this are, let's say for example that only Patients and their physicians (any physicians that have seen the patient and thus added records) shall have access to that patients records. This is fine and great, but when a patient walks into the medical records department and wants their records, should we just have them sit down at the desk and fetch them by themselves? This is probably less than ideal. A Medical Records employee will probably need to get those records on behalf of the patient. Now, the flipside is that we don't really want to allow any old MedRecs employee to be able to pull up all the information about any patient at any time they want. So really what we need is a 2-tier access control check that not only checks the requesting employee is in medical records, and that the request is made on behalf of the patient; we also want to verify that the patient has indeed approved the request for the employee to access their records. So, perhaps there is an approval code, for simplicity sake, we will say it is the last 4 digits of the patients SSN, and for the Medical Records employee to access that patients records, the patient will have to authorize the transaction by entering the last 4 of their SSN on a keypad on the counter.

I dare you to show me a RBAC system that solves that problem. :)

This is where we get into the rules part of the system. This is the part that I am most excited about, as not only is it the most complex part of the system, but the answer is so simple. Let's dive right into it:

   # The requesting user is one of the patients physicians
   User in Patient(Physicians) OR
   # The requesting user is the patient logged into the web access system
   User is Patient OR
   # User is a MedRecs employee on behalf of the patient with patient authorization
   (User on behalf of Patient AND User in Role(MedRecs) and Request(AuthCode) is Patient(AuthCode))

Kinda pretty isn't it?

While this is by no means the complete solution, I feel like it has promise as a system that is not overly complex to implement but allows the flexibility that a true CBAC needs to allow.

I would love to hear your thoughts on the subject, so share!

No comments:

Post a Comment