An open-source security certificate logon component-secuser

Design, development: Xiao Bo

Page: Gu Xiaoyan

Artist: Sun Yingying

2007-8

Introduction

Security Certificate logon component secuser, which is short for "secuser. This component encapsulates the certificate management, verification, and security authentication functions of the Web application system after logon, providing developers with a convenient and easy-to-use and highly scalable Security Certificate System Support Platform.

Architecture

 

Figure 1 system architecture of the security certificate logon component

 

 

 

The secuser component consists of the following components:

User Terminal Components

Logon: this component runs on a terminal and provides a winform logon interface and certificate management functions. Developers can modify the logon Component Interface and cropping functions as needed.

 

Figure 2 logon page

Secuser. Remote. Client component: This component provides interfaces for terminal and server certificate management operations.

 

Figure 3 Relationship Diagram of secuser. Remote. Client components

User terminal component Summary

The user terminal component runs on the user terminal and provides terminal-side Certificate Management, user logon, and browser container after logon. The user terminal component provides interfaces bound to the user terminal, you can bind a certificate to a terminal by means of machine code or software dog, so that you can only run the software on a specified machine.

Webserver Components

Secuser. Remote. Server Component: This component provides responses to user-side Certificate Management and encapsulation of page security verification.

Figure 4 Relationship Diagram of secuser. Remote. Server Components

 

The secuser. Remote. server component consists of ccertserver, cbasepage, and ctestbasepage.

Ccertserver is used to process Certificate Management responses. cbasepage provides webpage security verification. All pages that require security verification must be inherited from cbasepage, cbasepage verifies whether the current page is called by the current logon user through a token. The cbasepage class can also provide the certificate ID, user ID, and other basic information of the current user to the derived page, and provide a userinfo interface to access the information of the current user on the page.

For the sake of security, all pages requiring security verification must be executed in the browser container of the logon component on the terminal, which makes software debugging difficult, to facilitate developers to debug the software in the development stage, secuser. remote. the server component provides a ctestbasepage class. during development, the interface can be inherited from this class. This class provides the same attributes as the basepage class, but does not perform security verification, the derived class can modify the protection attribute of the ctestbasepage class to set different values for debugging. This class only exists in the debug version.

Isecuser interface component: the secuser component is a highly scalable certificate security system platform. The Platform Framework does not limit user implementation, but only provides implementation interfaces, you can design any implementation method that meets your needs. The Open Source Code provides the implementation components secuser. Cert and secuser. user for the interface. These two components are just an example. You can compile your own interface implementation without using these two components.

 

 

Figure 5 isecuser interface component class relationship diagram

Call the icertmanage interface to create a certificate

Use the iuserpassword interface to verify the user name and password

Access global variables through the iglobalcfg Interface

Iusercertmanage interface for Certificate Management

The iuserpassword interface is the only interface associated with the user system in the component. developers generally need to implement this interface to verify the legality of user identity from the developer user system, the User ID assigned to the user is returned.

Note that there are two user IDs in the system. One is the user ID of the User System and the other is the user ID of the certificate system. These two IDs are not one, the user IDs used in the entire certificate system are the user IDs of the certificate system, rather than the user system user IDs, the User ID of the user system is only used to operate the user system on the user page derived from the cbasepage class.

Secuser. Cert component: this component implements the certificate system interface icertmanage, iglobalcfg, iusercertmanage. This component is just an example. If the developer has no special requirements, this example can meet the developer's needs. It can be used directly without modification.

Secuser. User component: this component implements the iuserpassword interface of the user system. This component is just an example. The developer's user system is certainly not the user system in the example. Therefore, this component is to be rewritten in general, and the developer must rewrite this component to connect to the developer's own user system.

Configuration and deployment

Terminal component configuration

Configure the terminal components as follows:

Static Configuration:

Developers need to configure static attributes of the logon component based on their own system conditions.

The cgetconfig. CS file of the logon Project

Internal class t_staticcfg

{

Internal const string pai_file_name = "certcfg. xml"; // configuration file name

Internal const int cert_check_days = 30; // The number of days after the certificate expires.

Internal const string cert_subject = "cn = xxx"; // The Name Of The certificate subject, which must be the same

The names set on the server side are consistent.

Internal const bool need_identifier = false; // whether terminal identification code verification is required. If

Verification required. The cgetidentifier must be modified.

Identifier Property Code!

Internal const string default_remote_url =

"Http: // localhost: 2185/web/secuserface. aspx"; // default remote URL

Internal const int admin_page_width = 800; // The width of the administrator interface

Internal const int admin_page_height = 600; // The height of the administrator interface

Internal const int normal_page_width = 800; // width of the normal user interface

Internal const int normal_page_height = 600; // height of the normal user interface

}

