RBAC 基于角色的访问控制权限

Design
Within an organization, roles are created for various job functions. The permissions to perform certain operations are assigned to specific roles. Members or staff (or other system users) are assigned particular roles, and through those role assignments acquire the permissions needed to perform particular system functions. Since users are not assigned permissions directly, but only acquire them through their role (or roles), management of individual user rights becomes a matter of simply assigning appropriate roles to the user's account; this simplifies common operations, such as adding a user, or changing a user's department.

Three primary rules are defined for RBAC:

1.Role assignment: A subject can exercise a permission only if the subject has selected or been assigned a role.
2.Role authorization: A subject's active role must be authorized for the subject. With rule 1 above, this rule ensures that users can take on only roles for which they are authorized.
3.Permission authorization: A subject can exercise a permission only if the permission is authorized for the subject's active role. With rules 1 and 2, this rule ensures that users can exercise only permissions for which they are authorized.

上面这段话在说RBAC设计，感觉来说，一个用户要做某件事情首先他必定要先是一个Role，这个Role是由系统控制者创建的具有针对某些功能有某些权限的Role。可能来说，对Role A对甲系统来说，他有复制，查看，但是没有删除权限。但是对Role B来说，对甲系统，他有复制，查看，删除，所有权限。

三条主要规则，应该是针对RBAC的三条准则。
1.应该把做某件事的权限设计在某一个Role下。
2.一个用户应该被授予一个Role身份。
3.一个用户要做一件事，那么应该先取得对应这件事的Role身份。

Additional constraints may be applied as well, and roles can be combined in a hierarchy where higher-level roles subsume permissions owned by sub-roles.

With the concepts of role hierarchy and constraints, one can control RBAC to create or simulate lattice-based access control (LBAC). Thus RBAC can be considered to be a superset of LBAC.

When defining an RBAC model, the following conventions are useful:

S = Subject = A person or automated agent
R = Role = Job function or title which defines an authority level
P = Permissions = An approval of a mode of access to a resource
SE = Session = A mapping involving S, R and/or P
SA = Subject Assignment
PA = Permission Assignment
RH = Partially ordered Role Hierarchy. RH can also be written: ≥ (The notation: x ≥ y means that x inherits the permissions of y.)
	A subject can have multiple roles.
	A role can have multiple subjects.
	A role can have many permissions.
	A permission can be assigned to many roles.
	An operation can be assigned to many permissions.
	A permission can be assigned to many operations.
A constraint places a restrictive rule on the potential inheritance of permissions from opposing roles, thus it can be used to achieve appropriate separation of duties. For example, the same person should not be allowed to both create a login account and to authorize the account creation.

缺点
Prior to the development of RBAC, the Bell-LaPadula (BLP) model was synonymous with MAC and file system permissions were synonymous with DAC. These were considered to be the only known models for access control: if a model was not BLP, it was considered to be a DAC model, and vice versa. Research in the late 1990s demonstrated that RBAC falls in neither category.Unlike context-based access control (CBAC), RBAC does not look at the message context (such as a connection’s source). RBAC has also been criticized for leading to role explosion, a problem in large enterprise systems which require access control of finer granularity than what RBAC can provide as roles are inherently assigned to operations and data types. In resemblance to CBAC, an Entity-Relationship Based Access Control (ERBAC, although the same acronym is also used for modified RBAC systems,such as Extended Role-Based Access Control) system is able to secure instances of data by considering their association to the executing subject.

各类RBAC使用调研
casbin

okta
Spring Boot 2.0
要钱

Shiro

User-Role-Permission security pattern (RBAC) in Spring Security 4