RBAC-based permission Design Model

Permission analysis documentRBAC-based permission design model: 1 RBAC IntroductionRBAC is currently the most widely accepted permission model. The National Institute of Standards and Technology (NIST) Standard RBAC model consists of four component models, the four component models are the basic model RBAC0 (Core RBAC), The Role classification model RBAC1 (Hierarchal RBAC), The Role restriction model RBAC2 (Constraint RBAC), and the unified model RBAC3 (Combines RBAC) [1]. RBAC0 Model 1 is shown.
Chart 1 RBAC 0 model l RBAC0 Defines the smallest element set that can constitute an RBAC control system.RBAC contains five basic data elements: User users (USERS), role roles (ROLES), target objects (OBS), Operation operations (OPS), and permission permissions (PRMS, permissions are granted to a role rather than a user. When a role is assigned to a user, the user has the permissions contained in the role. Session sessions is the ing between the user and the activated role set. The difference between RBAC0 and traditional access control is that adding an indirect layer brings flexibility. RBAC1, RBAC2, and RBAC3 are successively extended on RBAC0. L RBAC1 Introduce inheritance relationships between rolesThe inheritance relationships between roles can be divided into general inheritance relationships and restricted inheritance relationships. Generally, the inheritance relationship only requires that the role inheritance relationship is an absolute partial-order relationship, allowing multi-inheritance between roles. The restricted inheritance relationship further requires that the role inheritance relationship is a tree structure. L RBAC2 Responsibility separation is added to the model.RBAC2 constraints specify the mandatory rules to be followed when a role is granted or a role is granted to a user and when a user activates a role at a certain time. Separation of duties includes static and dynamic separation of responsibilities. The relationship between constraints and user-role-Permission determines the access permission of users in the RBAC2 model. L RBAC3 Including RBAC1 and RBAC2It not only provides inheritance relationships between roles, but also provides separation of responsibilities. Create a role definition table. Determine the roles in the current system. Because of inheritance issues, the role represents a tree structure. 2 Permission design:Configure resources and resource operations: resources can be defined as a general resource model. Provides universal unified resource interfaces. Database ER diagram: relationship diagram: 3 Analysis:We can see from the above class relationship diagram and erdiagram. The entire permission can be abstracted into five objects. OrgBean: Describes the org model. Role : Used to describe roles. Permission : Describes permissions. Resource : Used to describe resources. Operation : Used to describe the operation.   Permission includes the aggregation of resources and Operation, and permissions for resources and operations. Role And Permission are both self-contained. Because it is designed to inherit permissions. Resource resources may also have a tree structure, and the resources must also be self-contained.   Thoughts :The core of the permission system consists of the following three parts: 1. create permissions. 2. assign permissions. 3. then, the main participants in each part of the system are as follows: 1. create permissions-create Creator, 2. permission assignment-Administrator assignment, 3. permission-User: 1. creator creates a Privilege. Creator is divided during system design and implementation. What permissions should a sub-system or module have. Here, the object declaration of Privilege and Resource is completed, and Privilege is not really linked with a specific Resource instance to form an Operator. 2. Administrator specifies the association between Privilege and Resource Instance. In this step, the permissions are actually associated with the resource Instance and the Operator (Privilege Instance) is generated ). The Administrator uses Operator as a basic element to create an ideal permission model. For example, operations such as creating roles, creating user groups, assigning users to user groups, and associating user groups with roles are completed by administrators. 3. the User uses the permissions assigned by the Administrator to use various subsystems. As a user, Administrator has a permission model that is suitable for management and maintenance. As a result, the programmer only needs to answer a question, that is, what permissions can be used to access any resources, that is, the Operator mentioned above. Providing Operator for programmers means putting armor on the system. The Administrator can follow his wishes to establish the desired permission framework and add, delete, and manage the relationship between Resource and Privilege. You can set the roing between User and Role on your own. (If Creator is regarded as the inventor of Basic, Administrator is the user of Basic, and he can do some script-based programming.) Operator is the most important part of the system, and it is a bond, A link between Programmer, Administrator, and User.   4 Permission API GetPermissionByOrgGuid (String orgGuid)Input an org Guid to obtain the access permissions of the current org object. GetSourcePermissionByOrgGuid (String orgGuid, String resouceGuid)By passing in an org Guid and a resource Guid, return to change Org's access permission to the current resource. GetPermissionByResourceGuid (String resource)Pass in the Guid of a resource to get the permission definitions under the current resource. HavingHeritPermission (String orgGuid, String resouceGuid): BooleanInput an orgGuid and the resource GUID to check whether the resource has the permission to inherit down under the changed OrgGuid. Here inheritance is the inheritance of resources. That is, you have permissions on the parent topic. You can inherit the permissions on the subtopics under the parent topic. HavingPermission (String orgGuid, String resourceGuid): BooleanChecks whether an Org has the permission to a resource. These are coarse-grained permission APIs. The following are fine-grained permissions: GetOperationByPermission (String permissionGuid)Use the Guid of permission to obtain all valid operations of the permission. GetOperationByGuid (String permissionGuid, String resourceGuid)Use the Guid of permision to obtain all valid operations under the resource. ScreeningOpreationByGuid (String permissionGuid, String resourceGuid, String orgGuid)Use the Guid of permission, resource, and org to obtain the valid operations of Org on this resource. HasOperation (String operationGuid): booleanThe passed operationGuid indicates whether the operation permission is granted. 5 Permission implementation:1. form-based authentication, which is commonly used. However, when a user arrives at a resource that is not authorized to access, the Web Container sends out an html page and requires the user name and password to be entered. 2. filter is used to prevent users from accessing some unauthorized resources. The Filter intercepts all requests/Response and places a verified identity in the user's Session, then, the Filter determines whether to allow Response each time based on this identifier. This mode is divided into two types: Keeper: Filter or Servlet. Authenticator: Use JAAS to implement it on the Web. Filter interception only blocks whether the user has the permission to access the page or the resource. The real post-display interception is performed inside the application. API is provided for display interception. Http://blog.csdn.net/huanghanzzz2006/article/details/1429666