Roles are turning into the hot topic this year, and with Dave Kearns, Dave Shea, Ed Zhou and Robert Ciampa in just the past couple of weeks, I thought I’d better pitch in with my 2p worth, given this is an area I’ve spent a lot of time thinking about (and writing about [PDF, 260k], I thought I’d write a little more.

When thinking about Roles and how they relate to privileges, I’ve always found it much easier to think of everything as a role. And I do mean everything. A ‘group’ is a role, it just happens to have a lot of other roles attached to it. Specific access privileges (such as being able to print to a specific printer) are also roles.

However perhaps the most critical aspect in this thinking is that there is absolutely no inheritance of permissions at any stage. Whilst there is a convincing simulation of inheritance, at no time does an account derive permission to do something simply because of that account’s location within the hierarchy, or because of membership in a group, where the group has the permissions.

Rather, by converting more traditional Groups to Roles, and explicitly linking a group of individual roles to the Group role, you can simulate groups-based inheritance (everyone who is given the Group role gets all the roles associated with that group) without having to worry about inheritance.

However the key to making this work properly is in having a fully implemented provisioning service which reprovisions all rights, roles, permissions across all provisioned systems every time an account has it’s roles changed. This avoids problems with having to worry about retained rights, inherited rights, or even conflicting rights. To make comment on something Ed Zou said:

A simple change can often have multiple effects. For example, when a person is relocated to east coast should he still be managing the customers at west coast? Should he stay on the revenue processing team? Often time these are managed on separate systems.

If a full roles-based system is implemented, this problem goes away. The person working on the West Coast has a set of West Coast roles. If they move to the East Coast, they get a set of East Coast roles instead of the West Coast roles. If they need access to anything from their old set of roles, these are added separately. The provisioning system then resets all the necessary permissions in whatever systems need to be set. And you’re done.

If you approach Roles in this manner, you can create ‘Role Groups’ that are closely aligned with business requirements or business roles. There is perhaps a greater need for up-front effort in creating all the initial low level roles that provide permissions-based access to various systems, and also require the implementation of fixed procedures for the implementation of new systems so that the relevant low-level roles are created to match the new permissions that need to be provisioned in the new system, but once this is done these roles can be grouped as needed.

By also implementing a ’smart’ provisioning system that can work out if a certain set of permissions has already been provisioned, then there doesn’t need to be uniqueness between role sets either - one instance of a role simply replaces another instance of the same role. You avoid problems with inheritance of permissions, you can change roles as needed, and through automatic reprovisioning, addition or deletion of roles translates almost immediately to a change of permissions.

More later.