Access control defines which resources and actions are available to a user depending on their permissions or role in the system.
The process starts with authentication, which verifies the user’s identity, and continues with authorization — checking whether the user is allowed to perform a particular action.
There are different access control models. In this article we will look at the most common ones: role-based (RBAC) and attribute-based (ABAC) models.
One way to restrict user access to a system is role-based access control.
Imagine you have a page on a social network.
As the owner of the page, you can create, view, edit , delete content.
Friend can view your content.
Guest has no access to your content.
Moderator can view and delete undesired content.
This way you get actors and the operations they are allowed to perform:
Roles
Actions
These standard actions are called CRUD (Create, Read, Update, Delete) operations.
The table shows how access to the content of a user’s personal page is split between different user groups. Such a permission structure is called a role model.
| Resource | Owner | Friend | Guest | Moderator |
|---|---|---|---|---|
| /my-page | C R U D | R | — | R D |
Another approach to restricting user access to a system is attribute-based access control.
Subject attributes — user characteristics that affect access
Action attributes — operations the user can perform
Object attributes — properties of the object being accessed
Environment attributes — the context in which access takes place
Splitting access to a user’s personal page content for users with different attributes:
| Resource | Subject attributes | Action attributes |
|---|---|---|
| /my-page | Role: Owner | Action: C R U D |
| /my-page | Role: Friend | Action: R |
| /my-page | Role: Guest | Action: — |
| /my-page | Role: Moderator | Action: R D |
| /my-page | Role: Moderator | Action: R U D |
Now two moderators have access to different sets of operations.
Using ABAC makes access management more flexible and can be combined with the RBAC model.
An important task a QA engineer may face is checking that the implemented role model matches the one described in the requirements.
Requirements for the role model of the «Records list».
| Section | User | Analyst | Administrator |
|---|---|---|---|
| Records list | C R U | R | C R U D |
During testing the tester changes their role either on their own or by asking colleagues for help.
Change the «Role in the system» and check that the implementation of the role model for the «Records list» section matches the requirements.
Уровень повышен!
