Why Do You Need Context-Aware Permissions?

Before CAP, you could only grant or deny an app permission to a particular resource. If a user wanted the app to access another resource, you would have to grant access even if the user did not need that functionality. But with CAP, you can grant apps permission when certain criteria are met.

For example, a banking app may ask for permission to access a user’s location in order to alert them to nearby ATM locations. However, once the user initiates a transaction from the app, it should no longer be able to access their location because they are using another service. As CAP modeling comes into play, developers and users gain more control over what data is accessed and under what circumstances.

When to Use Context-Aware Permissions

RBAC is an effective means of managing what users can and cannot do across your network. You define roles such as “system administrator” and then specify what each person with that role can do. This defined set of privileges allows users to perform tasks while limiting their ability to view or modify data belonging to other users.

Recently, context-aware access control approaches introduced a way to extend RBAC with specific types of dynamic contextual information. The following are some use cases on when to use CAP modeling.

Anywhere-Anytime Access

The internet has revolutionized the way users access applications, and mobile applications have gained popularity with anywhere-anytime access. Mobile apps should be flexible and allow users to modify how they can use an app based on context. For instance, a user may want to check their account balance on their mobile banking app while they are at a friend’s house, but may not want that information stored on their friend’s computer. CAP modeling allows developers to handle these sensitive data requests in a way that protects users’ privacy and creates a fine-grained permission model.

Saving Data in Trusted Locations

With CAP, users can save sensitive data in locations they trust that are not accessible without their knowledge. For example, an employee might place an invoice spreadsheet in Google Drive so that the finance team can access it from multiple devices. If the employee doesn’t want the file to be accessible from personal devices, Google’s context-aware access allows them to configure a policy such as “Grant access to all employees belonging to Finance Department if using a trusted corporate device from corporate network.”

Distributing Business Functions

Multinational establishments often have business functions spread across different geographical locations, with different teams working on specific aspects of data.

Let’s say a company’s marketing team is based out of London, its legal team resides in New York, and its finance team is based out of Mumbai. The marketing team needs access to their marketing projects, the legal team needs access to documents, and the finance team requires access to employee details. In such scenarios, RBAC will not suffice. The company needs to extend the permission model to include location and time zone information, along with other user attributes, because the company wants to ensure that certain data is accessible only by employees in a particular location.

CAP modeling ensures that people can only access or manage the information they need at a specific location or time of day. This provides an added level of security and ensures that people only get access to data that they actually require, thereby improving data governance without hindering productivity.

To implement CAP in the above scenario, you would define policies for specific locations and time zones. Since the finance team is in Mumbai, access to employee details would only be provided during working hours in Indian Standard Time.

Using Cerbos to Define Context-Aware Permissions

One option for implementing CAP is Cerbos, an open source access control application that provides an out-of-the-box, context-aware authorization model to define fine-grained permissions for your business.

With Cerbos, you can write context-aware access control policies for your resources. Configure your rules in YAML and use the Cerbos API to evaluate policies and make runtime decisions.

Cerbos Policies

Cerbos provides three kinds of policies to define CAP: derived roles, resource policies, and principal policies.

Derived Roles

With traditional RBAC, you define roles like “manager” or “system administrator.” Derived roles are built on top of RBAC and extend it by providing location-specific or time-sensitive attributes.

For example, say you want to provide additional permissions to the head of the finance department in California. You can use the location-specific attribute to tie it up with the “head of department” role and provide special privileges. With Cerbos, you can achieve this by defining derived roles.

To see how this works, go to the Cerbos Playground and make changes to the YAML files.

Resource Policies

Resources also play a role, since you define your permissions based on which resources each role should have access to. In terms of CAP modeling, a resource could be a set of files on the cloud or on a hard drive, or a hard drive itself. You can also use fine-grained permission modeling for code repositories where you would want to define permissions for specific code files or the repository at large.

You can use Cerbos to define coarse- and fine-grained resource policies. For example, say the team working on a security model for a financial institution is located in Sydney, and you want to add location and time zone access to users on that team. You would create a policy for your code files and provide access to users on the security squad, located in Sydney and working in Australian Eastern Daylight Time.

Principal Policies

Principal policies are typically used to override a specific user’s privileges.

Once you define the policies, the Cerbos Policy Decision Point (PDP) evaluates a request based on the metadata supplied in it. Requests for evaluating the policies are sent to PDP through the Cerbos API. Cerbos uses CheckResourceSet, which can be invoked by calling the /api/check API endpoint. This interacts with the policy repository and after evaluation, generates an action response with Allow/Deny. You can check out a sample configuration in the Cerbos Playground.

Cerbos will also update your policy configurations without the need to restart. Just roll out your code changes to production and Cerbos does the rest.

Conclusion

You should now see the benefits of ensuring that sensitive information is only available on certain devices or in certain locations. Some data cannot leave certain networks without encryption, which requires a permission model beyond RBAC. CAP modeling allows an organization to create rules around access that are dynamic and contextual, meaning permissions assigned at one level can automatically change when additional context factors come into play.

If your application can make decisions based on user location, time of day, device type, and connected systems, this increased level of granularity can greatly improve your app’s security. You might be concerned about the complexity of this model or fear that it will affect operations, but Cerbos makes it easy to implement CAP. Learn more about implementing Cerbos.