Role Explosion
21 Sep 2010
Everybody knows RBAC, the Role-Based Access Control. The principle is simple, the theory behind it seems to be sound and it is very popular. The problem is that is does not scale. RBAC is fine for few tens of roles. But as the number of connected systems grow, the number of roles grows as well. Organization with thousand employees can easily end up with few of thousands of roles. The difficult problem of managing thousand employees will be transformed to even more difficult problem of managing few thousands of roles.
The reasons are quite understandable but they are far from being obvious:
- Cartesian product: Let's have roles for bank teller, supervisor and branch director. Let's operate in London, Berlin and Bratislava. We need a role for "teller in London", "teller in Berlin", ... 9 roles total. The number of roles grows very quickly.
- Atomization: This can be sometimes avoided by decomposing roles to re-usable re-combinable units. Combine them to a "higher-order" roles using role hierarchy. This gives us 6 roles instead of 9. Unless the teller shares part of the access rights with janitor. Then we need "basic branch office access" role, "teller's IT access" role and a "teller" role that combines these two. Now we have 8 roles. The number of roles still grows quite quickly.
- Uniqueness: Many employees have one-of-a-kind set of access rights. Any attempt to fit them into the roles will inevitably result in a number of roles that is equal or greater than the number of such employees. This is quite pointless.
Static RBAC model usually cannot be used to efficiently handle role explosion. There are some solutions, but none of it is a panacea:
- ABAC - Attribute-Based Access Control. This seems to be a new buzzword. The principle is that instead of having roles there is a expression that computes access rights. The expression takes user attributes as parameters. It seems to be very flexible. But it is a new concept and has yet to be proven. Also, it replaces formal structure of roles with logic. That smells of programming instead of configuration. ABAC may solve the problem of role management, but does it also solve the generic problem of policy complexity and management?
- RBAC, but forget about least privilege. Create "bigger" roles than what would the principle of least privilege dictate. Roles that allow much more than they should. This will improve role re-use and keep the number of roles manageable. It is less secure, but may be good for some environments.
- Spice up roles with some logic. That usually means adding rules to make roles more generic without sacrificing security. E.g. instead of creating "teller in London" create a parametric role "teller" that takes locality from user profile as a parameter and computes the path to the home directory. This is somewhere between ABAC and static RBAC. It has good features from both approaches and seems to be the most popular choice for provisioning systems. But does it really solves the problems? Nobody seems to know for sure.
- Manage the chaos. Let user's request access rights, let others to approve it. The obvious problem is how to revoke the unneeded rights. There needs to be yet another process to review and revoke them, usually called attestation. It is a good for CYA strategy, as there is always someone who have approved what he shouldn't. But is it really secure? The approvals are often done by "I just look at it and if it seems OK I approve". Especially if someone has to approve hundreds of requests each day.
Practical enterprise IDM solution will most likely need all of these mechanisms, not just one. And especially a good, experienced team of people using these mechanism. Because every IDM deployment is different and one size does not fits all.