A few weeks ago, Baljinder Wadhwa, a consultant at HP, started an interesting thread on coarse-grained vs. fine-grained access control trying to figure out what the differences were between the two. His question generated a high level of great answers that went in different directions. This post aims at summarizing those answers, bringing in my own view, and producing a structured answer to Baljinder’s question. Here goes…
- Coarse: (1) composed of relatively large parts or particles <coarse sand> (2) : loose or rough in texture <coarse cloth>
- Fine: (1) very thin in gauge or texture
(2) : not coarse <fine sand> (3) : very small (4) : keen <a knife with a fine edge> (5) : very precise or accurate <a fine adjustment> <trying to be too fine with his pitches>
Definitions from the Merriam-Webster
The definitions start to hint at what the differences might be: fine-grained access control will work on smaller items whereas coarse-grained access control will work on larger items.
Granularity can apply to the message being intercepted or the information being considered for access control. Ultimately, the rules being define will allow for more or less granular AC. Examples:
- Coarse: Employees can open the door.
- Fine: Employees based in the US can open or close the door during office hours.
- Finer: Employees in the Engineering department and based in the US can open or close the door during office hours if they are assigned to an active project.
A little history of access control
In application security, there are grossly speaking 3 types of access control:
- Access control lists (ACL): with access control lists, once a user is authenticated, that user is allowed to access an application or not depending on whether that user’s id is on a list of authorized users (white list) or blocked users (black list). This mode is either all-in or all-out. It is extremely coarse-grained from that perspective. It is also coarse-grained in the sense that it only considers one dimension, that of the user, ignoring resources, actions, and context. However, it is extremely fine-grained in the sense that it becomes a user-specific rule. In the previous examples, John is the user id that would be on the ACL for the open door action.
- Role-based access control (RBAC): sometimes, though, it is not who you are but rather what role(s) you embody. For instance, a person might be allowed to open a door. That right (or permission) is granted because that person has the role employee, not because of who they are. Typically, in RBAC, a user can have multiple roles to which different permissions can be granted. Take wordpress for instance, the popular blogging platform. WordPress lets users define roles and associate permissions to roles and then roles to users therefore transitively granting users permissions. But roles have their limits too. How do you express other conditions or parameters? What if you want to express a permission of the following form: “only employees can open the door between 9AM and 5PM”. With RBAC, you can express employee + open door. But you cannot really express the time constraint. In addition, what if you want employees who can only close doors? You would need to define employee_open and a employee_close role. This leads to role explosion.
- Attribute-based access control(ABAC): to address this, one needs to be more discriminate, finer in terms of what information is considered to define a rule. Instead of defining permissions based on roles only, one should be able to use attributes. Attributes are any bit of data, or label, that describes a user, resource, target, object, environment, or action. Anything from an apple, its color, and weight to a person eating that apple, the location of the apple… With ABAC, you can mix and match attributes to define extremely targeted (fine-grained) rules e.g. employees can open the door between 9AM and 10AM or close the door after 5PM if and only if the employee belongs to the ‘door opener’ group.
Standards for access control
In the previous paragraph, we looked at some broadly used and accepted access control models: ACL, RBAC, and ABAC (yes, access control is for acronym lovers). Let’s check out standards that back these models.
- ANSI INCITS 359-2009 RBAC Role-Based Access Control: this standard defines role-based access control and its model.
- XACML: this OASIS-driven standard defines a policy language, request/response protocol, and architecture that implement ABAC.
The NIST has a webpage dedicated to RBAC which summarizes extremely well the different RBAC standards existing and their variations / applicability.
In addition to the ANSI RBAC and the OASIS XACML standards, there are standards for ACL but these tend to be OS-specific.
Of all the standards out there, XACML is the one providing the finest granularity.
Defining access control granularity
The granularity of an access control framework can be defined from two different angles:
- the expressiveness of the grammar used to express access control rules:the more flexible a grammar and the more information it can cater for, the finer grained the resulting access control will be. XACML can consider attributes about users, resources, actions, and the environment. This makes it very fine-grained. RBAC implementations typically focus on the user role and the target application therefore losing a bit of granularity since it won’t be able to make access control decisions based on actions, other subject attributes, or the context.
- the ability of the ‘agents’ to see more or less information: in order to make fine-grained access control decisions, there is a need for agents or interceptors to be able to inspect business messages flowing through them. If, for instance, an agent can only see the URI of an HTTP message and the user principal name, then it can (most likely) only make decisions based on that. On the other hand, if the agent is capable of inspecting the entire message, including all HTTP headers plus the payload of the message, then more fine-grained AC requests can be generated. This is why there are firewalls which typically look at TCP packets, XML gateways which look at SOAP/REST messages, and many other types of gateways / interceptors in between. Interceptors can be business app-specific e.g. interceptors for Sharepoint or SAP which enable fine-grained access control.
In a second instalment, I will focus on the issues of scale around granularity of access control. I will also list some product categories and vendors that address different levels of granularity. Stay tuned!