Java Web Project Rights Management



Method One, SPRINGMVC integration Shiro (Shiro is a powerful authority management framework)

Http://www.360doc.com/content/14/0529/09/11298474_381916189.shtml

Method Two, role-based access rights control

Role-based access rights control
Less nonsense, the theory of things do not want to say more, online a lot, I have to point to the actual.
First, role-based access control, all user access will be filtered, and then analyzed access rights to be authenticated.
The focus of the permissions, the design of the table.

Universal three tables, table name customization. User table (users), Roles table (role), Resource table (Resource)

User tables are not special, very simple. The key is the role table and the Resource table.


Table Structure Overview


Data tables


Role table



User table




Resource table
One of the key fields in the role table, access levels (level)
This field directly controls which table information the role is able to access, such as mobile and unicom data in a single datasheet, and access levels can control the role to access only one of them.


Key fields in the Resource table: Authorityname and ResourceUrl:
A URL can correspond to multiple authorityname, but a authorityname can only correspond to one url,url access can be defined as requiring multiple or individual permissions.
The relationship between these three sheets is many-to-many.
That is, a user can have multiple roles, and a role can access multiple resources. In specific cases, we can associate user tables and resource tables, assigning specific resource access to users.


In addition, we want to add the access level field to the datasheet. Used to determine whether the access role has that level.

First, do not frame handwriting permission control, the basic process is as follows
Write a Pojo class that defines a map<string,collection<string>> collection. The role is used to pair resources and permissions.
Configure a servlet to load the permissions at the start of the container and pair the ResourceUrl in each resource with the Authorityname (permission name) through the Resource table's data information. The resourceurl here may correspond to multiple permissions, so the collection collection within the Map collection is used to configure multiple permissions, which need to match all permissions within the collection. So the URL can be entered repeatedly into the database, but the permissions can not be repeated.
Authoritydatamap, this class is used to store permission information after a permission match, and is a collection of all permissions for the project. Cached in the servlet context.
Userauthoritymanager This class defines the information that a login user requests for registration, such as: User name, role Group, login information, etc. is cached in the servlet container after logging in. Validation of permissions when user accesses.
Implement a filter, Accessdecider, this is an access to the decision maker, mainly used for the current user access to the resources for authentication and permission matching, the compliance is passed, does not comply with the rejection.
Implement a filter, Authorityfilter, which filters all requests of the user. Matches the filtered request to the set of permissions cached in the Authoritydatamap in the servlet, and, if found, traverses the current user right in Userauthoritymanager to match. When querying, you also need to check the user's access level, which is the role level, to show different data according to the level.
All, and finally comb the process:
1, service starts, Authoritydatamap starts loading all permissions
2,userauthoritymanager User logon Load User rights
3AuthorityFiler filter all requests → forwarding to accessdecider to do the right judgment → according to the results of the corresponding success or failure to jump.

Method Three, proposed RBAC permission model

NIST (national Institute of Standards and Technology, American Institute of Standards and Technology) The standard RBAC model consists of 4 component models, each of which is a basic model RBAC0 (Core RBAC) , Role classification Model RBAC1 (hierarchal RBAC), role restriction model RBAC2 (Constraint RBAC) and unified Model RBAC3 (combines RBAC) [1]. The RBAC0 model is shown in Figure 1.


RBAC 0 Model
RBAC0 defines the smallest set of elements that can form a RBAC control system.
In RBAC, there are five basic data elements including user users, role ROLES (ROLES), target objects (OBS), Operation Operations (OPS), license permissions (PRMS), and permissions are assigned to roles. Instead of a user, when a role is assigned to a user, the user has the permissions that the role contains. The session sessions is a mapping between the user and the activated role collection. The difference between RBAC0 and traditional access control is that adding a layer of indirection brings flexibility, RBAC1, RBAC2 and RBAC3 are all extensions in the RBAC0.

RBAC1 introduces the inheritance relationship between roles
The inheritance relationship between roles can be divided into general inheritance relationship and limited inheritance relationship. The general inheritance relationship only requires that the role inheritance relationship be an absolute partial order, allowing multiple inheritance between roles. A restricted inheritance relationship further requires that the role inheritance relationship be a tree structure.

The RBAC2 model adds a liability separation relationship
RBAC2 constraints specify the mandatory rules that should be followed when permissions are assigned to a role, or when a role is assigned to a user, and when a user activates a role at some point in time. Separation of responsibilities includes static separation of responsibilities and dynamic separation of responsibilities. The constraint, together with the user-role-permission relationship, determines the access permissions of the user in the RBAC2 model.
L RBAC3 contains RBAC1 and RBAC2.
It provides both the inheritance relationship between roles and the separation of responsibilities.

Create a Role definition table. Set the roles in the current system.
Because of the problem of inheritance, the role embodies a tree-shaped structure.



Thought:
The core of the authority system consists of the following three parts: 1. Create authority, 2. Assign permissions, 3. Use permissions, then, the main participants in each part of the system are compared as follows: 1. Create authority-Creator creation, 2. Assigning Permissions-Administrator assignment, 3. Use Permissions-User:
1. Creator Create privilege, Creator in the design and implementation of the system will be divided, a subsystem or called modules, what should have permissions. Here is the privilege and Resource of the object statement, and did not really connect privilege with the specific Resource instance, to form a Operator.
2. The Administrator specifies the association of privilege with Resource Instance. In this step, permissions are actually associated with resource instances, resulting in Operator (privilege Instance). The Administrator uses the basic element of Operator to create his ideal privilege model. For example, create a role, create a user group, assign a user to a user group, associate a user group with a role, and so on ... These operations are done by the Administrator.
3. User uses the permissions assigned by the Administrator to use each subsystem. The administrator is the user, in his mind has a more suitable for his management and maintenance of the rights model. As a result, programmers just answer a question, what permissions can access what resources, that is, the previous Operator. The programmer's offer of Operator means putting armor on the system. The administrator can build what he wants to do according to his wishes. The framework of permissions can be increased, deleted, and managed Resource and privilege relationships. You can set the corresponding relationship between user and role roles. (If you treat Creator as the inventor of basic, the Administrator is the user of basic, he can do some scripted programming) Operator is the most critical part of the system, and it is a bond, a tie between programmer, the Administrator, and the User.



Detailed content in http://info.codepub.com/2008/05/info-19368.html

Methods Four, refer to the OA project of the Still Academy

http://bbs.csdn.net/topics/300237764, there's a mention inside.