Enterprises that build complex applications using multiple codebases need to make sure the right people or services can only access what they need without a slew of difficult to maintain code buried in the application. Nor do they want to manage a cumbersome and manual way of tracking the changes in access logic. The rules around this logic regularly change, new features, regulations and so on, so rebuilding the code, essentially reinventing permissions is not a reliable nor scalable approach for good cybersecurity.
Emre Baran, CEO, Cerbos.
Code-based solutions can be customized to fit the needs of the business, but they can be difficult to learn and time-consuming to maintain. The right authorization model for an enterprise will vary based on the size of the organization and the type of application being used, but all enterprises need to ensure that their chosen solution is able to scale as the business grows.
Enterprises will often choose to design an authorization model that is closely tied with their own hierarchy, with users and permissions mirroring the structure of the enterprise. In the short term this is effective but, in the case of change in hierarchy, this lack of flexibility can often lead to the model needing to be redesigned and reimplemented, which is both costly and time-consuming. Instead it can be beneficial for an enterprise to implement key modelling concepts that meet the requirements, but aren’t tied to, existing governance models and internal policies. There are two popular design concepts that organizations could choose from; Role-Based Access Control and Attribute-Based Access Control.
Role-based access control
With Role-Based Access Control (RBAC), access is defined in terms of roles, each role containing a specific set of entitlements and capabilities. This makes it easy to add and remove users from roles as needed, without having to individually adjust permissions for each user. Roles can be viewed as filters; for example an Accounts Receivable role will have access to accounts receivable tools and data, while an Accounts Payable role will not. The RBAC model has two different approaches; core and hierarchical.
Core role-based access control
Core RBAC is controlled by a specified administrator, who is responsible for defining users, roles, and permissions for Zero-Trust Network Access (ZTNA). Users with common characteristics are grouped and then assigned a role, which comes with a specific set of permissions. Users are then allowed to perform a specific set of tasks within this role.
In a model-driven design, a database is used to depict roles, permissions, users, and their related associations. It stores entities, and can assign permissions based on their relationship within the authorization model. Enterprises may also opt to use a third-party application such as Active Directory, or Auth0 for authentication and authorization.
Hierarchical role-based access control
A hierarchical RBAC can be a helpful tool for managing access to different departments or business units. It can help to eliminate redundancies that might be caused by role overlap, and it can also help to define the structure of the organization. In addition, a hierarchical RBAC reflects the authority level of the organization; ensuring that the higher the rank of the user in the organization, the higher the access privilege in the system. It’s an extremely useful model to use when a parent role has many child roles.
A model-driven design can also be used in hierarchical RBAC; either by creating a new column named “Parent” in a roles table to derive a parent-child relationship, or creating a mapping table which stores the parent-child relationship within that. The latter is the more scalable option and offers more flexibility and fewer issues in managing data.
An enterprise could also integrate a tech stack (third-party tools) to implement RBAC in their code. These include annotation-based permissions such as Spring Security, or Cerbos, which is a plug-and-play tool that offers open-source access control across multiple departments and hierarchies.
Attribute-Based Access Control
Attribute-based access control (ABAC) is a more flexible access model that provides dynamic security rules applied to object attributes. It is more complex, but allows organizations to introduce useful measures such as location-specific rules. Authorization is granted in real-time, and every attribute in ABAC is an individual entity and consists of a key-value pair which is dynamic and can be changed to mirror the flexibility of an enterprise.
ABAC is communicated using Policy-Based Language (PCL), which is built on natural language policy. There are four building blocks of PCL, one being the “subject”, which is the active entity and has permissions to perform an “action” on an “object” (two other building blocks). These three components form an access decision, and the “qualifying phrase”, the final building block which includes time or location information, is often used to further influence the decision.
An enterprise can again integrate a tech stack to design a policy-based language. JBoss XACML and Spring Security’s XACML both use eXtensible Access Control Markup Language to define and evaluate policies. Cerbos, which is an open-source access control that provides context-aware authorization, allows an enterprise to model fine-grained access permissions.
RBAC or ABAC?
Role-Based Access Control is ideal for small-to-medium enterprises that have well-defined groups. It takes less processing time and resources to implement, and is a good choice if the budget is limited. Attribute-Based Access Control provides much more flexibility but is resource-heavy and time-intensive to start with. It is the preferred approach for those enterprises that need more granularity and faster provisioning for permissions, or those that operate over multiple locations, time zones and security clearance levels.
Regardless of choice, it is important that an enterprise designs an authorization model that integrates easily into existing systems, and offers the scalability and flexibility to adapt and grow with the organization.
