Designing an authorization model for an enterprise

An authorization model plays a vital role in securing an enterprise’s sensitive data. Businesses often code additional custom logic on top of traditional access control solutions, like Active Directory. However, as businesses grow, they need an access control that can scale to match their growth.

In this article, you’ll learn about various design approaches for enterprise authorization models.

What is an authorization model

Authorization models usually manage user access and are based on departmental structures, hierarchies, and employee work roles. There are two important aspects of authorization models: decision and enforcement.

• Decision evaluates whether a user is allowed to perform a particular action on a resource. For example, a user request evaluation generates either an allowed or denied decision.
• Enforcement defines the progression of the request based on the decision. For example, what the user should be presented with when a request is denied or approved.

In the absence of an authorization model, administrators struggle with defining permissions. There could be a lot of random requests involved in managing access control, which can quickly become a cumbersome task. However, authorization models provide a structure and hierarchy, securing your application and improving the user experience.

Designing an authorization model

When designing an authorization model, one of the key factors to consider is that it should not be a replica of your department or functional hierarchy. This might work for some businesses but is not practical for all. As your organization grows, your hierarchies will evolve and access control will have to progress on the basis of these new and changed hierarchies in your organization. If your model is tightly coupled with your organization’s hierarchy, then redesigning and reimplementation will be necessary.

Rather, one of the best ways to get started is to look at your existing governance models and internal policies. Take a look at some key modeling concepts:

Role-based access control

Role-based access control (RBAC) defines access in the form of roles and their associated tasks. A role is a set of entitlements and capabilities that define what a user can do. You can think of roles like filters: you add users to roles to apply permissions. For example, an Accounts Receivable role will have access to accounts receivable tools and data, while an Accounts Payable role will not.

There are two approaches in which you can model RBAC: core or hierarchical.

Core RBAC

Core RBAC is designed by defining roles—groups of users with common characteristics. It designates specific tasks for each user-defined role, allowing users to perform different tasks based on their assigned role(s). A specified administrator is responsible for defining users, roles, and permissions.

In the figure above, you can see that an admin manages your system. They create users, roles, and permissions; and define user role mapping and authority levels for roles. These associations define what a user can access in your system.

Model-driven design

In a model-driven design, you can use database entities to depict roles, permissions, users, and their related associations.

In the figure above, you can see that the major entities participating in the RBAC modeling include the following:

• User stores user information
• Role stores role-related information
• UserRole stores user role mapping
• Permission stores the actions and resources on which the action can be performed
• RolePermission stores the association of each role to its associated permission(s)

These entity relationships can be transformed into table structures. In the diagram below, you can see the table structures derived from the relationships:

Active Directory

Active Directory (AD) is a directory service provided by Microsoft for Windows domain networks. Some enterprises use AD for authentication. In this case, your authorization model should integrate with AD for authorization. Third-party libraries, like Oracle Fusion and Dynamicweb, can let you use AD for authentication and authorization.

Auth0

Auth0 is an authentication and authorization platform. It is easy to implement and provides support for RBAC. There are two ways in which you can implement RBAC using Auth0: Authorization Core and Authorization Extension.

Authorization Core and Authorization Extension both have unique features for implementing RBAC. Authorization Core allows you to define RBAC for your APIs. The new core RBAC implementation of Auth0 improves performance and scalability. Authorization Extension lets you define authorization using groups, roles, and permissions.

Hierarchical RBAC

When a role has many child roles that perform activities, then you would use hierarchical RBAC. A hierarchical RBAC helps you manage access and permissions to the different departments or business units, along with eliminating redundancies that could be caused by role overlap. It helps in defining the structure of the organization and reflects its authority level.

For example, in your organization, say you have an Accounts Payable department. The director of this department reports to the VP of Finance. The department also has other employees who report to the director. In the diagram below, you can see many activities that can be handled by different child roles in the department:

The hierarchy of an Accounts Payable department defines that a director of accounts payable should have access permissions exclusive for theDirector - Accounts Payable role as well as permissions across the child roles. In other words, all the child roles defined for the Accounts Payable department will be a subset of the parent role. Thus, a hierarchical RBAC ensures that the higher the rank of the user in the organization, the higher the access privilege in the system.

Model-driven design

You can also use a model-driven design for a hierarchical RBAC. There are two approaches to model a parent and child relationship between roles:

• You can add a new column named “Parent” in a roles table. It will be recursively associated to derive a parent and child relationship. The problem, however, is that with the increase in data, it will take a lot of processing, and managing it will be challenging.
• You can introduce a mapping table that stores the parent and child relationship. This gives you more flexibility and fewer issues in managing data.

In the diagram above, you can see a new mapping table to store parent-child association.

Tech stack

You can use annotation-based or other third-party tools to implement RBAC in your code.

Annotation-based permissions

Spring Security provides out-of-the-box annotations, like @RolesAllowed and @Secured. You can use them at the method level to determine which role has permissions to execute the methods. You can also supply a comma-separated list of roles to these annotations. The annotation ensures that users with any one or all the listed roles can execute the method.

@Secured("ROLE\\\_REPORT\\\_VIEWER")
public String getReport(String reportName) {
  //method body
}

