The downside of RBAC.
Most people would agree that role-based access control is a Good Thing, albeit too Holy-Grail-shaped. Roles are a good way of corralling and thinking about permissions, it’s true. The problem is that we tend to use roles a lot, and not in just the prescribed ways.
Identity wonks keep running up against the problem that as individuals, we present different aspects of our PII based upon what role we’re assuming at the time, and only very few people are willing to use a one-size-fits-all, completely real-name set of credentials on the Internet. In real life and in cyberspace (sorry, Myrcurial) we wear a variety of masks based upon the social situation, and we want to retain the freedom to change those masks at any time. As I’ve said before, there are often good reasons for this; it’s not all about deception. I wear a deliberately pure Parent Mask when I deal with my kids’ teachers, because they might react differently to me if they knew where I worked. I use a pseudonym here, because I am most definitely NOT speaking for my employer when I blog, and I don’t want there to be any confusion about it.
So roles can be good. And if you can achieve the utopian state of basing your access controls on roles, so much the better. Except ...
When you assume a role, you’re putting in a layer of separation between yourself as an individual and the entity you’re interacting with. There are times when this can decouple personal responsibility from individual actions. I’m not just talking about the wider freedom of speech that anonymity can afford, but also a loss of personal investment in security. You, as an online user, are going to care a lot more about the security of your online banking account than the security of the account you have to use as an employee (say, to transfer data from your company to a business partner). And the more you are forced into using an online account because of a role you play, the less responsibility you will feel for keeping that account safe.
We run into this all the time in our line of work, because we don’t always have users who are self-selected, net-literate consumers of our online offerings. They’re often people who don’t like computers, and wouldn’t be online at all if they didn’t have to deal with us. So not only do they not care much about the security of the logins we give them, they treat the logins as roles and pass them around their offices like a muddy shovel. “Here, it’s your turn. Go log in and upload what they want.“ In this case, roles work too well—for legal reasons, we want them to be personally liable for their actions under those logins, and yet, because they’re roles, they don’t stick terribly well.
When vendors are pushing multi-factor authentication, they often miss the subtle fact that just adding another factor doesn’t necessarily mean you’re getting any closer to authenticating an individual than you were before. You’re just narrowing the scope of possibilities. It’s true that generally, only one person at a time can hold a token, even if fifteen people in an office know the same login and password. But if you’re trying to enforce personal accountability, adding another factor is not going to do it when the user is deliberately colluding with others. (That sounds too nasty; let’s not say “colluding.“ Let’s say “sharing work-related duties” instead, because that’s really how they see it.)
So as the use of roles increases, and as the distance increases between you and your user (geographically, organizationally and sociologically), the less likely it becomes that your system security will rest in the hands of individuals. The perimeter isn’t just wider; it’s diffused to the point where it really is gone. So much for the C in RBAC.
Posted by shrdlu on Thursday, October 09, 2008(0) Comments • Permalink •
