1 Design ideas
In order to design a set of user authentication management with strong scalability, it is necessary to establish database tables such as users, roles and permissions, and establish the relationship between them. The specific implementation is as follows.
1.1 Users
Users are just pure users, used to record user-related information, such as user names, passwords, etc., and the permissions are separated. To have permissions to a resource, a user must be associated with a role.
Users typically have the following attributes:
ü number, unique in the system.
ü Name, unique in the system.
ü User password.
ü Comments that describe the user or role.
1.2 Roles
A role is the basic unit of use rights, with a certain number of rights, and user rights are granted through roles, usually with the following attributes:
ü number, unique in the system.
ü Name, unique in the system.
ü Comments describing role information
1.3 Permissions
Permissions refer to the user's access to certain functions of the program according to the role, such as the read, write, modify and delete functions of files, and usually have the following attributes:
ü number, unique in the system.
ü Name, unique in the system.
ü A comment describing the permission information
1.4 Relationship between users and roles
A user (User) can belong to multiple roles (Role), and a role group can also have multiple users. A user role is an object used to describe the affiliation between them. A user (User) associates the permissions to a certain resource through a role (Role), such as
l User:
UserID UserName UserPwd
1 sheet three xxxxxx
2 Lee Four xxxxxx
……
l Role:
RoleID RoleName RoleNote
01System administrator monitoring system maintenance administrator
02 Monitoring personnel online monitoring personnel
03 Dispatcher dispatch staff
04 General Staff Staff
……
lUser role ( User_Role ):
UserRoleID UserID RoleID UserRoleNote
1 1 01 User " Zhang San " is assigned to the role " System Administrator "
2 2 02 User " Li Si " is assigned to the role " Monitor "
3 2 03 User " Li Si " is assigned to the role " Scheduler "
……
As can be seen from this relationship table, the specific resources owned by the user can be related by the user role.
1.5 The relationship between permissions and roles
A role (Role) can have multiple permissions (Permission), and the same permission can be assigned to multiple roles. E.g:
l Role:
RoleID RoleName RoleNote
01System administrator monitoring system maintenance administrator
02 Monitoring personnel online monitoring personnel
03 Dispatcher dispatch staff
04 General Staff Staff
……
l Permission:
PermissionID PermissionName PermissionNote
0001 Increase monitoring allows to increase monitoring objects
0002 Modify monitoring allows modifying monitoring objects
0003 Delete monitoring allows to delete monitoring objects
0004 View monitoring information allows viewing monitoring objects
……
l Role permissions (Role_Permission):
RolePermissionID RoleID PermissionID RolePermissionNote
1 01 0001 Role " System Administrator " has permission " Add Monitoring "
2 01 0002 Role " System Administrator " has permission " Modify Monitoring "
3 01 0003 role " system administrator " has permission " delete monitoring "
4 01 0004 Role " System Administrator " has permission " View Monitoring "
5 02 0001 Role " Monitor " has permission " Add Monitoring "
6 02 0004 The role " Monitor " has the permission " View Monitoring "
……
It can be seen from the role permission relationship in the above example that the role permission can establish the corresponding relationship between the role and the permission.
1.6 Establish user permissions
The core of the user rights system consists of the following three parts: creating rights, assigning rights and using rights .
The first step is to create permissions (Permission) by the Creator, which will be divided by the Creator when designing and implementing the system. Use the stored procedure CreatePermissionInfo (@PermissionName, @PermissionNote) to create permission information to specify which permissions the system module has.
In the second step, the system administrator (Administrator) creates users and roles, and specifies the relationship between the user roles (User-Role) and the role permissions (Role-Permission).
1) It has the functions of creating users, modifying users and deleting users: Administrator
l The stored procedure CreateUserInfo (@UserName, @UserPwd) creates user information;
l The stored procedure ModifyUserInfo (@UserName, @UserPwd) modifies user information;
l The stored procedure DeleteUserInfo (@UserID) deletes user information;
2) Has the function of creating roles and deleting roles: Administrator
l The stored procedure CreateRoleInfo (@RoleName, @RoleNote) creates role information;
l The stored procedure DeleteRoleInfo(@RoleID) deletes role information;
3) Administrator has the function of establishing association relationship between users and roles, roles and permissions:
l The stored procedure GrantUserRole (@UserID, @RoleID, @UserRoleNote) establishes the association between users and roles;
l The stored procedure DeleteUserRole(@UserRoleID) deletes the association between users and roles;
l The stored procedure GrantRolePermission(@RoleID,@PermissionID,@RolePermissionNote) establishes the association between roles and permissions;
l The stored procedure DeleteRolePermission(@RolePermissionID) deletes the association between roles and permissions;
The third step User (User) uses the permissions assigned by Administrator to use each system module. Using stored procedures GetUserRole(@UserID, @UserRoleID output), GetRolePermission(@RoleID, @Role-
-PermissinID output) to obtain the user's permission to use the module.
1.7 User Authentication Implementation
When the user passes the verification, the system automatically generates a 128-bit TicketID and saves it to the user database table, and establishes the stored procedure Login (@UserID, @UserPwd, @TicketIDoutput) for user authentication. After the authentication passes, a TicketID is obtained, otherwise the TicketID is null . Its flow chart is as follows:
Figure 1 Login flow chart
After getting the TicketID, the client passes the TicketID when calling the server method, judges the permissions of the user corresponding to the TicketID through the stored procedure JudgeTicketPermission (@TicketID, @PermissionID), and calls the method according to its permissions.
When the user logs out of the system, create a stored procedure Logout (@UserID) to log out of the system. When the user exits the system abnormally, determine the user's TicketID according to the last login time (LastSignTime), and establish a stored procedure ExceptionLogout (@UserID, @LastSignTime) to handle the user's abnormal exit.
Figure 2 Logout flow chart
WebService can use SoapHeader to write TicketID to make TicketID passed from client to server. .Net Remoting can use the CallContext class to pass the TicketID from the client to the server.