Authorization Patterns

Real-world systems live somewhere in between a perfect enforcement of least privilege and a system based solely on accountability. As computing and networking technology has matured, a variety of access-control schemes have been developed to try to balance these needs. These schemes represent broad philosophical frameworks that aid the development of access control policies as well as specify implementations for a particular scheme.

In practice, most organizations use a hybrid approach to access control where the resource owner tightly controls certain resources and custodians control other resources. For example, most organizations control access to the HR system in a very formal way, while allowing individual employees to determine who will see documents that they produce within some very broad guidelines.

One of the first organizations to systematically look at access control on computer systems was the Department of Defense. A 1983 Department of Defense publication called the Trusted Computer System Evaluation Criteria (TCSEC), but commonly referred to as "the orange book" because of the color of its cover, defined two modes of access control for the Department of Defense: mandatory access control and discretionary access control. In mandatory access control (MAC), the owner (or the owner's representative) sets the policy, and custodians and users are obligated to follow it. In discretionary access control (DAC), the custodian is left to determine what users will be granted access. Further, once granted access, the user becomes, in effect, a custodian, because a user can grant access to other users.

There has been a significant body of research on military security standards with some important discoveries. One of the most important is an undecidability result that showed that a DAC-based system, judged to be initially safe with respect to some policy, cannot be shown to remain safe over time. User actions may eventually result in an unauthorized user being granted access.

Another important result involves what is known as "tapping-out information." Consider a system where there are two levels of access control: classified and unclassified. In any system with shared resources between access-control levels (e.g., classified and unclassified documents stored on the same filesystem), it is impossible to keep users of classified information from sharing that information with unclassified users. In short, enforcing MAC on a shared system is impossible, because users with access to classified data can always find ways to encode classified information in system resources. Since these resources can be viewed by both sets of users, unclassified users can decode the message and see classified data. For example, if both sets of users can see the filesystem, classified data could be encoded by manipulating the presence of a particular file or even just its size, over time.

These results may seem somewhat esoteric, but taken together, they lead to a fundamental and important conclusion: you cannot build a practical access-control system that does not rely, to some extent, on trusting custodians and users to follow the policies.

Perhaps the best known and most widely used access-control scheme is a user-based permission system made popular by the Unix file permission system. Figure 8-1 shows a schematic representation of how user and group permissions work in this system. The system is conceptually simple: both users and groups have access rights to resources directly and users belong to groups.


As embodied in the Unix filesystem , there are three permission levels: read (r), write (w), and execute (x). These permission levels are applied as attributes of the files and directories on the system. For simplicity, we'll just speak of files here, but the concepts are just as applicable to directories.

Files belong to owners, specific Unix users on the system, and groups, collections of users. Each of these levels can be set for the file's owner, the file's group, and everyone else. So for example, it possible to set permissions on a file so that it is readable and writable by its owner and only readable by its group and not readable by everyone else. Just about any other combination you can imagine is possible as well.

User-based permission systems are fairly simple to use and administer, and they have served nicely for decades. Still, they suffer from several drawbacks:

All of this has combined to cause system designers to search for something more flexible and easier to understand and use.

Access-control lists (ACLs) are an attempt to create a more flexible permissions system that grants individual users access to specific resources. Access-control lists are just exactly what they sound like: lists of specific users and groups who have access to the resource. In filesystems, ACLs are stored as attributes of the files and encompass the standard file-permissions system and expand it to enable specific users or groups to be designated as having a particular level of access.

Figure 8-2 shows a schematic representation of access-control lists. The primary difference between this diagram and Figure 8-1 is the insertion of a permissions structure between the resources and the users and groups. Rather than users and groups being directly associated with a given resource, the resource has a set of permissions that includes both users and groups. This indirection gives ACL-based permission systems additional flexibility at the cost of some additional complexity.


Because ACLs are a recent addition to many operating systems, many tools and applications do not support them fully, if at all. More problematic is the fact that permissions are stored as attributes of the resources and are thus distributed across the filesystem, making managing individual user access difficult. For example, when a user no longer requires access to a set of resources due to a job change or a process change, there is no single place where those permissions can be changed. The resources must be visited one by one, and permissions for that user removed.

Role-based access control (RBAC) is based on the idea that users are typically granted access to resources based on their roles in the organization. Figure 8-3 shows a schematic representation of RBAC.


A key feature of the RBAC model is that all access is through roles. Contrast this with the user-based permission model shown in Figure 8-1. In the RBAC model, some authority, such as the HR department, assigns roles and the resource owner assigns permissions.

A second key feature of RBAC-based authorization is that roles can be hierarchical, as shown in Figure 8-4. If roles are created as shown in this figure, assigning an employee a role as a developer also automatically assigns roles as a member of the engineering department and as an employee. In addition to being hierarchical, roles can be parameterized to aid in role administration.

Role-based authorization schemes are based on three rules:

  • Role assignment. All users of the system are assigned roles; users without roles cannot take any action.

  • Role authentication. Before a user can take on a role, that role must be authenticated for that user.

  • Action authorization. A user can take an action only if that action is authorized for the current, authenticated role of the user.

Role-based authorization is more flexible than an authorization scheme based on simple groups and more secure than one in which users can be authorized independent of their group or role membership. Furthermore, as practiced, role-based authorization makes it relatively easy to add and remove a user's access to resources as his function in an organization changes, even if he changes tasks day to day.