Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Roles, Rules, and Requests
There are three general approaches to setting permissions in an enterprise: role-based, rule-based, and request-based provisioning. In practice, most enterprises are driven to use all three.
Role-based provisioning ties users’ privileges to their jobs. If you’re an accounts receivable clerk, you have one set of permissions; if you’re an engineering team leader, you have another; and so on. Theoretically, this is the cleanest method of provisioning. The problem is that in its pure form it doesn’t work. "I’m not aware of any customer who has done a full role-based provisioning deployment and been happy with it," Aisien says.
Idan Shoham, chief technology officer at M-Tech, puts it more forcefully: "I think the role-based implementation exists only in mythology," he says. "I’m not aware of any successful cases."
"Roles make sense inside a single application," Shoham continues. "But as you add target systems [effectively, applications in this case] and more users, the role engineering product starts to dominate your implementation process. And eventually your whole project crashes and burns."
At the opposite end of the spectrum is request-based provisioning, in which no permissions are granted until the user asks for them. This approach is extremely flexible, but it tends to be frustrating for users, who generally can’t figure out what additional permissions they need until they need them.
The middle ground is what Aisien calls rule-based provisioning, in which users are granted certain bundles of permissions to start with and then can request more. M-Tech’s Shoham refers to this as "painting with a very broad brush. You understand you’re not going to capture all the users’ requirements, just enough to get the user started."