Role-based RBAC Access Control

 

Role-Based Access Control (Role-Based Access Control) introduces the concept of role, in order to isolate the user (that is, the action subject, subject) and privilege (permission, indicates an operation on the resource, namely, operation + resource ).

As a proxy layer between a user and privilege, role decouples the relationship between permissions and users. All permissions should be granted to role rather than user or group. Privilege is a permission granule consisting of operation and resource, indicating an operation of resource. For example, delete news. Role-privilege is the relationship between role-to-role, which is the core of permissions.
The two major features of Role-Based Access Control (RBAC) are: 1. the changes between roles and permissions are much slower than those between roles and users. This reduces the complexity of authorization management and management overhead. 2. flexible support for enterprise security policies and great scalability for enterprise changes.
RBAC basic concepts:
RBAC regards permission authorization as a problem of who, what, and how. In the RBAC model, who, what, and how constitute three tuples of access permissions, that is, "who performs how operations on what (which ".
WHO: The owner or subject of the permission (for example, Principal, user, group, role, actor, etc)
What: the target object or resource (resource, class ).
How: specific permissions (privilege, positive authorization and negative authorization ).
Operator: operation. Indicates how to operate on what. That is, privilege + Resource
Role: a set of roles with a certain number of permissions. The unit and carrier of permission allocation, which aims to isolate the logical relationship between user and privilege.
Group: user Group, the unit and carrier of permission allocation. Permissions are assigned to the Group Regardless of specific users. A group can contain groups (to inherit permissions) or users. users in a group can inherit the permissions of a group. The relationship between User and Group is many-to-many. Groups can be hierarchical to meet the requirements of permission control at different levels.
RBAC focuses on the relationship between Role and User and Permission. The relationship is called the User assignment (UA) and Permission assignment (PA). The relationship between the left and right sides is the same-to-minus relationship. That is, the user can have multiple role, and the role can contain multiple users.
All RDBMS users know that the n: m relationship requires an intermediate table to store the relationship between the two tables. The UA and PA are equivalent to the intermediate table. In fact, the whole RBAC is based on the relational model.
Session is an obscure element in RBAC. In terms of standards, each Session is a ing, and one user is mapped to multiple role. When a user activates a subset of all his roles, a session is created. Each Session is associated with a single user, and each User can be associated with one or more sessions.
In RBAC systems, a User is actually playing a Role and can replace the User With an Actor. This idea comes from the Actor-Role mode in Business Modeling With UML. Given that multiple people can have the same permissions, RBAC introduces the concept of Group. Group is also considered as an Actor. The concept of User is like a person.
The Group and GBAC (Group-Based Access Control) are different. GBAC is mostly used in the operating system. The Group is directly associated with the permission. In fact, RBAC also draws on some GBAC concepts.
Both Group and User are related to the organizational unit, but not the organizational unit. The two are conceptually different. An organizational unit is an abstract model of a physical company structure, including departments, persons, and positions. The permission model describes abstract concepts. Generally, the organizational structure is modeled using the Party or responsibility mode of Martin fowler.
The relationship between person and user in party mode is that each person can correspond to a user, but not all users have corresponding persons. The department or organization in the Party can correspond to the group. Otherwise, the group does not necessarily correspond to an actual organization. For example, you can have a group named "deputy manager". Many people share the same responsibilities.

The introduction of the group concept is not only used to solve the problem of the same roles of multiple people, but also used to solve another authorization problem of the Organization: for example, I hope everyone in department a can read the news from department. With such a group corresponding to Department A, you can directly authorize this group.