Implementation of a universal rights management system using RBAC model

　　This paper mainly describes a general permission system to realize the idea and process. This is also a summary of the production Rights Management module.

The purpose of this system is to make this permission system "generic". is to produce a web system by invoking this permission system (the generated DLL file), you can implement rights management. This

The system will manage all the users, menus, action items, role assignments, rights assignments, logs and other contents of the production system.

This feature is implemented from two aspects of normal access and illegal access. Normal access means that users can only see or manipulate their own menus after they log on to the system, and illegal access is accessed through a spelling URL

Integration of a function, so the program in addition to the user login to obtain user-owned menu permissions, but also to block the user's illegal request. Both are indispensable.

I. Concept

The implementation of this function is mainly based on RBAC permissions design model, the English (role-based access Control) is translated into role-based rights management, also called role-based access control.

Two. Database design

1. system table: This table records each system because it is "generic". Other users, menus, actions, and permissions tables each record will correspond to the system code.

Field Description:code-> System Identification code

sysname-> system Name

2. Menu table: Record menu. Each function as a menu, the menu has a URL attribute, the user by clicking on the menu to access the corresponding function;

Field Description:id-> primary key, self-increment identity

Menuname-> Menu Name

pageurl-> menu corresponding URL

Pid-> Menu Parent ID

Lv-> Menu level, sub-level menu and Level two menu

Controlleraction-> menu Unique identifier, used to do permission control

Systemcode-> System Identification Code

3. Operation table: This table is mainly to determine whether the user has to operate a specific function, such as the commonly used "delete" function and other operations are placed in this table;

Field Description:id-> primary key, self-increment identity

Opratename-> operation name

Operatecode-> Operation Identification Code

Systemcode-> System Identification Code

4. User table: Record the users of all systems. Record user account, password and other information;

Field Description:id-> primary key, self-increment identity

Username-> User Login Name

Userpwd-> User Login Password

Systemcode-> System Identification Code

5. Role table: This is an indispensable RBAC design, record role information, different levels of roles have different permissions. Assigning a role to a user also uses it;

Field Description:id-> primary key, self-increment identity

rolename-> role Name

Systemcode-> System Identification Code

6. Permission table: holds the user's permission information. In this system my design is each menu, each operation corresponds to a permission record. So there is a field [ActionType] to distinguish between a menu or an operation;

Field Description:id-> primary key, self-increment identity

Powername-> Permission Name

Actionid-> menu or Action ID

Actiontype-> is a menu or action

Systemcode-> System Identification Code

7. User-Role table: This table is responsible for associating user and role relationships. Because the RBAC model is used for the first time and is used quickly, a one-to-many role is not considered in this use. So

In this system, the user and the role are all one-to-a-person relationship, each user corresponds to a role;

Field Description:id-> primary key, self-increment identity

Userid-> User ID

roleid-> role ID

Systemcode-> System Identification Code

8. Role-Corresponding Permissions table: This table is responsible for managing roles and permissions relationships. Roles and permissions belong to a one-to-many relationship, and each role corresponds to multiple permissions;

Field Description:id-> primary key, self-increment identity

roleid-> role ID

Powerid-> Permission ID

Systemcode-> System Identification Code

9. Log table: This should be easy to understand, log table records the user's operating system traces, such as user information, access URL, time and so on.

Field Description:id-> primary key, self-increment identity

Userid-> operation name

Visiturl-> Operation Identification Code

Remark-> System Identification Code

Createtime-> creation Time

Systemcode-> System Identification Code

Three. Program Design

The above said the structure of the database, the next talk about the design of the program. The beginning has been mentioned in order for the general purpose of this project to generate DLL files for other system calls, of course, you can also be made

WebService, can also meet cross-platform.

This system does not have a common data access layer and business logic layer with any business systems. Even if the two use the same database, the system has a separate data access layer and a business logic layer,

when then This situation limited to one "permissions backend" that implements rights management.

here I used three layers and added an interface service. Other systems can only access this interface to invoke the methods they need. This is useful for the system itself to avoid any

to achieve diameter varies. The user is also concise and clear. To achieve this, you can use the keyword internal to decorate the classes of the data access layer and the business logic layer . Program structure such as:

　　Go ahead and talk about what methods and properties this interface provides.

1. Current login User: In the system in many places to use it, such as display login user's account, role, etc., storage login users can use the session, but also use Redis;

2. Login/exit method;

2. Login user has access to the menu collection: Provide users with normal access to the menu, such as the tree menu;

3. Sub-Menu Collection: Method 2 can also be achieved, this is just one more service;

4. How to determine the operation permissions: The database has an action table, through the operation code to the permission table query. Determine whether the login user has permission to an operation, such as "delete" function;

5. Log collection: To meet the needs of each system to view the log.

Four. Permissions and logs

the privilege here is to block access to the non-normal path. The realization of the idea is that the user access to the URL with the user can access the menu properties "Controlleraction" one by one contrast. For Ease of understanding,

Use the development examples here to illustrate :

when I was working on a business system, the UI framework was MVC4.0, and he supported filter very well. Therefore, a filter folder is added to the three layer of the permission system, creating the Powerattribute class , providing validation

Login and verify permissions two classes.

[AttributeUsage (AttributeTargets.Method, AllowMultiple =false)]     Public classLoginattribute:actionfilterattribute {/// <summary>Login Verification</summary>        /// <param name= "Filtercontext" ></param>         Public Override voidonactionexecuting (ActionExecutingContext filtercontext) {varLoginuser =Userservice.loginuser; Base.            OnActionExecuting (Filtercontext); if(Loginuser.id <=0) {Filtercontext.result=NewRedirectresult ("/home/login");            FilterContext.Result.ExecuteResult (Filtercontext); }        }    }

[AttributeUsage (AttributeTargets.Method, AllowMultiple =false)]     Public classPowerattribute:loginattribute {/// <summary>Authentication of access rights</summary>        /// <param name= "Filtercontext" ></param>         Public Override voidonactionexecuting (ActionExecutingContext filtercontext) {Loginattribute Loginattribute=NewLoginattribute ();            Loginattribute.onactionexecuting (Filtercontext); varRouteaction = httpcontext.current.request.requestcontext.routedata.values["Controller"] +"."+
httpcontext.current.request.requestcontext.routedata.values["Action"]; List<Menu> userownmenulist = Menuservice.getuserownmenulist (). Resultmodel asList<menu>??NewList<menu>(); varIshavepermission = Userownmenulist.firstordefault (M = m.controlleraction.tolower () = = Routeaction.tolower ())! =NULL; if(!ishavepermission) {HttpContext.Current.Response.Write ("you do not have permission to access");            HttpContext.Current.Response.End (); }        }    }

When accessing the user list, simply add the attribute power to the corresponding action.

    // GET:/user/list     // User List Page     [Power]    " View user list ")]      Public ActionResult List (string""int1)

The log is implemented as above, no longer described. The whole text is too much, there is no code to implement the interface, because the implementation of these methods are very basic. Inconvenience of presentable.

Implementation of a universal rights management system using RBAC model