« IEEE's Glenn Zorpette Hits Trifecta at ABM Awards | Main | Utah Stories »
Authorization Models and Delegation
I promised yesterday that I’d talk a little more about our discussion on delegation. I’ve since had a profitable discussion with Devlin and Bryant as well.
The problem with delegation is that it requires something that has eluded organizations since computer security first became an issue: how do you build good authorization models? Most applications are built without much prior thought to the authorization model and then it gets slapped on afterwards. For organizations, it’s even worse. The business has fuzzy ideas about authorizations and they change them all the time. “Oh, we’re spending too much money on catering; from now on VP’s have to sign off on all catering requests, in triplicate.”
To see why an authorization model is needed for delegation, consider this scenario. I work at BYU and BYU has, in the name of efficiency, stopped giving out paper paystubs. It’s all online. Also supposed my wife handles the family budget and needs access to the paystub. I always forget to print them out (and besides having everyone print them on expensive laser printers instead of distributing the paper in the first place is lame). I want to authorize my wife to have access to the paystub. I can’t. There’s no way to delegate my authority to see my paystub.
Consequently, I break BYU policy and give my wife my NetID and password so she can impersonate me and see the paystub (at least in this scenario). Of course, because she’s impersonating me, she has all my rights and can also change student grades, update the 401K, and send a nasty note from me to the University president. Now, she wouldn’t do any of those things, but BYU doesn’t care that she wouldn’t, they care that she might. And so, there’s strict policy against sharing NetIDs and passwords, like there is in most organizations.
BYU has set up a situation where their practice (electronic paystubs without a delegation system) sets up situations where people routinely ignore their policy (don’t share NetIDs). Of course, BYU isn’t alone in this folly. Every organization on the planet has these problems and the increased mechanization of formerly people-based processes is only going to exacerbate them.
Solving this problem for this one instance of delegation isn’t all that hard: add a way for me to select any other NetID to also see my paystub. Since almost anyone can get a NetID of their own at BYU (universities are at an advantage here), my wife could get her own NetID and I could select her to see my paystub and the problem is solved.
Solving the problem more globally is much more difficult, nigh unto impossible. After all, I want to delegate all kinds of things: my son to use my bookstore discount, my TA to keep grades, my colleague to update my course calendar when he substitutes for me, my assistant to update my appointment calendar, etc. The list is endless.
You could imagine a bunch of smart people sitting down and coming up with lists of roles, lists of resources, lists of actions on resources, lists of permitted delegations, and then building a big edge-colored, acyclic graph that represents all of this that the various systems on campus could query to get “the answer.” Of maybe you couldn’t imagine that. I can’t. I especially can’t imagine them meeting day after day to update the graph as things change as they inevitably do in a community of 50,000 individuals.
This is the same problem that the Semantic Web faces: endless debates about ontologies. Dave Weinberger, working on his Everything is Miscellaneous book, would probably agree that such a task is hopeless. We’re likely to end up right back where we are now: building one off delegation solutions
Devlin, Bryant, and I were wondering if there are ways to use folksonomies to solve this problem. Is there an analog for authorization that would work in many cases and allow common usage to define the cowpaths? You’d still need to identify resources and actions that need explicit authorization to meet legal and risk requirements, but is that most things or a small subset? I’m not sure.
Posted by windley on March 23, 2007 10:53 AM



Comment from Frederick C. Monson at March 23, 2007 3:47 PM
Every system is designed by someone who will not administer it. Why are we surprised when the limits/rules imposed on use of a system reflect the inability of the administrator to manage its potential? Most CEO's are not able to be more than they can be unless they are willing to take extreme chances with assets and resources. How could one budget for that, and how many are willing to take the chance? The university plumber knows better than to turn off the heat in a building during cold weather, but how many university presidents have demanded fuel savings during Christmas breaks when temperatures fall below freezing. How many university presidents would know that the hot water pipes freeze first? The plumber knows!
Comment from Frederick C. Monson at March 23, 2007 3:48 PM
And, my wife sends me to my printer!
Comment from Eric Norman at March 23, 2007 4:53 PM
I have my favorite scenario that I think exposes some important concepts in the area of delegation. And they aren't just technical; those are probably the least important. I call it "Alice and Bob at the Bar". You can find it at
http://projectliberty.org/index.php/liberty/public_community/forums/concordia_program
Comment from Levi at March 23, 2007 5:02 PM
The erights.org website has a lot of interesting research on authorization modeling.
Leave a comment
I encourage you to leave a comment below. Your email address will not be displayed on Technometria, but allows me to communicate with you directly. Your email address won't be displayed, but will be used to compute a MicroID for your comment.