Security meets Usability: Crafting Dynamic and Granular Access Control Solutions

Hey, everyone. I'm Samhita. I'm a full-stack engineer at BlackRock. And here's a little something about me. Now, if we were doing this session in person, we would have played a quick icebreaker game. I would have bragged about my benching abilities and showed you a lot of memes. But unfortunately, I couldn't join you in Amsterdam this year. So, we'll have to skip all of this and dive right in. Let's get started.

Imagine you're building access control into your web application. So, first question you'd probably ask yourself is, what strategies should I use to make sure that sensitive data is accessed by only those who truly need it? Then you might start thinking. Should I implement it at the component level or the API layer? Or is it safe for the back end to handle it all? Then you might consider another layer of complexity. How do I integrate all of these permissions with business logic checks and feature flags so that certain features are only available to specific users?

By now, I hope you understand that access control is not a single decision and you'd have to think through multiple layers in your architecture in order to get it right. So, in today's session, we'll be going over all of this and explore two ways to implement access control that's granular, dynamic, and scalable. Why should you care about this? OASP has listed broken access control as the number one security risk in web applications. They also recommend attribute-based access control over the traditional role-based access control, which grants access to users only based on the user's roles.

Why? Because attribute-based access control is more effective in implementing the principle of least privilege, and it also handles dynamic access needs. Let's see how. Consider Sam, who is a publisher for a blogging application. When she joined, she was assigned categories within which she can take actions. The access control rule is that publishers can publish approved posts in their assigned categories but only during business hours. Whenever a blog post is created, it is given a category. It is initially unreviewed but gets eventually approved by the editor. Now, if Sam wants to publish this post, access is granted not just based on her role, which is the case with role-based access control, but also based on her attributes, the attributes of the resource, which is the post, and environmental attributes like time and location. These three, along with the access control policies themselves, are the four core components that make up ABAC. If any of her attributes change, like she moves to the membership department or is assigned to fashion, her access is automatically revoked. And because all these attributes are incorporated into the decision-making process, your application's security is much more robust.

Where should you enforce it? You would enforce access control on the front end so that users have instant feedback. They immediately know what they can or cannot do, and this makes for a very intuitive UI. This is a crude example of what it might look like. Apart from the fact that it's an FL-stangle and the solution is not scalable, the problem here is that front-end access control is only the first line of defense. It's like hanging a do not enter sign on your door and not actually locking it. So it's very crucial that you also enforce access control in the back end because front-end access control can be easily bypassed with the right tools. So you might replicate the same rules on the back end. That's a lot of duplication and it's difficult to ensure policy consistency across both the layers, which is why even though your policy enforcement needs to happen on both the front-end and the back-end, the definition of the rules or your permissions themselves need to be on the back-end as a single source of truth. So you may offload your entire access control logic to the back end and have the front end make an API call to the back end and get the access control decision.

This solution is secure, but it introduces trade-offs in terms of usability and performance, especially in ABAC because we saw how it depends on dynamic factors like user, resource, and environmental attributes. And every time these attributes change, your UI needs to trigger an API call to the back end to get the updated access control decision, which causes latency and a laggy user experience. And not to mention, if there are any policy updates or policy additions, your code needs to be rewritten. Also, how would you handle feature flags like premium users or exclusive resources? And what about when there are multiple front ends and multiple back-end services? How would you ensure policy definition consistency across these layers? And more importantly, how do you create a scalable solution that satisfies all the design criteria that we discussed so far? Like I said in the beginning, we'll be going over two solutions. The first one is CASL. It's an open-source JavaScript library which allows you to define permissions in a declarative manner, like what the user can or cannot do instead of worrying about how to check for permissions. Consider these examples from our blogging application. An admin can manage everything. An author can create and edit their own posts within assigned categories, but cannot delete published posts. These are called abilities in CASL.

Let's convert this into code. Let's begin by defining a function called defineAbilityFor, which takes in the user as an input and returns the user's abilities. If the user is an admin, the user can manage all. Manage and all are keywords in CASL where manage means any action and all means any subject. If the user is an author, the user can create a post but cannot delete a post. You can also type check these abilities by defining a type for the actions and subjects and creating an ability object which conforms to the defined types.

Note here that createMongoAbility does not mean that your application has to use MongoDB. It only means that we'll be using certain operators from the MongoDB query language. One such operator is the in operator, which is used to specify conditions on these abilities. For example, the user can create a post in a tech and lifestyle or the user can update only the title and description fields of their own posts which are in draft state. If the description object is nested, you can use a wildcard to state that you only want to grant access to the top-level fields. Finally, you can use cannot to describe what the user cannot do, like deleting published posts.

Behind the scenes in Kazzle, these can rules are combined using logical or and inverted rules, like cannot and all the conditions are going to be combined using logical and, which are the pink boxes that you see. Okay, so remember this, we have the definability for function which returns all the abilities for the user. Because the permission definition needs to be a single source of truth, this is going to be a shared library between the UI and the server. Once the user is authenticated, you would invoke this definability for function and get the user's abilities. To validate an action on the server side, you would do ability.can and pass the action and the subject. The same ability.can function can be used on the front-end to perform programmatic checks and it returns a boolean true or false.

