Keep your application secure

Choosing the best access control strategy

Warren Parad

Published on September 12, 2020

Implementing data security within application can be done with various access control strategies. The access control determines if a given user is allowed to perform a particular action on a requested resource. Do they have access to see the data, make updates, or delete it? The answer to that lies within your access control policies. There are different ways to implement security each with its own benefits and detractors. Finding the right one for your application can be the difference between happy users with secure, private data, and a disastrous data breach.

Depending on the types of applications or services your product has, different models may be more or less viable. Below I’ll discuss the prominent types as well as their benefits and detractors. For each of these it helps to have a concrete situation in mind. While it may not completely mirror your use case, an example better shows the difference.

For our example we’ll use a document repository. There are many documents. Each document can have any number of users and each of those users may have different permissions to that document. Users will share documents and change other users’ permissions as well as create, modify, and delete documents. We’ll assume there are two services, one that stores text documents and another than stores complex binary data, text and binary.

Inline access policy (IAP)

Extensible: 👎 Implementation:

With IAP, we’ll be storing the list of users and their permissions with the document. That means when creating a text document, the list is saved in the text document, and when creating a binary document, the list is saved in the binary document. Each service validates access and permissions to its own documents. IAP is access controlled architecture where the access policies are persisted with the document themselves. This is a very simple approach that allows for quick implementation at the cost of flexibility and scale. In the case a third type of document repository service is created, it is free to implement access control how it makes sense for those documents



Role-based access control (RBAC)

Extensible: 🤷 Implementation:

Role-based access control separates the responsibility of permissions from the documents. Roles are created and assigned to users. These assignments are stored in a separate service, so that any document application or service can access the role data. Checking user roles requires either your document service to make an api call to the role service or the list of roles is exposed via the user’s authentication token. Because the roles apply to the user only, permissions to individual documents do not exist in this paradigm. A user has access to all documents of type X or none of them at all.



Access control lists (ACL)

Extensible: 👎 Implementation:

Access-Controlled lists flip responsibility around work from the document-first perspective. On a document you define an ACL (which can inherit lists from other places) which specifically allow/deny user actions on the document. Because these only apply to the document, it has the opposite problems from RBAC, most notably lack of understanding of what documents a user has access to. Given the lack of complexity and the fact all the policy has to be applied to the document in one place. The flexibility is extremely lacking.



Attribute-based access control (ABAC)

Extensible 👍 Implementation:

Attribute-based access control removes the notions of roles and documents as far as access is concerned. Instead we’ll completely rely on attributes attached to the user and the document. Permission is granted if all the document & user attributes evaluated result in a success. In practice this means converting every authorization request to a user attribute list combined with a document attribute list and then using a policy evaluator. This offers advantages over the native RBAC paradigm, and improvements over ACLs.



Granular Role-based access control (gRBAC)

Extensible: 👍 Implementation:

Granular RBAC removes all the restrictions applied above by creating distributed access policies. Fundamentally this is similar to RBAC, but the key difference is the scale and granularity for which it applies. Policies are stored separately from users, documents, and roles, and instead link all three. A policy contains one or more users, one or more roles, and one or more documents. This triad of responsibility combines the benefits of the other strategies by focusing on access control as a first class notion.




There are many strategies to implement access control for documents, and already we see some of them lack the flexibility to scale with changes to our document repository. Documents aren’t even that challenging of a concept, so with more complex resources, finding the right fit for your product becomes even more important. Pick the one that best resembles the future possible access patterns for your product resources.

And while there are caveats to each of these strategies, you can add functionality on top to help compensate for what they are lacking. For example moving RBAC away from the authentication identity provider to a separate service. This better resembles how the other strategies work, but starts to lose the benefits that RBAC had provided. Fundamentally, these changes to the paradigms to improve them, makes them something different, and rather than attempting to patch a system that doesn’t fit, it may be better to pick a better access strategy.

Since you're here, check out what Authress is all about!

Enjoyed reading this article? There's more in our Knowledge Base.