FAQ - Access Control Process - Permission Model
Updated: Mar 8
Access Control Processes are an integral part of today's digital world. 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.
That's when an application is designed to follow the user, role, and permission model which defines privileges associated with a user.
What is an 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.
What are the entities participating in an access control model?
There are three entities around which the access control model revolves:
User - An entity that has access to perform certain actions on desired data/resource.
Role - An entity that is a superset of the User and holds the details of set actions that can be performed.
Permission - An entity that defines actions.
How to implement an access control process for a multi-user application?
There are two ways through which a permission model can be architect, based on the requirements of the system, one of them is chosen.
Role-based access control (RBAC)
Attribute-based access control (ABAC)
What is role-based access control and how to model it?
Role-based access control, abbreviated as RBAC:
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
Less prone to error than assigning permissions to an entity
In RBAC modeling:
Users are assigned to Roles
Permissions are authorized to Roles
Model: There are two ways in which RBAC can be implemented:
Core RBAC: This is the foundation of all RBAC implementations where:
N number of roles are created, each role has a defined set of permissions
Roles are mapped to users to define the access based on the permissions assigned to that role
The main entities in this model are:
User – an individual (identified by a unique UID) with access to a system
Role – a named job function (indicates the level of authority)
Permission – equivalent to access rights
Session – a mapping between a user and a set of roles to which the user is assigned in the context of a working time
Object – a system resource that requires permission to access
Operation – any action in the protected network
Users have assigned roles and in turn, based on the roles, they access resources.
Hierarchical RBAC: It determines the model mapping based on the organization hierarchy. Basically, the higher you are in the chain, 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: if a user is termed as an admin and can perform an action of creating entities then its parent says system admin will have rights to create entities and in addition to that will have more access say to delete entities.
Annotate each method with roles that can access the entity/method.
Access Control Lists (ACL)
To externalize the authorization, one can use “ACL” which will evaluate if the current role is listed in the list available for that entity.
OAuth - Open standard for access delegation used by third parties like
Database Model - Creating entities and manage the permission model in the application. Tables that could be created-
What is an attribute-based access control and how to model it?
Attribute-based access control, abbreviated as ABAC:
Is a next-generation authorization model
Provides dynamic, context-aware, and risk-intelligent access control
Efficient regulatory compliance
Effective cloud services
Reduced time-to-market for new applications
A top-down approach to governance through transparency in policy enforcement
Attributes as building blocks in a structured language
Defines access control rules and describes access requests
Each attribute consists of a key-value pair such as “Role= SysAdmin”.
ABAC can be implemented using XACML.
XACML is a policy language that is as expressive as a natural language.
For example: “An Admin wants to create an entity for a given context”. A sentence like this includes four grammatical building blocks:
Subject – Who demands access
Action – the user wants to perform
Resource – the object impacted due to action
Environment - in which the access request is made
Attribute evaluation then enables effective policy-based authorization.
Let’s consider this 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”.
An access request evaluation based on the following attributes and attribute values should therefore return PERMIT:
Subject’s “department” = “HR”
Subject’s “region” = “London”
Resource “type” = “Recruitment reports”
Resource “region” = “London”
The following diagram shows a basic XACML architecture that includes:
Policy Enforcement Point (PEP), which intercepts any requests in a normal program flow.
Policy Decision Point (PDP) grants 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.
Amazon’s The Axiomatics Policy Server - Paid
JBOSSXACML - Open Source Library
Spring Security’s XACML using SpEL (Spring Expression Language)
Which model to choose while architecting user permission?
While ABAC provides a lot of complexity and governance at the elementary level, RBAC often is sufficient to model the access privileges for almost 80% of applications. Even if one uses ABAC, at its core ABAC needs the RBAC set up in place. Both of these are filters to model the access control, ABAC being the more complex of the two and requires more power, processing, and time. The access control processes must be managed and reviewed from time to time to meet organizational needs.