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.
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
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.
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.
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.
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.
XACML Processing
There are policy servers available in market that can be used. Some popular ones are:
Amazon’s The Axiomatic Policy Server - Paid
JBOSSXACML - Open Source Library
Spring Security’s XACML using Spring Expression Language
RBAC or ABAC
Identity management protects your digital identities and sensitive data associated with it. But which methodology will be best for your implementation.
You can take a calculated decision based on some factors:
When to Use RBAC
Rules defined in RBAC are simple and easy to use. The evaluation using RBAC are fast and less process intensive.
Use Case for RBAC
When you have small workgroups or applications where defining work by role is simple then that would be an ideal use case for implementing RBAC.
For example - You work for a retail shop with a handful of employees, then manage user role permission model with RBAC.
When to Use ABAC
When you are dealing with complex business functions and a lot of hierarchical processes and the permission model deals with the granularity of data then you should opt for ABAC.
Use Case for ABAC
When your organization is focused on time-sensitive data, location-specific data access, then you should opt for ABAC.
For example - you work in an organization where you are not allowed to access files outside office premises, then go for ABAC to implement your user role permission model.
There are certain organizations who opt for a hybrid model where RBAC sits on the periphery whereas the internal processing of department is managed by ABAC.
Takeaway
Access Control management is an integral part of today's digital world. With options to choose from role based or attribute based access modelling you can secure your sensitive data.
What is important is to understand which modelling works the best for your organization. ABAC provides a lot of complexity and governance at the elementary level. Often RBAC is sufficient to model the access privileges for almost 80% of applications.
Consider that ABAC implementation still needs modelling of RBAC at the core and as it is more complex, it requires more power, processing and time.
Whichever user role permission model you opt for remember that the access control processes must be managed and reviewed from time to time to meet your organizational needs.
Technical Marketing is the next big thing in the Tech Industry. I'd love to talk with you. Learn more about how it can help your business by booking a discovery call.