Archive for June 2008
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:
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.
Here’s an interesting use case for DynaGroups.
One customer might have a few dozen/hundred JBoss AS instances, but only a handful of them have a web app deployed called, say, “someapp.war”. They want to know what set of expressions they could use to maintain a group of all appservers that have that webapp deployed.
This wasn’t possible in the 1.0.0 version of the platform, so in the upcoming 1.0.1 release of RHQ you will see DynaGroups support a new “child” expression token. Using it, you can easily satisfy the above use case. The expression set looks like:
resource.type.plugin = JBossAS
resource.type.name = JBossAS Server
resource.child.name.contains = someapp
Up until now, RHQ only supported “resource.parent” and “resource.grandParent” sub-expressions, which meant that you could only traverse up the resource hierarchy. This new expression token really helps to round out hierarchical navigation using expressions, allowing traversal in either direction.
If you have suggestions for other DynaGroups features, don’t hesitate to postback to the RHQ development forums here — http://forums.rhq-project.org/