Notes on Designing an Admission Control System

An admission control system takes care of two parts: action and resource. As a concrete example, let’s assume you are a sales manager. A typical business is viewing the orders made by all sales man in your group. Here, viewing the orders is the “action” part, while the orders made by your group is the “resource” part.

Given a user account, an admission control system tells which actions the user could take on which resources. For a website, the action is usually represented with a URI. For instance,

1
2
3
"/orders/view" -> view the orders
"/user/delete" -> delete a user
"/user/update" -> update a user's profile

A typical way of managing the actions is through a layered representation of users, roles, and permissions. A user belongs to a role, and a role is composed of a set of permissions. Each permission is linked to a URI for instance. For convenience reasons, people usually add additional layers to the three-layer structure. For example, a “permission group” layer makes it easier for the manager to assign permissions when the number of permissions is too large.

1
user -> role -> permission

Representing the resource is nontrivial. Before that, you need domain knowledge to understand the structure of the resource. In our example of sales manager, the resource are orders which could be managed in a tree. The manager can see all orders within her subtree, while a sales man cannot see orders from her siblings. In this case, the resource is put into a tree as follows.

1
2
3
4
5
6
7
manager -- sales man 1
|
-- sales man 2
|
-- sales man 3 -- agent 1
|
-- agent 2

You may maintain multiple trees, each for a logic organization. For instance, one tree for sales and another for operators. Each order is linked to a node on the tree. When a action arrives, e.g., “/orders/view/1” where “1” is the order id, we check if the linked node of this order entry in DB. If the node is within the user’s subtree, the admission is granted, otherwise denied.

Last but not least, be sure to use a white list for the super user. In other words, the super user should not go through the admission control system. Otherwise, when the admission control system is down, you can do nothing at all without permission.