Authorization and Identity Based Access Control

I watched Alan Karp's The Virus Safe Computing Initiative at HP Labs, Mark Miller's Paradigm Regained: Abstraction Mechanisms for Access Control, Tyler Close's Core Patterns for Web Permissions and Mark Stiegler's From Desktops to Donuts: Object-Caps Across Scales which were presented last month at Google's TechTalks. Their presentations motivate authorization based access control (ABAC) by contrasting it with identification based access control (IBAC) whose primary realizations are respectively capabilities and access control lists and by presenting some useful designing patterns including the power box.

Some observations were particularly well articulated. I record them here:

Alan describes the difference between identity and authorization based access control as the difference between the questions: who are you? and are you authorized? The latter generally being the crux of the issue.

IBAC, he says, is a good way to stop users from doing what they are not allowed to do while ABAC stops processes from doing what they are not allowed to do. In other words, in an IBAC system it is difficult to stop a program which acts on your behalf from doing something that you do not want done, e.g. solitaire from sending all of your data over the Internet and then deleting it.

When a program delegates a task to some other program which has authority which that the former does not (e.g. most any client and server interaction), the latter must be very careful in fulfilling the former's request to avoid leaking authority. This is referred to as the confused deputy problem. Alan notes that to avoid this problem on an IBAC system, a program must build its own access control mechanism. On a capability based system, the delegator not only requests the service but provides the authority to the delegate which significantly simplifies the implementation of access control and thereby reduces the chance for confusion.

Alan provides a nice example of why trust should follow delegation. HP had a contract with a copy shop which allowed employees to request print outs, copies, etc. Employees were authorized using IBAC: HP sent a list of employees allowed to use particular services to the copy shop and when an employee requested a service, the copy shop would check if the employee was permitted by consulting the list. The problem is that the list is not static. Employees left, new ones were hired or someone went on vacation for some time and had to delegate his or her responsibilities to someone else. To keep the list up to date, HP periodically sent the copy shop a note with any changes. Someone at the copy shop would synchronize the changes with the master list. The problem with this approach is since trust does not follow delegation, it creates a lot of traffic with the delegator. Taking the person who went of vacation, in oder to delegate his or her responsibilities the person in charge of the access control list at HP had to be consulted. When the person came back, the list had to be updated again. Once the delegator has delegated some authority, the delegator should be remove further decisions. This observation is consistent with the way in which delegation is done is a capability based framework.

Mark Miller describes the difference between permission and authority as the difference between cause and effect (12:00). Permission is what actions are directly allowed, e.g. ,is a program instance permitted to read a particular file? On an ACL architecture, you can answer this question by checking if the principal occurs on the ACL associated with the resource. Authority is the composition of causes: is it possible for the program instance to read the file? The program instance may not have permission to read the file but that does not answer the question: can the program instance read the file? If another program instance which is cooperating with this instance has permission to read the file, then the instance has the authority to read the file even though it does not have permission. Authority is thus the effect brought about by the allowed actions, i.e., the composition of causes.

The permission analysis support the fantasy that I can give Dan permission to read a file; I cannot give Markus permission to read the file and that I've accomplished something by preventing Dan from delegating to Markus the permission to read the file (15:50), i.e. Markus may not have permission but that does not answer the question if he has the authority.

He also discusses one of the problems with naming (23:00): the context in which names are evaluated greatly determines the amount of authority a program requires. He provides the following illustration. Given the command:

cp a b

cp evaluates the strings a and b to locate the associated resource. To do this, cp requires access to the entirety of the user's name space including the ability to read and write any file the user may specify. Contrast this with this command:

cat < a > b

Here, the shell evaluates the names and passes the file descriptors to cat and cat does not require any access to the name space. Although cp and cat both have the same authority, the minimum authority required by cat is significantly less than that required by cp.

He explains how capabilities cannot revoke permission but can revoke access using Redell's caretaker pattern. The idea is to not copy a capability but to interpose a forwarding object and when the delegator wishes to revoke access to the object, it simply destroys the care take object and messages are no longer forwarded.

Delegation is not the problem. The modern world is one of decentralized cooperation between corporations and individuals, he explains, and for that world the primary issue is not to limit delegation but to embrace delegation (44:00). The entire division of labor of the market place is founded on chains of delegations. But we should be working to delegate the least amount of authority. The excess delegated authority is what has created the disaster of computer security as it is today.

Tyler Close likens capabilities to deep linking. ACLs do not allow you to do this: the user must first log in and then traverse the reference graph. The ability to directly name the resources in question facilitates delegation and at its root, collaboration is delegation.

Mark Steigler details the power box mechanisms for authority elevation. Applications started under the principle of least authority may require additional authority in the future. The power box is a mechanism which allows the application to negotiate this request with the user (28:30). Instead of the application having complete access to the user's authority and having the user provide a string to resolve, an application requests an open dialogue box with the user using the power box and it is power box that resolves the string. It then passes the descriptor back to the application. This inverts the normal power relationship and places the user in control instead of the applications.