Better yet, create a context and pass the ability instance to the application so that all the components in the app have access to it. Bazel also provides an option to create a contextual can component, which is like a wrapper component around other components that you can use for conditional rendering.

Can I delete a post? Do you see how readable the permission check is? It means that you are asking if you have the permission to delete at least one post. But on the other hand, if you ask, can I delete this post, it means that you are asking if you have the permission to delete that particular instance of the post because post here is the type of the subject. It can be a tad confusing, which brings me to my next point.

Should you be using a third-party library? While they offer a lot of convenience, there are some concerns about using them in enterprise applications, especially for access control and especially in applications that deal with sensitive data. Because the documents could be unclear, outdated or inaccurate. But most importantly, there may be vulnerabilities in the library itself. To have complete control over your security logic, you may want to build your own solution.

How do we write the policies such that it can be used by both the UI and the server? Or that can be used by multiple UIs and multiple servers? To solve this issue when the backend tech stack is not JavaScript-based, policy as code is utilized. This approach involves using code or configuration files like JSON or YAML to define and manage policies. By structuring policies in YAML with conditions for evaluation, you can ensure effective policy management.

Improving the structure of policies involves grouping them by resource and action for better navigation and scalability. The use of Google's common expression language for writing conditions ensures fast and secure policy evaluation. Evaluating conditions is done using CEL evaluators, such as the cell javascript evaluator for front-end applications, to produce Boolean results based on user, resource, and environment data. Storing user details in the global state and fetching policies from a management service are essential for policy evaluation.

Handling contextual business logic alongside permissions is crucial for accurate access control. Dynamic business logic, dependent on the application state, can further restrict actions despite having required permissions. Examples include preventing post approval during editing, disabling actions based on content presence, and enforcing unique constraints like post category names. Balancing dynamic business rules with permission-based access is vital for robust access control implementation.

And even with growing policies, the lookup time is going to remain constant. Now that we have the policies in place, evaluation of conditions is crucial. CEL evaluators are available for different languages, with the cell javascript evaluator used for the front-end. The validator resides in the web app and receives resource and environment attributes from the invoking component.

User details like role and department are stored in the global state for evaluation. Policies are fetched from a management service conditionally using Redux Toolkit or Tanstack Query. Contextual business logic often restricts actions despite having necessary permissions, depending on dynamic application states. Examples include preventing post approval during editing or disabling actions based on content presence.

Contextual business rules are vital for accurate access control alongside permissions. Encapsulating validation logic in a use permission hook allows its use in various components. Changing application states trigger re-computation of validation outputs and re-rendering of components using the hook. Fetching policies conditionally after a valid user ID is present and validating contextual actions are key parts of this process.

You know, so as to avoid unnecessary network requests. And if you're using RTK or Tanstack Query for this, the policies are going to be automatically cached in the store. We will be reading from the store for the purposes of this example, but please be very mindful of storing sensitive user and policy data in the store.

More often than not, even if you have the required permission to perform an action, you may still not be allowed to do so because of contextual business logic. And this business logic may depend on the state of the application and may need to be handled dynamically. Examples would be to prevent the approval of a post if it's currently being edited, to disable the comment button if there's no content typed in the comment box, and to prevent the creation of a post category if the name already exists.

So if a contextual action rule is present, it's going to be evaluated alongside the contextual policy validator. Encapsulate all of this validation logic inside a use permission hook so that it can be used by any component that needs to check for permissions. With changing application state and changing attributes, the hook would recompute the validation output and trigger a re-render in all the components that use it. At a high level, this is what simplified code for that looks like. This is where I'm fetching the policies conditionally after a valid user ID is present. And then here is the validation logic for cell JSC evaluation and contextual action validation. But there is one thing in this code that needs to be rewritten. You see how here I'm using the use selector hook to subscribe to the entire application state. Which means that any state change is going to trigger a re-render in all the components that use the use permission hook. Which is why that's a bad practice and you're supposed to be using your use selector hook to subscribe to only what's necessary. Make it as granular as possible.

Which is why that's a bad practice and you're supposed to be using your use selector hook to subscribe to only what's necessary. Make it as granular as possible.

Okay. Moving on to the last bit, we looked into the definition of permissions using the custom solution. Now let's look into how to enforce these permissions. You can create a can wrapper component inspired by CASL to hide or show a component in this case. To disable a component and then to create a protected route. If the user has permissions, you would show the outlet. If not, navigate to the login page. And finally, to skip an API call if the user doesn't have any permissions.

That was all for today. That wraps up our session. But before I let you go, let's summarize. We learned two ways to enforce fine-grained attribute-based access control. First one using CASL and second one using a custom solution. Both the solutions are scalable in the sense that adding a new policy means updating a single file without any code rewrites. They are dynamic because they work seamlessly with changing application state. They're readable like, can I read a post? Can I delete a post? And finally, they are clean because there's separation of concerns. Hopefully you remember everything from this session. But because it was a lot and if you had to remember just one thing, it would be to consider using OWASP recommended attribute-based access control because it's more effective in implementing the principle of least privilege.