Terminal verification code implementation

The cgetidentifier. CS file of the logon Project

Static string identifier

{

Get

{

// Insert the actual code for obtaining the terminal identifier

Throw new exception ("you must write code for Client Identifier! ");

}

}

This component only provides interfaces and does not provide specific implementation. You can add your own terminal identification code in the get block.

Webserver Configuration

Example database creation

Create a user database secuser and execute scripts under secuser. User \ SQL to create a table. As mentioned earlier, do not create a user database but use the user database of the developer.

Create the Certificate database cert and execute the script under secuser. Cert \ SQL.

Database Connection Configuration:

In connectionstrings of WEB \ WEB. config, configure the connection strings of the user database and Certificate database corresponding to the developer system.

<Connectionstrings>

<Add name = "secuser. cert. dal. data. connectionstring "connectionstring =" Data Source = (local); initial catalog = Cert; Integrated Security = true; Connect timeout = 30; "/>

<Add name = "secuser. user. dal. data. connectionstring "connectionstring =" Data Source = (local); initial catalog = secuser; Integrated Security = true; Connect timeout = 30; "/>

</Connectionstrings>

Makecert.exe program path Configuration:

Makecert.exe is an external program for the sample code user to generate a certificate. developers can create their own certificate code. If the sample code is used, you must configure the path of this component, and place the component in the corresponding path.

<Deleetask>

<Add key = "makecertpath" value =

"E: \ webcomponent \ v1.0bone \ secuser \ WEB \ bin \"/>

</Appsettings>

Certificate Management page home page Address Configuration

This configuration indicates the page to which the system first points after logging on as a certificate administrator.

If a framework exists on the homepage of the actual Certificate Management page, this page needs to be made a jump page pointing to the actual homepage. The same applies when a common user logs on to the home page.

<Deleetask>

<Add key = "adminhomepage" value =

"Http: // localhost: 2185/web/adminhomepage. aspx % 22/>

</Appsettings>

The preceding two configurations are in the deleettings section.

Interface implementation configuration

The interface must be implemented before it can be used. You can write your own interface implementation and enter the interface implementation code in the Web/app_code/instance. CS file.

The sample code is as follows. You can modify the code and add your own interface implementation.

Public instance ()

{

// Initialize Certificate-related interfaces

M_usercertmanage = new secuser. cert. BLL. cusercertmanage ();

M_globalcfg = new secuser. cert. BLL. cglobalcfg ();

M_certmanage = new secuser. cert. BLL. ccertmanage ();

M_usercertmanage.globalcfg = m_globalcfg;

M_usercertmanage.certmanage = m_certmanage;

// Initialize the user password verification Interface

M_userpassword = new secuser. User. BLL. cuserpassword ();

}

Deployment

Generate the first certificate Administrator

The First Certificate administrator can apply as a Super User without review. After completing the preceding configuration, the user runs the logon component and selects a user in the user system as the Super User such as admin, after clicking Apply for an administrator certificate, enter the user name and password of the selected super user. The certificate information has been used. The developer determines how to use the certificate information based on his or her own situation, after confirmation, you can generate the certificate of the first certificate administrator. This user will automatically

Install the user certificate on the user terminal and use the Certificate for user authentication.

The system can have multiple certificate administrators. Applications from other administrators except the first certificate administrator must be approved by other administrators before they can be used.

Global attribute Configuration

You can configure global properties after logging on as an administrator.

 

Note that the certificate topic must be consistent with the certificate in the terminal configuration; otherwise, the terminal will not be able to find the certificate.

User attribute Configuration

 

User List

 

User Certificate Management

 

User Property Management

 

Security

Several security suggestions

1. We recommend that you use SSL for the website. Currently, the version certificate cannot be used for SSL authentication. However, as this component has already been used for security verification, you only need to configure SSL with the server certificate, to achieve high security. In particular, we strongly recommend that you use SSL to configure webserver on the background management page.

2. We recommend that you compile the two components of your terminal into a strongly-named component to avoid modification.

3. We recommend that you perform obfuscation and other encryption on the logon component to prevent key configuration code from being easily decompiled.

4. We recommend that you use the release version when releasing components referenced by the Web server, especially secuser. Remote. server. dll. We strongly recommend that you use the release version for release.

Open source code
Http://files.cnblogs.com/eaglet/SecUser_V1.0.1.rar

 

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/mengyao/archive/2007/09/11/1781121.aspx