A top-down approach to role creation

Much of the time what I write is in a vacuum – I only learn about actual usage and implementation from reader responses to a newsletter. Last week’s look at Role-Based Access Control (RBAC) was no different in that regard.

I wrote about adapting the Pareto Principle – the “80-20” rule – to the design of roles by mining your audit logs to find out who is accessing what and creating roles that maximize the number of people in each role (see editorial link below). A number of you wrote in response to that newsletter and, surprisingly, a few of you had each – independently – come up with the same “spin” on this idea. And it doesn’t require digging through reams of audit logs.

Putting together what these folks offered, we can look at the method as a “top-down” approach to role creation.

Remember that “roles” are simply a bundle of rules that apply to the people filling the roles.

The top-down approach starts by defining an “enterprise” role (also called “corporate” role or “organization” role). These are rules that apply to all – or most – of the people in the enterprise. Then come down to the next organization level: division, school, etc. (smaller enterprises will skip this level), and once again define rules that apply to all – or most – of the people in that level. Continue on to the department, class, etc. When you’re done with the organizational approach, start out on the various applications and services that are used and create roles that contain the rules most – or all – users of that app or service need.

This did remind me of how I used to construct “groups” within NetWare back in the days before the directory (the 1980s, for those of you who are counting!), and roles do have a lot in common with groups. If you’re interested in how I see the difference, take a look at “Identification using group membership and roles”: https://www.nwfusion.com/newsletters/dir/2003/0818id1.html. We’d start with the group “Everyone” that was, of course, everyone who accessed the server, then build groups based on department membership, application usage and resource needs. If you’ve administered a server-centric network (NetWare 3 or earlier, Windows NT, most flavors of Unix) then this extrapolation from groups to roles comes fairly easily.

 One difference (arbitrary, perhaps, but important I think) between roles and groups is that groups tend to be static entities, while roles change much more often both in membership as well as in privileges. They are much more dynamic, it would seem. That brings us back to last week’s second newsletter, about the concept of “dynamic communities”. We’ll explore that concept some more in the next issue.