FAQ - Access Control Process - Permission Model

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

• Hierarchical RBAC

• 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.

Implementation:

• Spring Security

• 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

• Amazon

• Google

• Facebook

• Database Model - Creating entities and manage the permission model in the application. Tables that could be created-

• Roles

• Permissions

• User Roles

• Role Permissions

• Users

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

• Achieves:

• Efficient regulatory compliance

• Effective cloud services

• Reduced time-to-market for new applications

• A top-down approach to governance through transparency in policy enforcement

ABAC uses:

• 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”.

• It defines:

• Who

• What

• Where

• Why

• With what

Implementation:

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”

• Action= “read”

• 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.

XACML Processing:

• 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.