User authentication management design
1 design idea
In order to design a set of user authentication management with strong scalability, database tables such as users, roles, and permissions are required, and the relationship between the establishment is, which is implemented as follows.
1.1 users
Users are just a pure user, used to record user-related information, such as user name, password, etc., permissions are separated. The user (user) must have permission to a certain resource, must be associated with a role (Role).
Users typically have the following properties:
ü No number is unique in the system.
ü Name, unique in the system.
ü User password.
ü Note, describe the information of the user or role.
1.2 role
The role is the basic unit of the use of permissions, with a certain number of permissions, give user permissions through the role, usually with the following properties:
ü No number is unique in the system.
ü Name, unique in the system.
ü Comment, describe role information
1.3 permission
Permission refers to the user's operation of some functions of the program based on the role, such as reading, writing, modifying, and deleting functions for files, usually with the following properties:
ü No number is unique in the system.
ü Name, unique in the system.
ü Note, describe the permission information
1.4 Relationship between users and roles
A user (user) can be partially affiliated to multiple roles, one character group can also have multiple users, and the user role is used to describe the objects of the affiliated relationship between them. User (USER) has permission to a certain resource through the role association, for example
l Users:
Userid UserName Userpwd
1 three xxxxxx
2 Li Si XXXXXXXXXX
......
l role (Role):
RoleId Rolename Rolenote
01 System Administrator Monitoring System Maintenance Administrator
02 monitor personnel online monitor personnel
03 dispatcher dispatched staff
04 general staff staff
......
l User 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 person"
3 2 03 Users "Li Si" is assigned to the role "dispatcher"
......
As can be seen from this relational table, the particular resource owned by the user can be associated with the user role.
1.5 Permissions and Roles A Role (Role) can have multiple permissions, and the same permissions can be assigned to multiple roles. E.g:
l role (Role):
RoleId Rolename Rolenote
01 System Administrator Monitoring System Maintenance Administrator
02 monitor personnel online monitor personnel
03 dispatcher dispatched staff
04 general staff staff
......
l Permission:
Permissionid Permissionname PermissionNote
0001 Add Monitoring Allows to add monitoring objects
0002 Modify Monitor Allows Modify Monitoring Objects
0003 Deleting Monitor Allow Delete Monitoring Objects
0004 Viewing monitoring information allows the monitoring object to be viewed
......
l Role permissions (Role_Permission):
Rolepermissionid RoleId PermissionId RolepermissionNote
1 01 0001 Role "System Administrator" has permission "Add Monitor"
2 01 0002 Role "System Administrator" has permission "Modify Monitor"
3 01 0003 Role "System Administrator" has permission "Delete Monitor"
4 01 0004 Role "System Administrator" has permissions "inspection monitoring"
5 02 0001 Role "Monitoring person" has permission "increase monitoring"
6 02 0004 Role "Monitoring person" has permission "inspection monitoring"
......
It can be seen from the role permission relationship in the above examples that role permissions can establish correspondence between roles and permissions.
1.6 establish user permission
The core of the user rights system is composed of the following three parts: creating permissions, allocation permissions and access rights.
The first step is created by Creator (Permission), Creator will divide when designing and implementing a system. Use the stored procedure CREATEPERMISSIONFO (@ permissionname, @ permissionnote) to create permission information, specify which permissions have the system module.
The second step is created by the system administrator, and specifies the association between user-role and role-permission.
1) Administrator has the function of creating users, modifying users, and deleting users: l Store process CreateUserInfo (@ username, @ userpwd) creates user information;
l Store process modifyuserinfo (@ username, @ userpwd) Modify user information;
l Storage procedure deleteuserinfo (@Userid) Delete user information;
2) Administrator has the function of creating roles and delete roles:
l Store process createroleinfo (@ rolename, @ rolenote) Create role information;
l Storage procedure deleteroleinfo (@roleid) deletes role information;
3) Administrator has the relationship between the establishment of users and roles, roles, and permissions:
l Storage Procedure GrantUserRole (@ userid, @ roleid, @ userrolenote) establishes the association relationship between users and roles;
l Storage Procedure DeleteUserRole (@USERROLLEID) Delete the association relationship between users and roles;
l Storage Procedure GrantrolePermission (@ roleid, @ permissionid, @ rolepermissionnote) establishes roles and permissions;
l Storage procedure Deleterolepermission (@RoePermissionID) Delete the relationship between roles and permissions;
The third step user (USER) uses the permissions assigned to the Administrator to use each system module. Use the stored procedure getUserrole (@Userid, @USERROLLEID OUTPUT), GetrolePermission (@ roleid, @ role-
-Permissinid output) obtains the user's use permission to the module.
1.7 user authentication implementation
When the user passes the verification, the system automatically generates a 128-bit Ticketi to save to the user database table, establish a stored procedure login (@ userid, @ userpwd, @ ticketid output) for user authentication, authentication by getting a ticketid, otherwise TicketID is NULL. The flow charts are as follows:
Figure 1 Login flow chart
After getting TicketID, the client passes the TicketID when calling the server method, and judges the permissions of the user corresponding to the TicketID by storing JudgeticketPermission (@ ticketid, @ permissionid), and is called according to its permissions.
When the user exits the system, establish a stored procedure logout (@USERID) to exit the system. When the user is abnormally exits the system, determine the user's TickeID according to the last login time (Lastsigntime), establish the abnormality of the stored procedure ExceptionLogout (@ userid, @ lastsigntime) to handle the user's exception exit.
Figure 2 Logout flow chart
WebService can write TicketID in SoapHead to make TicketID to the server from the client. .NET Remoting can use the CallContext class to implement TicketID to the server from the client. 2 database design
2.1 Database Table
Figure 3 Database relationship diagram
2.2 Database Table Description
2.2.1 User Table (static_user)
Static_user
Static_user field name detailed explanation Type Remarks Userid route number VARCHAR (20) PK Username User Name VARCHAR (20) Userpwd User Password VARCHAR (20) Lastsigntime Last Land Dataime SignState User Login Status Tag INT Tickeid Verification Ticket Number VARCHAR (128)
2.2.2 Role table (static_role)
Static_Role
Static_user field name detailed explanation Type Remarks RoleId Role Number VARCHAR (20) PK ROLENAME Role Name VARCHAR (20) ROLENOTE Role Information Description VARCHAR (20)
2.2.3 User - Role Table (static_user_role)
Static_user_role
Static_User field name detailed explanation Type Note Userroleid User Role Number VARCHAR (20) PK Userid User No. VARCHAR (20) FK RoleId Role Number VARCHAR (20) FK UserRolenote User Role Information Description varchar (20)
2.2.4 Permissions Form (static_persirsion)
Static_Permission
Static_user field name detailed explanation Type Remarks PermissionID number VARCHAR (20) PK Permissionname Permissions Name VARCHAR (20) Permissionnote holographic information Description varchar (20)
2.2.5 Role - Permissions Table (static_role_permission)
Static_Role_Permission
Static_user field name detailed explanation type Remarks RolepermissionID Role Permissions No. VARCHAR (20) PK RoleId Role Number VARCHAR (20) FK Permissionid Permissions No. VARCHAR (20) FK Rolepermissionnote Role Permission Information Description VARCHAR (20)
3 .NET technology summary
3.1 WebService SoapHeader
Perform custom authentication and authorization for SQL databases. In this case, custom credentials (such as user names and passwords) should be passed to the service, and the service will handle authentication and authorization. The simple way to pass additional information along with the request to the XML web service is through the SOAP header. To do this, you need to define a class derived from the SOAPHEADER in the service, and then declare the public field of the service as that type. This is disclosed in the public contract of the service, and can be used by the client when creating a proxy from the WebServiceutil.exe, as shown in the following example:
Using system.Web.services;
Using system.web.services.protocols;
// Authheader Class Extends from SoapHeader
Public class authheader: soapheader {
Public String Username;
Public String Password;
}
Public Class Headervice: WebService {Public Authheader Sheader;
...
}
Each WebMethod in the service can define a set of associated headers using the SoapHeader custom property. By default, the header is required, but it can also define a selection header. The SoapHeader property specifies the name of the public field or the properties of the Client or Server class (called the headers attribute in this title). Before the input header is called method, the WebService sets the value of the headers attribute; and when the method returns the output header, the WebService retrieves the value.
[WebMethod (Description = "this Method Requires a Custom SOAP Header Set by the Caller"]]
[SoapHeader ("Sheader")]]]
Public string securemethod () {
IF (Sheader == Null)
Return "Error: Please Supply Credentials";
Else
Return "User:" Sheader.userName;
}
Then, the client sets the header directly on the proxy class before calling the required header, as shown in the example below:
Headerservice h = new headervice ();
Authheader myHeader = new authheader ();
MyHeader.userName = "Username";
MyHeader.Password = "password";
H.AuthHeader = myheader;
String result = H. SecureMethod ();
3.2 .NET Remoting security authentication
CallContext provides a set of property sets transmitted with the execution code path, and CallContext is a dedicated collection object similar to the thread locally stored by the method and provides a data slot that is unique to each logic execution thread. The data slot is not shared between the call context on other logical threads. When the CallContext propagates along the execution code path round-trip and by each object in the path, the object can be added therefrom. When a remote method is called for an object in another AppDomain, the CallContext class will generate a LogicalCallContext instance that propagates together with the remote call. Only objects that are publicly ILogicalthReadaffInative interfaces are stored in CallContext are propagated outside the LogicalCallContext to Appdomain. Objects that do not support this interface are not transmitted along with the remote method call in the LogicalCallContext instance.
The CallContext.SetData method stores a given object and associates it with the specified name, and the CallContext.getdata method retrieves an object with the specified name from the callcontext.
The following code example shows how to use the setData method to transfer the main body and the identifier object to the remote location for identity.
Public class clientclass {
Public static void
MAIN () {
GenericIdentity Ident = New GenericIdentity ("Bob");
GenericPrincipal prpal = new genericprincipal (Ident,
Newstring [] {"Level1"});
LogicalCallContextData Data = New LogicalCallContextData (prpal);
// Enter Data Into the CallContext
CallContext.SetData ("Test Data", DATA);
Console.writeline (data.numofaccesses);
ChannelServices.RegisterChannel (New Tcpchannel ());
RemotingConfiguration.registerActiVatedClientType
TypeOf (HelloServiceClass), "TCP: // localhost: 8082");
HelloserviceClass Service = new helloserviceclass ();
IF (service == null) {
"" "COULD NOT Locate Server.");
Return;
}
// Call Remote Method
Console.writeLine ();
Console.writeline ("Calling Remote Object");
Console.Writeline (Service.hellomethod ("Caveman"));
Console.writeline (Service.hellomethod ("Spaceman"));
Console.writeline (Service.hellomethod ("Bob"));
Console.Writeline ("Finished Remote Object Call");
Console.writeLine ();
// Extract the return data from the call context
LogicalCallContextData ReturnedData =
(LogicalCallContextdata) CallContext.getdata ("Test Data");
Console.writeline (data.numofaccesses);
Console.writeLine (ReturnedData.Numofaccesses);
}
}
The following code example shows how to transmit the main body and the identifier object to the remote location using the getData method for identity.
Using system;
Using system.text;
Using system.runtime.remoting.Messaging;
Using system.security.principal;
Public Class HelloServiceClass: MarshalByrefObject {
Static int N_INSTANCES;
INT Instancenum;
Public helloserviceclass () {
N_INSTANCES ;
Instancenum = n_instances;
Console.writeline (this.gettype (). Name "HAS Been Created.
Instance # = {0} ", instanceenum);
}
~ Helloserviceclass () {
Console.writeLine ("Destroyed Instance {0} of
HelloServiceClass. ", Instancenum);
}
Public string hellomethod (string name) {
// Extract the call context datalogicalcallcontextdata data =
(LogicalCallContextdata) CallContext.getdata ("Test Data");
Iprincipal myprincipal = data.principal;
// check the user identity
IF (MyPrincipal.Identity.Name == "Bob") {
Console.writeline ("/ NHELLO {0}, you are identified!",
Myprincipal.Identity.name);
Console.writeline (data.numofaccesses);
}
Else {
Console.writeline ("Go Away! You are not Identified!");
Return string.empty;
}
// Calculate and return Result to Client
Return "Hi There" Name "."
}
}
4 detailed code design
4.1 WebService Code Design
The WebService End code mainly performs the operation of the database, establishing the method you need to operate the Client Operation Database for the client's end call.
1) Class userInfomng () User Information Management Class, which includes methods:
l CreateUserInfo (String User String UserPwd) establishes user information, calls stored procedure CreateUserInfo (@ UserName, @ UserPwd)
l ModifyUserInfo (String UserName String Userpwd) Modify User Information, calls stored procedure modifyuserinfo (@ username, @ userpwd)
l DeleteUserInfo () Delete user information, call the stored procedure deleteuserinfo
(@Userid)
2) Class UserageHAThentication () User authentication class, used to implement user roles, permissions settings, including methods:
l createpermissionInfo (String Permissionname String Permissi)
-onnote) Establish permission information, call the stored procedure CreatePermissionInfo
(@ Permissionname, @ permissionnote)
l CREATEROLEINFO (STRING ROLENAME STRING ROLENOTE) establishes role information, calls stored procedure Createroleinfo (@ RoleName, @ Rolenote)
l Deleteroleinfo () Delete role information, call the stored procedure Deleteroleinfo
(@Roleid)
l GrantUserRole (String Userid String Roleid String Userrolenote) Grants the user role, calls the stored procedure grantuserrole (@ userid, @ roleid,
@USERROLENOTE)
l DeleteUserRole () Delete the user role, call the stored procedure deleteuserrole (@USERROLEID)
l GrantrolePermission (String RoleId String PermissionID String Rolepermissionnote grants role permissions, calling stored procedure grantrolepermission (@ roleid, @ permissionid, @ rolepermissionnote)
l DeleterolePermission () Delete the granted role permissions, call the stored procedure
Deleterolepermission (@RoepermissionID)
4.2 User Certification Code Design (Client End)
The Client end calls the WebService method to perform database access, the client code design mainly implements the functionality of the interface, including: permission setting, user management, user authorization management, user authentication management
1) Permission settings
Class PermissionInFomng () User Rights Information Management Class, including methods:
l createpermissionInfo () Establish permission information
2) User Management
Class userInfomng () User information management class, including methods:
l createUserInfo () build user information
l ModifyUserInfo () Modify User Information
l DeleteUserInfo () Delete User Information
3) User authorization management
Class roleinfomng () Role information management class, including methods:
l createRoleinfo () Establish role information
l Deleteroleinfo () Delete role information
Class Userrolemng () User Role Management Class, including methods:
l GrantUserRole () grant user role
l DeleteUserRole () Delete User Roles
Class RoleperMissionMng () Role Permission Management Class, including method
l grantrolepermission () grant role permissions
l DeleteroleperMission () Delete Role Permissions
4) User Certification Management
Class Authentication () User authentication class, including methods:
l login (String User String Userpwd) User Login Certification, user authentication is assigned to a Ticketid, otherwise TicketID is NULL
l logout () users have normal exit
l ExceptionLogout () user exception exits
