RBAC (role-based Access Control)

http://hi.baidu.com/akini/blog/item/eddbd61b90f6d4fbae513371.html
RBAC Help Editor Encyclopedia card

Role-based access controls (role-based access control) as a promising alternative to traditional access control (autonomous access, forced access) are widely concerned. In RBAC, permissions are associated with roles, and users get permissions to those roles by becoming members of the appropriate role. This greatly simplifies the management of permissions. In an organization where roles are created to accomplish a variety of jobs, users are assigned roles based on their responsibilities and qualifications, and users can easily be assigned to another role from one role. Roles can be given new permissions depending on the new requirements and the consolidation of the system, and permissions can be reclaimed from a role as needed. The relationship between roles and roles can be set up to encompass a wider range of objective situations.

Directory

Introduction to

RBAC basic concept

RBAC96

model

ARBAC97 model

DRBAC

expansion about editing this paragraph

RBAC supports three well-known security principles: the principle of least privilege, the principle of separation of responsibilities and the principle of data abstraction. The principle of least privilege is supported by RBAC because RBAC can configure its role to be the minimum set of permissions it needs to complete a task. The principle of segregation of duties can be manifested by invoking mutually exclusive roles to accomplish sensitive tasks, such as requiring a single accounting clerk and a financial administrator to participate in the same posting. Data abstraction can be embodied through the abstraction of permissions, such as the abstract rights of borrowing and depositing for financial operations, rather than the typical read, write, and execute permissions provided by the operating system.　　However, these principles must be embodied by the detailed configuration of the various parts of RBAC. RBAC has many components, which makes the management of RBAC multi-faceted. In particular, we want to split these issues to discuss: the assignment of users and roles, the assignment of roles and permissions, and the assignment of roles and roles to define the inheritance of roles. These activities require the linking of users and permissions. In many cases, however, they are best done by different administrators or management roles. Assigning permissions to roles is typically the responsibility of the application Manager. In the banking application, the debit and deposit Operation authority is assigned to the cashier role, and the authorized loan Operation Authority is assigned to the manager role. and assigning specific personnel to the corresponding cashier role and manager role is the category of Personnel management. Roles and roles are assigned features that include the assignment of users and roles, and the assignment of roles and permissions. More generally, the relationship between roles and roles embodies a broader range of strategies.

edit this paragraph rbac basic concept

　　RBAC thinks that authority authorization is actually the problem of who, what, how.　　In the RBAC model, who, what and how are the three groups of access rights, that is, "what the Who which".　　Who: a user or subject of authority (such as principal, User, Group, Role, actor, etc.) What: the object or resource (Resource, Class) to which the permission is directed.　　How: Specific permissions (Privilege, positive authorization and negative authorization). Operator: operation. Shows how to operate on what. That is Privilege+resource role: a set of roles, a certain number of permissions.　　The unit and carrier of permission assignment is to isolate the logical relationship between user and privilege. Group: User groups, authority assignment units and vectors. Permissions are not considered assigned to a particular user but to groups. Groups can include groups (to enable inheritance of permissions), or they can contain permissions for users to inherit groups within a group. User and Group are many-to-many relationships.　　Group can be layered to meet the requirements of different levels of permission control. The focus of RBAC is the relationship between role and user, permission. Called User Assignment (UA) and permission Assignment (PA). The left and right sides of the relationship are many-to-many relationships.　　Is that user can have multiple role,role that can include more than one user. Any use of RDBMS knows that N:m's relationship requires an intermediate table to hold the relationship of two tables. This UA and PA are equivalent to the intermediate table.　　In fact, the whole RBAC is based on the relational model. The session is a more obscure element in RBAC. Standard says: Each session is a mapping, a user to multiple role mappings. When a user activates a subset of all his characters, a session is created.　　Each session is associated with a single user, and each user can be associated to one or more sessions. In the RBAC system, the user is actually playing the role, can use actor to replace user, the idea comes from business Modeling with UML book Actor-role mode. Given that multiple people can have the same permissions, RBAC introduces the concept of group. Group is also seen as an actor.　　And the concept of user is like a person. The group is different from Group (group) in Gbac (group-based Access Control)。 Gbac is used in the operating system.　　The group is directly associated with permissions, and in fact RBAC draws on some gbac concepts. Group and user are concerned with the organization, but not the organization. The two are conceptually different. An organization is an abstract model of a company structure that is physically present, including departments, people, positions, and so on, while a permission model is a description of abstract concepts.　　The organizational structure is generally modeled by Martin Fowler's party or responsibility model. The relationship between person and user in party mode is that each person can correspond to a user, but probably not all of the user has a corresponding person. Party in the Department department or organization organization, can correspond to group. Conversely, group does not necessarily correspond to an actual institution.　　For example, there may be a deputy manager of this group, which is the same responsibility of many people. The introduction of the group concept, in addition to solving the problem of multiple people with the same role, is also used to solve another organizational authority issue: for example, a sector of the news I want all a department of people can see. With such a group of a department, you can directly authorize this group.

edit this paragraph RBAC96 model RBAC0

1. U: Represents the user set; R: Represents a set of roles; P: Represents a permission set; S: Represents a session set; 2. paí PXR, is a multiple-to-many assignment of permissions to a role; 3. UA Í UXR, is the user to the role of many-to-many assignment; 4. User:s→u, a single mapping of sessions and users, User (SI) representing the users who created the session Si; 5. ROLES:S→2R, a mapping of session and role subsets, roles (SI) represents a set of roles for the session Si; 6. The session SI has a permission set of P (SI).

RBAC1

On the basis of RBAC0, the role level is added, which reflects the multilevel security requirement.

RBAC2

A constraint set is added based on the RBAC0.

RBAC3

A collection of functions and functions of the RBAC1 and RBAC2.

edit this paragraph ARBAC97 model

The ARBAC97 model is a role-based role management model, consisting of three parts: URA97: User-Role management model PRA97: Permissions-Role management model RRA97: role-Hierarchy management model

edit this paragraph DRBAC

Drbac is a distributed RBAC model under the Dynamic Alliance environment.　　Drbac differs from the previous trust management and RBAC approach in that it supports 3 features: 1. Third-party assignment: If an entity is authorized to assign an assignment, it can assign a role other than its namespace.　　2. Numeric properties: Adjust access rights by assigning a mechanism for handling numeric values related to the role.　　3. Assign monitoring: Use the PUB/SUB structure to continuously monitor the established trust relationship to track the status of the assigned assignment that can be canceled. Drbac is caused by the problem of access control of resources in an Allied environment. An "Alliance environment" could be a military effort to work together to achieve a common goal, or a business partnership between several companies. The Allied environment definition is characterized by the existence of multiple organizations or multiple entities that do not have a common, trusted Authority Center. In this case, entities must collaborate to share the portion of the protected resources necessary for an alliance while protecting their respective resources.　　The growth of network services on the Internet makes such a requirement very common. DRBAC combines the advantages of RBAC and trust management systems, and is a system that manages both flexible and decentralized, scalable implementations. DRBAC represents the controlled behavior of the role, which is defined within the trust domain of an entity and can be passed on to other roles within different trusting domains. DRBAC uses PKI to identify all entities related to trust-sensitive operations and to confirm the assignment of certificates. The mapping of namespaces from roles to authorizations avoids the need to identify additional policy sources.

RBAC (role-based Access Control)