Choosing the Right Access Control Model

In my previous article, Code security and safety tips when making guidelines, I mentioned that it is very important to give someone access based on the role assigned in your system. I have also mentioned the 3 most widely accepted access control models: Discretionary Access Control (DAC), Mandatory Access Control (MAC), and Permission Based Access Control (PBAC).

Choosing the right access control model for your project/organization is of great importance from a security point of view. With the proper implementation, you can prevent unauthorized access to the resources. Thus, you can prevent possible attacks.

There are more access control models, and I will try to show you their differences. By doing that, I will help you choose the best model for your application. 

How to determine which access control you should give to the user/employee?

First, you would need to identify the person's job. Then you would need to authenticate them by their identification, and then you would need to grant a person access to the hardware/software they need. By doing that, you must ensure they have the right level of permission to the organization's resources to do their job. At this stage, you would need to choose the type of access control model.

Main categorization of access control models

There are 6 main types of access control models:

• Mandatory Access Control (MAC)

• Discretionary Access Control (DAC)

• Role-Based Access Control (RBAC)

• Rule-Based Access Control 

• Attribute-Based Access Control (ABAC)

• Risk-Based Access Control

Mandatory Access Control – This model gives access controls only to the system's owner. The end user doesn't have any rights. The system owner can allow the end user which resources to access. This model has the highest level of restriction compared to the other models.

Because of its restrictive level, this model is used in government facilities and/or the military.

This model is also connected with two security models: Bell-LaPadula and Biba.

Biba allows the user with a lower-level classification to read higher-level info and the user with a higher-level classification to write to lower levels.

Bell-LaPadula allows the user with higher-level classification to write on its level and not on the lower levels, but they can read at lower levels.

If you want to know more about these two security models, check out Bell-LaPadula and Biba video. You can also check out Clark Wilson model, which focuses on upholding integrity.

Discretionary Access Control – This model gives all access controls to the user. It is the opposite compared to the MAC. As you can guess, the implementation of this model can lead to many cyber attacks, so you must be very aware of its flaws if you plan to use it.

Role-Based Access Control – This model gives predefined permissions based on the employee's position. This can be tricky to implement if you need to later modify a person's permissions and provide some specific access to some resource.

Rule-Based Access Control – This model gives access control based on rules. The system administrator manages the rules, checks the boxes, or adds some code to the settings. In the web application, this can be implemented in some settings page where you would have, for example, a list of rules, and by each rule you would have some check box. Depending on which of the rules you will check, you can save it and have the rules list you can use to assign to someone/or some custom role, etc. 

Attribute-Based Access Control – This model is defined by attributes. Attributes are tightly coupled with subject, object, environment, and actions. This means that we would have a lot of variations based on mentioned attributes, which could lead to increased implementation difficulty/complexity.  

Risk-Based Access Control – This model gives access based on risk evaluation. Mainly the profile risk of the user who is going to log in is evaluated. For example, if the user logs in from a different location, the risk is higher, and they will be prompted to further authenticate.

Example of implementation of Role-Based Access Control in the web application

For this example, I am going to use the Angular framework. You will see in the code below that I am checking roles in two cases. The first case is when you navigate to a certain page if the user has access to it, and the second is if the user has access but should be permitted to see a certain part of the page, or they have just read rights but not write... 

Create RoleGuard class that will implement the CanActivate interface. As mentioned on the Angular official site, the canActivate method will return true if the route can be activated. It will give the access and false if the requested route cannot be activated. 

As you can see from the code, in local storage, roles were stored, and in the isRoleAssigned method, it is checked whether the user has the required role from the list of roles in the method's input. If the user has the role, the method will return true, and it will navigate to the required route, and with false, the user will be redirected to the home page, for example (or maybe some custom page).

import {
 ActivatedRouteSnapshot,
 CanActivate,
 Router,
} from "@angular/router";
 
@Injectable()
export class RoleGuard implements CanActivate {
 constructor(
  private route: Router,
  private _localStorage: LocalStorageManager
 ) {
  }
 
 public canActivate(route: ActivatedRouteSnapshot): Observable<boolean> | boolean{
  return this.isRoleAssigned(route.data.roles);
 }
 
 private isRoleAssigned(roles: string[]): boolean {
  let assignedRoles = this._localStorage.retrieveObject(
   this._localStorage.roles
  );
  if (assignedRoles.roles.filter(role => roles.includes(role)).length > 0) {
   return true
  } else {
   this.route.navigateByUrl("home");
   return false
  }
 }
}

In app.routing.ts, import RoleGuard and as you can see, we are sending in the data, which is a list of roles someone needs to have to get to the wanted route.

import { RoleGuard } from "./auth/role.guard";
 
export const routes: Routes = [
…,
 {
  path: "user-statistic-report",
  component: UserStatisticReportComponent,
  data: { title: "User Statistic Report", roles: ["Manager"]},
  canActivate: [AuthGuard, RoleGuard],
 },
…

That part explained the routing part. The code below will present the state of the button based on the role.

So, I have implemented the role service in which I get assigned roles. And I am calling it on the page to check whether the user has the required role. For example, are they a Manager or an Admin.

 get isManagerOrAdmin() {
  return (
   this.roleService.userRoles &&
   (this.roleService.checkRole(Roles.MANAGER) || this.roleService.checkRole(Roles.ADMINISTRATOR))
  );
 }

When the page is initializing, I will call the mentioned method, and based on the outcome, I will enable or disable the button that has the function of saving the report.

 ngOnInit(): void {
  if (!this.isManagerOrAdmin) {
    this._buttons.find(x => x.title === "Save report").display = false
  }
…
 }

Conclusion

Establishing the model you want to use that is the best for your project/organization is very important. For example, a company with smaller applications will easily implement the Discretionary Access Control model. And other companies whose applications contain highly confidential or sensitive information would prefer to use Role-Based Access Control or Mandatory Access Control models.

I would say put everything "on paper" before you choose the right model; All the requirements your project/organization now has and the ones it could have in the future.

Cover photo by Victor Forgacs

#appSec #accessControlModels

Choosing the right access control model for your project/organization is of great importance from a security point of view. There are more access control models, and I will try to show you their differences in this article.