Enterprise Application Access Control Design - Back End

November 08, 2018

Special Thanks to…

Co-Author: Pang Cinyi cinyipang1@gmail.com

Background and Pain Points

Recently at work, I proposed to develop a new enterprice resporce management platform to replace the existing one which has bunches of problems. One of the major obstacle is user access control problem.

In the exisiting platform, access controls are managed by the front end routes, which means that users will be able to do anything once they have access to the particular page through the menu. If developers want to further control the range of data available, web components or even fields for access, they need to do customized inner access control.

In this way, the front end page will have over complicated logics, resulting in lack of centralized and standardized access control accross the platform. Besides, every developer adopts individual’s own development methodologies. Once a turnover takes place, the engineer who takes over the parts will have to spend additional time to understand the unique access control design for this particular module. In the end, as the platform grows, it becomes increasingly hard to maintain.

Therefore, the first thing first to resolve is definitely the access control problem if I decide to build a new platform. We must re-design a standard access control system with high scalability, good maintanability and extensibility.

Three Aspects in Access Control

There are three aspects we should consider in access control. Namely

Role-based control: Which group does this user belong to and what access rights does this group of user have?
UI level control: What modules / pages / components can users read / write?
Data level control: What is the range of data can users read/ write?

Role-based control

To avoid duplicated settings, role-based control should be implemented. Why? That is because some users have the same access rights because of their job titles and job levels are the same. If access rights are assigned to them individually, there will be duplications. In addition, if there is any change in future, for example, HR staffs will have access rights to a new component called “Benefit Management”, this access will be repeatedly added to every one of the HR staffs, which is redundant and error-prone.

UI Level Control

In enterprise resource platform, there might be a number of modules such as Finance, Human Resource, IT… There might also be sub-modules such as invoice management and business reports in Finance, leave application, candidate management and claim submission in Human Resource.

Different modules may be accessed by different group of users with different kind of rights. For example, only HR staffs can access to candidate management module but everyone can access to leave management module.

Data Level Control

In our organization, there are several child companies, every one of which has a number of departments. Therefore, even if users from company A and company B can see the same view / page, company A will only see data from company A and company B will only see data from company B.

Imagine what will happen HR staffs from company A can see claim submissions from company B!

Database Design

With the above considerations, we drafted a database design as below.

Users contains information about users and their roles
Roles contains role definitions
Modules contains modules and sub-modules information
ModuleControls contains mapping settings between modules and roles, which specifies what modules can a role access.
AccessControls contains different types of access control for a particular module control. For example, a Read type access control for HR staff in Leave Application Management sub-module
DataControls contains different data access controls for a specific access control type. For example, HR staff from Company A has Read access control on Leave Records from Company A in Leave Application Management
Companies contains information about companies
Departments contains information about departments

Sample JSON Returned by Access Control API

According to the above design, web API will be built and returned to the front end for actual access rights handling. The following code snippet shows a sample JSON returned by the web API. It is for a role which has full access (read and write) to all the leave applications in SG Company A, but only have read access to two departments in SG company B. (Don’t ask me why there is such a weird requirement… -_-)

[
    {
        systemName: 'HR',
        moduleName: 'Leave Application',
        moduleCode: 'HR_LeaveApplication',
        AccessControl: [
            {
                accessControlName: 'read',
                dataControl: [
                    {
                        dataControlName: 'SG-CompanyA'
                        companyId: 1
                    },
                    {
                        dataControlName: 'SG-CompanyB-DepartmentA'
                        companyId: 2,
                        departmentId: 35
                    },
                    {
                        dataControlName: 'SG-CompanyB-DepartmentB'
                        companyId: 2,
                        departmentId: 36
                    }
                ]
            },
            {
                accessControlName: 'write',
                dataControl: [
                    {
                        dataControlName: 'SG-CompanyA'
                        companyId: 1
                    }
                ]
            }
        ]
    }
]

This is the end of the introduction about back end design. We shall continue to introduce access control design in front end next time. Syi ya~