Thoughts on…

Java Middleware & Systems Management

Authorization Complexities with Hierarchical Models

leave a comment »

It’s too often the case that developers go overboard when deciding how configurable a program should be. The more permutations of possible configurations you have in a system, the more difficult it is to accurately determine what state that system is in.

Sometimes simpler is better. Actually, it quite often is. But let’s, for a second, see what would have happened if RHQ had provided a fine-grained authorization model, one that used a hierarchical permission scheme.

A system like this would have enabled you to grant or deny each of the basic CRUD permissions on each of the resource categories – platforms, servers, and services – separately. The matrix would have been as follows:

  View Create Modify Delete
Platforms        
Servers        
Services        

Unfortunately, there are complications arising from such a solution.

Let’s take the case where you want to delete a resource, say some service. Obviously, you would need delete-permission on services, but it would also indirectly require modify-permission on that resource’s parent (since you’re modifying the children resource list of the parent).

However, since the inventory model was created in such a flexible way, services can be children of platforms, servers, and even other services! So, in order to guarantee that a user can delete any service, the person would need modify-permission across the board. But we’re not done yet. Realize that in order to delete a resource you must first be able to see the resource; so you need to add view-permission on services too.

In the case above, you needed to grant a user five permissions just to implement a single, logical action – deleting a service. What seemed like a great solution to provide fine-grained access control to resources, quickly degraded into a coarse-grained model anyway because of the resources’ hierarchical relationships. Had each resource been an independent, unrelated entity, it would have been possible to grant or deny each of the permissions in the matrix individually.

RHQ, though, has had from the very first design session a rich, hierarchical model for resources. This hierarchy, specifically the parent-child relationships, rather precludes a complex authorization model. Instead, RHQ complements a flexible inventory with a more simplistic authorization scheme.

Global permissions simplify security management in RHQ significantly. It is often the case that you want one or two people to be able to make all sorts of modifications to the resources managed by the product. These administrators should have the right to create, modify, and delete anything in inventory. And so by granting these users a single permission, all of those actions are automatically permitted.

For non-administrators, the RHQ platform supports resource-level permissions. These are the permissions for the people who are going to be using RHQ on a daily basis to manage and monitor the enterprise resources (that the administrators have imported into inventory).

These users are going to want to focus on data that comes out of each of the logical subsystems that RHQ manages: measurement data, results of operations, alerting history, etc. And there exists one resource-level permission for each logical subsystem, which gives these users the ability to see and manipulate the data coming out of that respective subsystem.

So what does this mechanism provide that the fine-grained permission matrix can’t? Well, the two-level authorization scheme is more direct, and simpler to understand. Sure, both solutions can basically provide the same functionality, but the matrix doesn’t map as well (or at all really) to the two major types of users that will consume RHQ on a daily basis, and it requires rather detailed knowledge of how the various permissions relate to the resource hierarchy in order to use them correctly.

Granted, the two-level mechanism isn’t perfect, and there’s probably more than one person out there that has a use case it doesn’t well satisfy…but then again, there are improvements that can be made to any system. So, keep your eyes open for minor enhancements to the authorization scheme for RHQ over time, which will hope to satisfy a wider range of requested functionality.

As always, if you have any suggestions feel free to post to the forums (http://forums.rhq-project.org) and/or just open a new feature request (http://jira.rhq-project.org)

Advertisements

Written by josephmarques

June 19, 2008 at 8:29 pm

Posted in rhq

Tagged with

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: