Richard Rodger

I promised to make the development of the next Ricebridge product, User Manager, more transparent. So here goes…

User Manager is already in production. It's a fine-grained user access and permissions system. It handles arbitrary permissions for arbitrary business objects and is designed to be extensible.

That's all well and good, but the actual implementation as it stands is pretty specific to the client who contracted the original work. And rightly so.

Here's what we have now:

1. The extension and integration mechanism is via subclassing. Bzzt! Wrong answer. Definitely not the way to go – experience has shown that. In the current version you subclass the RBUser and RBUserManager classes with your own in order to hook up the user management features to your own application. Not really fun at all. Instead I think this should be done via contained classes. So your own User class, be it a POJO or whatever, is referenced inside an integration class, used by User Manager. I'm thinking of calling the integration class something like UserRef, the Ref suffix standing for “reference”.

2. The Naming convention sucks. In order to avoid clashes with implementor subclasses I chose to prefix most of the component classes with the prefix “RB”. It's just ugly. And not really that necessary. A lot of the user management specific classes should have proper names: UserManager, Login, Access etc. If the developer is going to use User Manager then they won't be using these class names anyway. They only big issue is with entity class names: User, Role, Group, etc. Point 1. above suggests a naming convention for them: UserRef, RoleRef, GroupRef, etc. These reference classes hold the actual entity objects, or perhaps even their own suitable references. If you're using old-style EJBs you might need this sort of dereference. I don't know – I've tried to forget most of my EJB knowledge and been largely successful! Urgghh. Shiver.

3. The permissions rules need a bit of redesign. This is quite a biggie and I doubt if this will be the last mention of them. Here's how they work now:
You have a set of Permissions. Each permission is binary. The Permissions are stored as a bit array. Each User has a permission set. So you can load up the permission set for a user and check if a permission bit is set for the permissions you are interested in. The list of permissions is not meant to be really long – maybe 256 at most. They are general things like read, write, save, etc.

Each role also has a set of permissions (there are no groups in the current version). So if you put a user in a role, they get all the permissions of the role. The permissions are just ORed together; they are additive.

The real power comes from the permissions you can assign to arbitrary business objects. These are just identified by a String name. You can assign a set of permissions to a user for a business object. That way you can give fine-grained control of business objects to only certain users.

To look at it another way, the permissions are like verbs, and the business objects are like, well, objects. The user is the subject.

For the original client requirements, we also put in a “domain” system, so that you could have domains as well as business objects. You could assign permissions to domains in the same was as business objects. Thinking about it now, there is no difference between domains and business objects. Domains are business objects. So out they go. We'll keep the idea of business objects of course.

4. Groups are not supported. The current system only uses roles. Is there a difference between groups and roles? Implementation-wise probably not — they are both just things you assign permission sets to. But I think there is a semantic difference. A group can reference a real-world collection — a class of students, a project team, and individual retail unit. It makes no sense to mess up the group just to control permissions. So I think that User Manager will have both roles and groups. Roles are where you put your permissions and groups are where you put your users. Of course, you will still be able to assign permissions to a group — that seems necessary for ease-of-use.

OK. Where do we go from here? Well the new design will look something like this. You have permissions. This are binary values and you get a list of them. Maybe 8, maybe 256, maybe 4096. Whatever. As many as you need, but you'd be nuts to have too many. Remember, it's the business objects where the fine-grained control happens. You also have users. Each user has a permission set. So at the basic level, you could have permission at index 0 as the “login” permission. If this bit is set, the user can login. Just using the User permissions means you can assign broad and general permissions to users – the ability to read everything, save everything, etc. Of course you can get more specific, but that multiplies your permissions and is not such a good idea.

And then you have groups. Just a collection of users. And each group gets a permission set as well. The group permissions are additive — they are added to the existing permissions of the user. Groups are mean to have a semantic referent and are not meant to be used for permission juggling. That's what roles are for. Roles are just the same as groups — you can assign them to users and they have an additive permission set. The only extra thing is that you can also assign them to groups.

So now here's what you have. You can set up your list of users, give them all a base set of permissions. Then you put them in groups, and give the groups some more permissions if that's useful. The group permissions should be fairly stable ones. Then you create some roles with permissions for specific activities. You then assign the roles to your users and groups as required. If you need to make changes, you mess with the roles, not the users and groups. Of course, some changes should happen to users and groups directly, like removing the login permission.

Now we come to business objects. I don't actually like that name. Let's generalise a bit. Let's call them “scopes”. A scope is anything you want it to be — it is just a String reference to something. It might be an individual business entity — a product id or SKU, or it might be a “domain”, some collection of business entities, or it might have some other meaning. That's for the developer to decide. Scopes are the unit of fine-grained access control. You assign permissions to scopes for individual users, groups and roles. So you can say, for instance, that scope “foo” has permission “modify” for users “a”, “b” and “c”.

The scope permissions are also additive. But we can add a twist here as well. After all the additive permissions are resolved for a user in a given scope or scopes, we can allow for negative scope-based permissions. This allows removal of certain privileges without totally shutting users out. This idea is a more experimental one at this stage – we'll have to see how it plays out.

So how do you get the permissions for a user at a given moment? The permissions are a function of: user, roles for the user, groups for the user, roles of the groups for the user, and then all of the scopes that apply to the user and any of the groups and roles for that user. This will have to be coded to avoid performance problems – some sort of caching is in order. Finally negative scopes are applied.

The following database structure encodes some of this design:

Permission: bit-index, name
User: id, username, base_permission_set (byte array)
Role: id, name, base_permission_set (byte array)
Group: id, name, base_permission_set (byte array)
Assign: user, role, group (use any two)
Scope: string-id, user, role, group, permission_set, positive/negative

So to get the roles for a user:
select Role.* from Role, Assign where Role.id = Assign.role and Assign.user = ?

To get groups for a user:
select Group.* from Group, Assign where Group.id = Assign.group and Assign.user = ?

To get roles for a group:
select Role.* from Role, Assign where Role.id = Assign.role and Assign.group = ?

To get all the roles of the groups of a user:
select Role.* from Role, Assign as ar, Assign as ag where Role.id = ar.role and ar.group = ag.group and ag.user = ?

For a given scope, get all the entries from the scope table, and cache them in a hash map. We can then match this against the roles and groups of the current user. Each scope is unlikely to have a high number of entries. If a scope applies to each user say, then it should be a group or a role. The User Manager should provide an easy way to turn a scope into a group or a role in fact.

Alright, that's enough for today.