@RolesAllowed({ "ROLE\\\_REPORT\\\_VIEWER", "ROLE\\\_REPORT\\\_EDITOR" })
public boolean isValidUser(String username) {
  //method body
}

Notice that in the code snippet above, the users having the role of eitherReport Viewer or Report Editor—or both of these roles together—can execute theisValidUser() method. However, users with theReport Editor role alone cannot execute the methodgetReport(String reportName), as this access is only provided to the Report Viewer role. A detailed list of annotations is available here.

OAuth

OAuth uses scope as a mechanism to restrict or grant access. A scope defines the resources an app is requesting and the operations it can perform on it. For example, your Facebook profile is an app that can request to post on your wall.

Cerbos

[Cerbos] (https://www.cerbos.dev/) Cerbos makes fine-grained access controls easy to implement and manage, making authorization more secure and more adaptable to changing requirements, while saving months of developer time. This enterprise-ready plug-and-play tool can manage your multidepartment communications and multilayer hierarchies with seamless integration.

Attribute-based access control

Attribute-based access control (ABAC) is an advanced access model that provides dynamic security rules applied to object attributes. In a more complex scenario, when you want to apply time slice or location-specific rules, you would use ABAC. For example, this would be useful if your organization has many departments, such as HR, sales, and marketing, and each has location-specific rules.

ABAC provides dynamic authorization in real time using attribute-based rules and policies. To change rules, you have to change the attribute values, which allows for a fair amount of flexibility.

In the figure above, you can see that every entity has attributes, be it user, resource, or department.

Every attribute in ABAC serves as an individual entity and consists of a key-value pair. For example, you would represent a user attribute name like this: Name (Key) = John Bright (Value).

ABAC is built on natural language policy (NLP), which uses human-understandable language to form policies or rules.

Policy-based language

There are four building blocks of a policy-based language: subject, action, object, and qualifying phrase.

An access decision is made when a policy is evaluated. An active entity called subject has permissions to perform an action on an object. These three components form basic noun phrases that describe an access decision. The fourth component, the qualifying phrase, includes time or location information and is often used to influence the decision.

Policy processing

In the figure below, you can see that the policy enforcement point (PEP) intercepts a user request and then redirects the request to a policy decision point (PDP). PDP generates a denial or an access approval response based on evaluation against configured policies.

Policy statement

A policy statement describes the rules applied on a resource when access is requested. ABAC helps you establish smooth interdepartmental authorizations by using policy statements.

For example, in your organization, there may be departments, like Sales, Payroll, and HR. Administrators of the Payroll department need access to the attendance reports for calculating the salaries of employees. Also, since your Payroll department is located in California, you also want to ensure that the attendance reports are only accessible in the California region.

For the above scenario, your policy statement can be configured like this: “All administrators of the Payroll department from the California region should have read access to attendance reports.”

This policy statement can be broken down this way:

• Subject: Payroll (department), Administrator (role)
• Object: Attendance report
• Action: Read
• Qualifying Phrase: California (location)

PDP evaluates the user request against the four parameters. It checks whether the user works in the Payroll department, is located in California, and is requesting read access for the attendance report. If any or all the parameters of the policy statement are not met, PDP denies the request.

Tech stack

You can use any of the following available libraries to design a policy-based language.

JBoss XACML

JBoss XACML is an open-source, API-based policy infrastructure library that uses eXtensible Access Control Markup Language (XACML) to define policies.

Spring Security’s XACML

Spring Security’s XACML uses Spring Expression language to evaluate policies.

Cerbos

Cerbos is an access control solution that provides context-aware authorization and allows you to model fine-grained access permissions.

Comparing RBAC and ABAC

To help you make a well-calculated decision, here is a quick comparison between RBAC and ABAC:

RBAC

• Rules definition in RBAC is simple and takes less processing time and resources.
• Access hierarchies that align with your organizational structure can be created.
• RBAC suffers from a role explosion (adding a lot of roles to add granularity). If you can avoid this, then it is a low-cost implementation.

When to use RBAC

• RBAC is ideal for a small-to-medium-sized organization.
• It also works well with organizations that have well-defined groups.
• RBAC is a good choice if you have limited time and resources or are running on a limited budget.

ABAC

• ABAC provides fine-grained access control and a targeted approach to security.
• You can easily add or revoke access for resources, entities, and members.
• ABAC is hard to implement, though highly flexible, and is time-consuming and resource-intensive.

When to use ABAC

• ABAC is ideal when you have ample time, resources, and budget.
• It also works well with organizations that have a team distributed across geographies.
• You also need authorization models to define rules based on location or time zone.

Conclusion

Enterprise authorization models play a pivotal role in securing enterprise applications. They ensure separation of work with secured access. Thus, it becomes important that you design a model that blends in your system. That is, it must integrate with existing systems and work well across different departments.

In addition to other third-party libraries, like JBoss, Auth0, and Spring, another library to consider is Cerbos. This open-source, cloud-native, and context-aware access control allows you to focus on building a robust authorization model with a shorter turnaround time. Even though enterprises are large and can have complex requirements, a solution like Cerbos makes access control simpler.