With more and more companies exposing their data and functionality to the public, it becomes increasingly important to ensure that only authorized users have access to sensitive information. Some of the security measures that can be implemented to safeguard APIs against unwanted access are authentication and authorization schemes.

While the primary focus of RBAC permissions is the user, the primary focus for PBAC permissions is the resource.

In a policy-based access control scheme, security is enforced by defining a set of policies that determine who is allowed to access which resources. These policies can be based on the identity of the user, the type of request, or other factors.

One advantage of using policy-based access control is that it can be used to enforce security at different levels. For example, policies can be defined to allow only certain users to access sensitive data, or to allow only certain types of requests to be processed. This flexibility can be helpful in meeting the security requirements of different organizations.

Three types of Access Control

‍

ACLs

Access Control Lists (ACLs) are a  type of security measure that can be used to restrict access to resources. ACLs can be used to specify which users are allowed to access which resources, and can also be used to specify the level of access that each user has.

ACLs are typically implemented as a list of entries, each of which specifies a user and the level of access that the user has to a particular resource.

One advantage of using ACLs is that they can be used to implement security at different levels. For example, an ACL can be used to allow only certain users to access sensitive data, or to allow only certain types of requests to be processed.

But ACLs become exponentially complex and difficult to manage as the number of users and resources grows. Each data type must have a rule written for who can access it and in what context.

Pros:

• Can be used to restrict access to resources.
• Can be used to specify which users are allowed to access which resources.
• Can be used to specify the level of access that each user has.

Cons:

• Becomes exponentially complex and difficult to manage as the number of users and resources grows.
• Each data type must have a rule written for who can access it and in what context.

‍

RBAC

In RBAC (Role-based access control), security is based on the roles that users are assigned.

For example, a user in the role of “administrator” might be allowed to access all resources, while a user in the role of “guest” might only be allowed to access certain resources.

Role-based Access Control (RBAC) is a static form of authorization that exponentially grows in complexity as user management grows. Static means that once a user is added to a role they retain those permissions until an administrator manually changes them.

This authorization scheme can become complex and difficult to manage as the number of users and roles increases. It also leaves a gap in security for a user to have access to data attributed to a role they should not have.

Pros:

• Fast and simple to setup
• Permissions are managed at the role level, so it is easy to understand what a user can access.

Cons:

• Grows exponentially in complexity as the number of users and roles increases.
• Leaves a security gap for users who have access to data attributed to a role they should not have.

‍

PBAC

In Policy-based access control (PBAC), sometimes referred to as attribute-based access control (ABAC), security is based on the attributes of users, rather than on roles.

Attributes can include things like the user’s location, the time of day, or the type of device that they are using.

Policy-based access control is a more flexible security scheme than role-based access control and can be easier to manage in large systems. Policy-based Access Control (PBAC) enables you to quickly make user-wide changes to match new policies or regulations without the need to audit each role throughout the user base.

It is important to note that PBAC is not a replacement for ACLs or RBAC. Rather, it is a complement to these security schemes. When used together, these security schemes can provide a more comprehensive security solution.

By defining policies that restrict access to resources, organizations can help ensure that only authorized users are able to access sensitive information.

Pros:

• More flexible security scheme than role-based access control
• Can be easier to manage in large systems
• Complement to ACLs and RBAC.

Cons:

• Not a replacement for ACLs or RBAC
• Requires careful planning and execution to be effective.

‍

The Devii Authorization Engine

Policies in PBAC systems are often expressed in the form of “if… then…” statements.

For example, a policy might state that “if the user is located in the United States, then they are allowed to access the resource.”

Devii takes it one step further with default deny. In Default Deny security, all access to resources is denied by default, unless it is specifically allowed by a policy.

This security principle can help to prevent unauthorized access to resources, even if there are gaps in the security policy.

The Devii Authorization Engine can be used to enforce policies at the individual user level, or at the group level.

When used at the individual user level, the Devii Authorization Engine can help to ensure that only authorized users are able to access sensitive information.

When used at the group level, the Devii Authorization Engine can help to ensure that groups of users are only able to access resources that they are allowed to access, based on the security policies that have been defined for the group.

The Devii Authorization Engine is a flexible and extensible security solution that can be used to enforce policies in a variety of different environments.

Gain peace of mind that assets cannot be compromised and regulations are met. Using PBAC to govern authorization empowers you to know that your data is securely used and controlled.

For more information about the Devii Authorization Engine, please contact us or book a demo.