• Nikhila Jain

How to Design User Role Permission Model?

Updated: Oct 1

With digitization and every small or big business making its online debut, it's necessary that the application access is made seamless for the users. Every user is different and uses your application differently, which calls for a set of permissions or privileges associated with that user. To model these privileges so that every user has a set of defined rules governing their access is done using a user role permission model.


In this post, I am going to walk you through the approaches that you can use to model the user role permission model and choose the one that best suits your needs.


A user access is governed by a login screen that enables user role permission model.
Photo By Danielle Rice on Unsplash

Access Control Process


A process that defines set rules for accessing the particular resource, governed by a fixed set of permissions, by a set of users is defined as a user, role, permission model.

In layman's terms, access control processes are a set of processes defined for users or group of users to enable them to access your application.


Let's look at a use case where there are two users who are accessing your application - Registered User and Guest User.


A registered user is the one, who has an account with your application and has access to use say reports, a functionality accessible only by registered users.


A guest user can browse through your application, but cannot access the functions which are available to a registered user.


As elaborated, you can see that the same application behaves in two different ways for two different users or group of users.


User Role Permission Model


In a user role permission model, there are three entities that participate and the model is designed to revolve around them:


User

An individual entity or a group of entities that perform same or different set of actions on your application with the same or different set of data or resources are the users of your application.


For example - You saw guest user(s) and registered user(s), and their behavior when they access your application.


Role

When the users are grouped into an entity to define or address same as one set, and also hold the details of actions that can be performed then such an entity is defined as Role.


For example - User 1, User 2, or User 3 who do not have an account created with your application can all be termed as Guest users and belong to Role - Guest.


Permission

Permission entity defines the set of actions that a user can perform on your application.


For example - Only a registered user can download or view reports. Downloading or viewing reports are actions modelled for a registered group of users.


Types of Permission Model


There are two ways through which a permission model can be architected, based on the requirements of the system, one of them is chosen.

  • Role-based access control (RBAC)

  • Attribute-based access control (ABAC)

Role Based Access Control


There are few key attributes associated with a role based access control model. It:

  • Restricts network access based on the roles and not individual users

  • Provides access rights only to the information an entity needs

  • A simple, manageable approach

  • Is less prone to error than assigning permissions to an entity

A permission model designed based on users, roles, and permissions.
Role based access control

In the above diagram, you can see that roles are defined at an authority level and are associated with certain permissions to access resources. The application users are associated with roles, and an admin user assigns appropriate roles to the users. Thus, it defines a controlled access model for your application users.


There are two ways in which you can implement a role based access.


Core RBAC

Core RBAC is foundation of all role based access models. As seen in above diagram, it has a number of roles depicted as a capital N. Each role has a set of permissions associated with roles and in turn with permissions.


The main entities that are modelled in the core RBAC are:


User

The individuals which are identified with a unique user identification (UID).


Role

A named job function (indicates the level of authority).


Permission

Equivalent to access rights a role has on application.


Session

A mapping between a user and a set of roles to which the user is assigned in the context of a working time, that is the duration in which they access your application.


Object

A system resource that requires permission to access.


Operation

Any action in the protected network that is performed by a user.


Model-Driven Role Base Access

The model-driven role base access where the core RBAC is modelled using database entities. A permission model is defined by creating entities in database, that is the tables created are mapped to actual entities that are governed by access rules.


A User Role Permission using model driven modelling for RBAC implementation.
A User Role Permission modelled using Model Driven Modelling for RBAC Implementation.

In above table, using model driven modelling you can create tables:

  • User table that stores information related to individuals accessing your application.

  • Role table that stores information of roles a user can have.

  • User Role table that stores association between a user and the roles.

  • Permission table that stores information about resources and actions that can be performed on resources.

  • Role Permission table that stores association between roles and permissions. That is which role has what all permissions.

Hierarchical Role Based Access

It determines the model mapping based on the hierarchy of your organization. Basically, the higher you are in the level, the more access you will likely have. The hierarchical RBAC ensures that the parent has all rights that are available with a child.


For example: Your organization has a hierarchy where there is a System Admin and Admins who report to a System admin. If an admin and can perform an action of creating entities then according to hierarchical role based access, the parent that is a system admin will have rights to create entities and in addition to that will also have some more access say to delete entities, modify permissions of entities and more.


Ways to Implement

