About Java Role access control (RBAC)

role-based access Control (RBAC) introduces the concept of role to isolate user (that is, action body, Subject) and privilege (permission, which represents an operation on Resource, i.e. Operation+resource).

Role as a proxy layer of user and permission (privilege), decoupling permissions and user relationships, All authorizations should be given role rather than directly to user or group.privilege is a permission particle, composed of operation and resource, representing a operation to resource. For example, a delete operation for a news. Role-privilege is the many-to-many relationship, which is the core of authority.

The two notable characteristics of role-based access control (RBAC) are: 1. The change in roles/permissions is much slower than the change between roles/user relationships, reducing the complexity of authorization management and reducing management overhead. 2. Flexibility to support the enterprise's security policy, and the changes in the enterprise has a great scalability.

Basic concepts of RBAC:

RBAC believes that authorization is actually the problem of who, What and how. In the RBAC model, who, what and how make up the access rights ternary group, namely "Who to what (Which) how to operate."

Who: a person 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, forward authorization and negative authorization).

Operator: operation. Shows how to what. which is privilege+resource.

Role: A collection of roles, a certain number of permissions. The unit and carrier of the assignment of rights, the purpose is to isolate the logical relationship between user and privilege.

Group: User groups, authority assignment units and carriers. Permissions are not assigned to a specific user and to a group. Groups can include groups (to implement inheritance of permissions), or you can include users, and users in groups inherit permissions from groups. 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 on 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 relations. That is, the user can have multiple role,role that can include more than one user.

As is known with the RDBMS, the n:m relationship requires an intermediate table to hold the two-table relationship. This UA and PA are equivalent to the middle table. In fact, the whole RBAC is based on the relational model.

Session in RBAC is a more obscure element. The standard says: Each session is a mapping, a user to multiple role mapping. A session is established when a user activates a subset of all his characters. Each session is associated with a single user, and each user can be associated with one or more sessions.

In the RBAC system, user is actually playing the role, can replace user with actor, this idea comes from business modeling with UML book Actor-role mode. Considering that multiple people can have the same permissions, RBAC introduces the concept of group. Group is also seen as a actor. And the concept of user is like a person.

Group (groups) in group and GBAC (group-based Access control) are different here. Gbac is used in the operating system more. The group is directly related to the permissions, in fact RBAC also borrows some GBAC concepts.

Group and user are related to an organization, but not an organization. The two are conceptually different. An organization is an abstract model of the physical existence of a corporate structure, including departments, people, Jobs, and so on, whereas the privilege 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 perhaps not all of the user has a corresponding person.party in the Department department or organization organization, can correspond to group. Conversely, a group may not correspond to an actual institution. For example, there can be a deputy manager this group, which is multiple people have the same responsibilities.

The introduction of the group concept, in addition to solving multiple people of the same role problem, but also to address the Organization's other licensing issues: for example, a department of news I hope that all a department of people can see. With such a group of sector A, you can authorize this group directly.

Role as a proxy layer of user and permission (privilege), decoupling permissions and user relationships, All authorizations should be given role rather than directly to user or group.privilege is a permission particle, composed of operation and resource, representing a operation to resource. For example, a delete operation for a news. Role-privilege is the many-to-many relationship, which is the core of authority.

The two notable characteristics of role-based access control (RBAC) are: 1. The change in roles/permissions is much slower than the change between roles/user relationships, reducing the complexity of authorization management and reducing management overhead. 2. Flexibility to support the enterprise's security policy, and the changes in the enterprise has a great scalability.