RBAC-based permission management model learning

In RBAC, permissions are associated with roles. You can obtain permissions of these roles by becoming a member of an appropriate role. This greatly simplifies permission management.

In an organization, roles are created to complete various tasks. Users are assigned roles based on their responsibilities and qualifications, you can easily assign a role to another role. Roles can be assigned new permissions based on the new requirements and the merger of the system. permissions can also be revoked from a role as needed.

The relationship between roles and roles can be established to cover a wider range of objective situations.

BAC supports three well-known security principles: Minimum permission principle, responsibility separation principle, and data abstraction principle.(1) the principle of least privilege is supported by RBAC because RBAC can configure its role as the minimum permission set required to complete the task. (2) The responsibility separation principle can be embodied by calling mutually independent and mutually exclusive roles to jointly complete sensitive tasks. For example, a clerk and a financial administrator are required to participate in the same posting. (3) data abstraction can be reflected through permission abstraction, such as abstract permissions such as borrowing and deposit for financial operations, without the typical read, write, and execute permissions provided by the operating system. However, these principles can only be embodied through detailed configuration of RBAC components. RBAC has many components (bucu), Which makes RBAC management multi-faceted. In particular, we need to separate these questions to discuss: user and role assignment; Role and permission assignment; Role and role assignment for defining role inheritance. All these activities require that users and permissions be linked. However, in many cases, they are best performed by different administrators or management roles. Assigning permissions to a role is the responsibility of a typical application manager. When the number of users is very large, it is very cumbersome to authorize (assign roles) each user in the system one by one. In this case, you need to group users. Each user group has multiple users. In addition to user authorization, you can also grant permissions to user groups. Further, you can separate role groups and other concepts.In the banking application, the loan and deposit operation permissions are assigned to the cashier role, and the approval loan operation permissions are assigned to the manager role. Assigning specific personnel to the corresponding cashier and manager roles is the scope of personnel management. The assignment of roles includes the assignment of users and roles, and the assignment of roles and permissions. In general, the relationship between roles reflects a wider range of policies. 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 (such as principal, user, group, role, actor, etc.) What: the object or resource (resource, class) for which the permission is applied ). How: specific permissions (privilege, positive authorization and negative authorization ). Operator: operation. Indicates how to operate on what. That is, privilege + resourcerole: 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, and 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.