There are different tech stacks available that you can use to model the role based access like:


Spring Security

Spring security provides you with options to either provide role base access at entity or method level or to externalize the access.


Annotations

The method level access can be provided by using annotations like @Secured or @RolesAllowed.


@Secured annotation is used to specify a list of roles that can access the method. That is a user can access that method only if she has one of the specified roles assigned to her.


For example - In the below code snippet - A user with a role admin can only access method getReport().

@Secured("ROLE_ADMIN") public String

getReport() { 

SecurityContext securityContext = SecurityContextHolder.getContext(); return securityContext.getAuthentication().getReports(String reportName); 

}

Another way to provide method level access is by using @RolesAllowed annotation that also takes a list of allowed roles. For example - In below code snippet - users with role SUPERADMIN can invoke methods getAllReports() as well as getAdminReport(). However, a user with role ADMIN can only invoke getAdminReport.


@RolesAllowed("ROLE_SUPERADMIN") public String
getAllReports() { 
	// method body
} 

@RolesAllowed({ "ROLE_SUPERADMIN", "ROLE_ADMIN" }) 
public boolean getAdminReport(String reportName) { 
	//method body
}

There are other annotations like PreAuthorize and PostAuthorize and more that you can use to define method level access. A detailed annotation detail can be found here.


OAuth

You can implement role based access using OAuth which is an open standard for access delegation. Generally, used by third-parties like Amazon, Google, Facebook and more.


OAuth uses scope as a mechanism to restrict or grant access to a user by providing tokens to access resources. It is popular in microservices architecture where every user request is validated against a user scope and a user token is generated to access resource(s).


Attribute Based Access Control


Attribute-based access control is an advanced access model that provides dynamic, context-aware, and risk-intelligent access control.


Using an attribute based access you will achieve efficient regulatory compliance, effective cloud services, reduced time-to-market for new applications, and a top-down approach to governance through transparency in policy enforcement.


An attribute based access as name suggests uses attributes as a building block to govern access using structured language.


Attribute based access where a user access is modelled using attributes.
Attribute Based Access Modelling

In the above figure, you will see that every entity be it user, resource or environment has attributes associated with them. Each of these attributes serve as and individual entity as far as access is concerned.


Each attribute is consists of a key-value pair. For example - a user attribute name will store a user's name into it and thus will be represented as name= John Smith, where name is the key and John Smith is the value.


Basically, an attribute is defined by 5Ws. That is Who is the attribute associated with, What is the value of that attribute, Where can the attribute be accessed, Why a permission to access is needed and With What the access privilege be used.


Ways to Implement

In order to implement attribute based access you can use following tech stack.


XACML

XACML is a policy based language that is as expressive as a natural language that we used to communicate daily. For example - if you want to represent the sentence - an admin wants to create an entity for a given context, then can be represented in four grammatical building blocks in the policy based language.


Subject- Who demands the access? - Admin demands access


Action- What operation user wants to perform? Admins want to create.


Resource- Which object or resource will be impacted? An entity.


Environment- Where is the access request made? In the given context.


As you saw, how a statement is broken down into subject, action, resource and environment. Once this is done, then the attribute evaluation is triggered using policy based authorization.


XACML Architecture

An XACML architecture includes:


Policy Enforcement Point (PEP), which intercepts any requests in a normal program flow. Policy Decision Point (PDP) that grants or denies access based on the policies associated with the PDP.


XACML architecture representation with policy enforcement and decision points.
XACML Architecture Representation

The PDP evaluates the XACML request created by the PEP and runs through the policies to make one of the four access decisions, namely:

  • PERMIT - approve

  • DENY - access denied

  • INDETERMINATE - error at the PDP

  • NOTAPPLICABLE - some attributes missing in the request or no policy match.

In order to understand the policy based authorization, let's take an example - a policy states that -


All admins belonging to the department Human Resource (HR) should have read access to Recruitment reports within the London region.


The policy can be broken down as:

Subject | department - HR

Subject | region - London

Action - read

Resource | type - recruitment reports

Resource | region - London


Access request - An admin user from the HR department in London wants to view recruitment report.


PDP will evaluate the access request based on following attributes that are defined in the policy.


User | department - HR

User | region - London

Action - read

Resource | type - recruitment reports

User | region - London


As the user's request matches with the policy, PDP generates an access decision as 'PERMIT' and the access is granted to the user.