CN1152333C - Method for realizing portal authentication based on protocols of authentication, charging and authorization - Google Patents

Abstract

The present invention discloses a method for realizing portal authentication based on the protocols of authentication, charging and authorization. In the method, first of all, a user browses a portal website accessed to a provider by accessing an IP address via a network to obtain an authentication webpage, security information is input in the authentication webpage and sent to a portal server, the security information is assembled into an authentication request data packet which is sent to NAS according to a radius protocol after the portal server receives the information, and the NAS as an agent is used for sending the authentication request data packet to a radius server which is used for returning authentication results. If the authentication results are successfully authenticated, the NAS is used for authorizing user access, an authentication response is simultaneously sent to the portal server by the NAS, and the portal server is used for informing the authentication results to a client via the authentication webpage. The scheme can be used for effectively solving the problem of the authentication of the network access of user class nodes in a local area network.

Description

Portal Authentication Realization Method Based on Authentication, Accounting and Authorization Protocol

technical field

The invention relates to an access method of a network system, in particular to an authentication and accounting method in network access based on authentication, accounting and authorization protocols.

Background technique

In the development process of LAN, switched LAN (LAN switch) solved the problem of network performance very well, and virtual local area network (VLAN) solved the problem of network security effectively. Combining the switched local area network and the virtual local area network to form a switched virtual local area network solves the above two problems very well, and makes the local area network (LAN) have manageable characteristics. But a basic feature of the LAN has not changed, that is, only link establishment and management, but no access authentication and authorization. Access authentication and billing are the basic features of network operation. A network that cannot effectively authenticate connected nodes is difficult to be adopted by network operators (ISPs). Therefore, in the construction of broadband network, the problem of authentication and billing must be solved by adopting LAN networking. Currently, there are two types of access management commonly used in the LAN environment, as shown in Figure 1.

1. In a network using VLAN technology, users can be identified by a virtual local area network identifier (VLANID), so if there is only one terminal node under each VLAN, the VLAN ID can be used to control whether to allow user access. This method is to link links to users one by one.

2. Applying the point-to-point protocol (PPP protocol) to the Ethernet (PPPOE) can solve the authentication and billing problem of the local area network. Use the PPP protocol to establish a point-to-point logical link on the Ethernet network to complete user authentication.

Usually, the devices at the access layer and the AAA (Authentication, Accounting, Authorization, Authenticator, Accounting, Author) server based on the RADIUS (Remote Authentication Dial InUser Service) protocol provide rich services for Internet access users, as shown in the figure 1. Devices at the access layer mainly provide users with physical access to the network and various services. The main task of the AAA server is to authenticate the legal identity of the user, formulate business policies, manage business, and manage users. For example, the access device has the function of allocating a certain bandwidth for users, and the AAA server formulates different bandwidth policies for different users, and the access device executes the decision of the AAA server, so that different users use different bandwidths.

The existing authentication, authorization, and billing methods based on the RADIUS protocol are as follows: when a user accesses the Internet, information such as user name and password are sent to the access device through client software such as PPP dialing on the computer, and the access device Generate a RADIUS message (the message type is Access-Request) based on these information. The message contains attributes such as user name, password, and access physical location information. The access device transmits this message through UDP/ The IP network is sent to the AAA server. After the AAA server receives the Access-Request message, it generates an authentication result according to its database records and decision-making scheme. If the authentication fails, it returns an Access-Reject message to the access device. If the authentication passes, it returns an Access-Reject message. Accept the access (Access-Accept) message and include authorized attribute information in the returned message, such as the user's IP address, time limit for accessing the Internet, and bandwidth. After receiving the above message, the access device will notify the user of authentication success or failure. If the authentication is successful, it will send an accounting request (Accounting -Request) message, there is an attribute in the message to indicate that the charging status is start charging. After receiving the Accounting-Request message, the AAA server will record the current time into the database as the starting time of accounting, and return an Accounting-Response message at the same time. Afterwards, the access device sends an Accounting-Request message at regular intervals. There is an attribute in the message indicating that the accounting status is real-time accounting. After receiving the Accounting-Request message, the AAA server records the accounting information in In the database, an Accounting-Response message is returned at the same time. The purpose of exchanging real-time accounting packets is to avoid loss of all accounting information due to abnormality of the access device, RADIUS service, or network when the user goes online.

During the accounting process, the user may log off the network at any time, and the access device sends an Accounting-Request message to the AAA server after receiving the user's log off notice, and there is an attribute in the message indicating that the accounting status is stop accounting . After receiving the Accounting-Request message, the AAA server records the current time in the database as the end time of accounting, and returns an Accounting-Response message at the same time.

According to the above process, the main disadvantages of the authentication solution that uses VLAN ID to identify users are: 1. The granularity of authentication can only reach the VLAN level, that is to say, several nodes that access the Internet through the same VLAN port cannot be effectively authenticated. Each node occupies a separate VLANID. 2. The networking lacks flexibility, and the management of VLAN ID is also a big problem. Adding, deleting, and moving users all involve the modification of VLAN ID, which must be managed and maintained on the device. When the number of VLAN switches increases time, it will consume a lot of manpower and material resources.

The main shortcoming of adopting the authentication realization mode of PPPOE is: 1, the process is complicated, it comprises PPPOE discovery (Discovery) stage and PPP session stage, so connection is set up time-consuming long; low efficiency. 2. The PPPOE client computer needs to install special PPPOE authentication client software, which increases the cost of the client and the inconvenience of use. 3. PPPOE is a point-to-point link and does not support multicast.

Contents of the invention

The purpose of the present invention is to provide a method for implementing portal authentication based on the authentication, accounting and authorization protocol, which can effectively solve the authentication problem of network access of user-level nodes in the local area network.

In order to achieve the above object, the first method for implementing portal authentication based on authentication, charging, and authorization protocols provided by the present invention includes the following steps:

Step 11: the user visits the portal (Portal) website of the access provider through the network access IP address, and obtains the authentication webpage;

Step 12: The user enters security information in the authentication webpage and sends it to the portal server (PortalServer);

Step 13: After the Portal Server receives the information, it is assembled into an authentication request packet and sent to the Network Access Server (NAS) according to the authentication, accounting, and authorization protocol (RADIUS protocol);

Step 14: The NAS acts as a proxy to further send the above-mentioned authentication request data packet to the RADIUS server;

Step 15: The RADIUS server returns an authentication result, and the authentication result has two types: acceptance (Accept, through authentication) and rejection (Reject, not through authentication). If the authentication result is acceptance, the NAS locally authorizes the user connection, and the NAS Send an authentication response to the Portal Server, and the Portal Server notifies the client of the authentication result through the authentication web page.

The second method for implementing portal authentication based on authentication, charging, and authorization protocols provided by the present invention includes the following steps:

Step 21: The user browses the Portal website of the access provider through the network access IP address, and obtains the authentication webpage;

Step 22: The user enters security information in the authentication web page and sends it to the Portal Server;

Step 23: After receiving the information, the Portal Server assembles it into an authentication request packet according to the RADIUS protocol and sends it to the NAS. If the security information in the authentication request packet does not have a user password (User-Password) and is encrypted with an encryption algorithm user password, then

Step 24: The NAS uses a challenge (Access-Challenge) message to send the challenge code (Challenge) required by the encryption algorithm to the Portal Server;

Step 25: Portal Server constructs an authentication request packet again, encrypts the user password with an encryption algorithm in the packet and sends it to the NAS together with the user name and other information;

Step 26: The NAS acts as a proxy to further send the above-mentioned authentication request data packet to the RADIUS server;

Step 27: The RADIUS server returns an authentication result, and the authentication result has two types of acceptance (Accept, through authentication) and rejection (Reject, not through authentication). If the authentication result is acceptance, the NAS locally authorizes the user connection, and at the same time, the NAS Send an authentication response to the Portal Server, and the Portal Server notifies the client of the authentication result through the authentication web page.

The third method for implementing portal authentication based on authentication, charging, and authorization protocols provided by the present invention includes the following steps:

Step 31: The user browses the Portal website of the access provider through the network access IP address, and obtains the authentication webpage;

Step 32: The user enters security information in the authentication web page and sends it to the Portal Server;

Step 33: After the Portal Server receives the information, it is assembled into an authentication request packet according to the RADIUS protocol and sent to the Network Access Server (NAS);

Step 34: The NAS acts as a proxy to further send the authentication request packet to the RADIUS server;

Step 35: The RADIUS server sends an Access-Challenge message to the NAS, requesting re-authentication;

Step 36: The NAS forwards the message to the Portal Server, and the Portal Server encrypts the user password again, and reassembles the authentication request message and sends it to the NAS;

Step 37: The NAS acts as a proxy to further send the authentication request packet to the RADIUS server;

Step 38: The RADIUS server returns the authentication result, and the authentication result has two kinds of acceptance (Accept, through authentication) and rejection (Reject, not through authentication). If the authentication result is acceptance, the NAS locally authorizes the user connection, and at the same time, the NAS Send an authentication response to the Portal Server, and the Portal Server notifies the client of the authentication result through the authentication webpage.

The 4th kind of portal authentication realization method based on authentication, billing, authorization protocol provided by the present invention comprises the following steps:

Step 41: The user browses the Portal website of the access provider through the network access IP address, and obtains the authentication webpage;

Step 42: The user enters security information in the authentication web page and sends it to the Portal Server;

Step 43: Portal Server sends an access-request message (Access-Request) message to NAS;

Step 44: NAS forwards the Extensible Authentication Protocol (EAP, Extensible Authentication Protocol) attribute in the received Access-Request message to the RADIUS Server;

Step 45: RADIUS Server sends a response message Access-Challenge (access challenge message) to the NAS device;

Step 46: The NAS forwards the EAP attribute in the Access-Challenge message to the PortalServer.

Step 47: Repeat the above steps 43 to 46 until the RADIUS server responds to the NAS with an Access-Accept or Access-Reject message;

Step 48: The authentication results returned by the RADIUS server include acceptance (Accept, passed the authentication) and rejection (Reject, not passed the authentication). Authentication response, the PortalServer notifies the client of the authentication result through the authentication webpage.

The fifth kind of portal authentication implementation method based on authentication, charging and authorization protocol provided by the present invention comprises the following steps:

Step 51: the user browses the Portal website of the access provider through the network access IP address, and obtains the authentication webpage;

Step 52: The user enters security information in the authentication webpage and sends it to the Portal Server;

Step 53: Portal Server sends authentication request directly to RADIUS Server;

Step 54: RADIUS Server sends an authentication response to Portal Server;

Step 55: Portal Server sends Triger Request (trigger request) message to NAS, and described Trigger message is self-defined message, and its attribute comprises Framed-IP-Address (user IP address), Event-Timestamp (event time stamp) Wait for the authorization information, compare the Event-Timestamp with the current time on the NAS, allow the user to access within the set time range, if the user is allowed to access, establish a connection to the user's IP, and open the connection permission;

Step 56: After the NAS completes setting the authority for the connection, it returns a Trigger-ack (trigger response) message to the Portal Server, and the content of the message is success or failure of the authority setting.

The various methods above also include: the user acquires the IP address for network access from the NAS through the Dynamic Host Configuration Protocol (DHCP).

In the above-mentioned various methods, the user enters security information in the authentication webpage and sends it to the Portal Server through a confidential hypertext transfer protocol (HTTPS).

The various methods above also include: in the process of surfing the Internet after the user passes the authentication, using a fault detection method to control the charging operation for the user.

The present invention has the advantages that: 1. Compared with the authentication solution that adopts VLAN ID to identify the user, the management granularity of the management mode based on VLAN ID can only be achieved at the level of VLAN ID, and the management of VLAN ID is also a big problem. Adding, deleting, and moving users all involve modification of the VLAN ID, which must be managed and maintained on the device, while the granularity of the Portal authentication method can be achieved at the user level, and users can choose their own ISP. 2. Compared with the dedicated authentication client (such as PPPOE client), the content of the WEB server and the authentication process are controlled by the operator, and the upgrade and change can be carried out centrally. Because in the Portal authentication mode that the present invention provides, WEB browser is quite popular, generally does not need to reinstall; And its form is familiar and accepted by most users, can operate almost without training. In addition, Portal authentication is easy to implement mandatory Portal authentication. In this case, the user does not even need to know the IP address of the WEB server, as long as he sends a request to browse any WEB server, he can be authenticated and so on. At the same time, the Portal authentication method is easy to implement cell broadcasting or store other content for free use by users. In a word, the method of authenticating through the WEB portal page provided by the present invention solves the problem of authenticating users under the broadband network, and requires little modification to the authentication equipment, but does not need modification to the RADIUS server.

Description of drawings

FIG. 1 is a structural schematic diagram of users and servers of the current access network;

Fig. 2 is a schematic diagram of the user network access structure of the portal authentication mode of the present invention;

Figure 3 is a logical structure diagram in which the portal server only directly interacts with the access device to realize user authentication;

Fig. 4 is the flow chart of the PAP authentication mode in the proxy mode;

Fig. 5 is the flow chart of the first CHAP authentication mode in the proxy mode;

Fig. 6 is the second kind of CHAP authentication mode flowchart in proxy mode;

Fig. 7 is the EAP authentication mode flowchart in proxy mode;

Fig. 8 is a logical structural diagram of the portal server directly interacting with the RADIUS server to realize user authentication;

Fig. 9 is a flow chart of the portal server notification authentication mode in the direct mode.

Detailed ways

The present invention will be described in further detail below in conjunction with the accompanying drawings.

The control of LAN access can be implemented at multiple control points. In the access structure shown in Figure 2, it mainly consists of an edge access layer, an access layer, and an aggregation layer. Authorization for access can be implemented at the edge access layer, or at the access layer or aggregation layer. The edge access layer generally uses Layer 2 devices such as VLAN switches as network access terminal devices, which only provide the function of physical access links, while above the access layer is Layer 3 devices with IP forwarding capabilities. The access layer device in Fig. 2 is NAS (Network Access Server). The portal (Portal) authentication function is an access control to the three-layer access (IP layer), so it must be implemented on a device with the ability to identify IP packets.

First, the client obtains an IP address through the DHCP (Dynamic Host Configuration Protocol) protocol (a static IP address can also be used), but the client cannot access the Internet using the obtained IP address, and can only access a specific IP address before the authentication is passed. , this address is usually the IP address of the Portal Server (Portal Server). Access devices using Portal authentication must have this capability. This is typically achieved by implementing an Access Control List (ACL).

After the user logs in to the Portal Server, he can browse the content above, such as advertisements, news and other free information. At the same time, the user can also enter the user name and password on the web page, which will be transmitted to the Portal Server by the WEB client application, and then the Portal Server and NAS or RADIUS server (RADIUS Server) interacts to realize user authentication. The present invention is divided into two modes according to whether the Portal Server directly interacts with the RADIUS Server. The method in which the Portal Server only authenticates through the NAS is called the proxy method, and the method in which the Portal Server directly interacts with the RADIUS Server for authentication is called the direct method. The exchange of messages between them follows the format stipulated in the RADIUS protocol, with extensions in message types and attributes.

The Portal authentication methods provided by the present invention are divided into two types: active Portal authentication and mandatory Portal authentication. The aforementioned method for users to actively access the Portal server for authentication is active Portal authentication.

For mandatory Portal authentication, before the user passes the authentication, the access device (sometimes called an access server, NAS) discards all other types of packets of the user, except that his packets are TCP packets and the port number is a well-known port number of the HTTP protocol. The port number. If so, the NAS redirects the IP to a specific IP address (usually the IP address of the Portal server). That is to say, no matter what IP address the user inputs to browse the web, he will be redirected to the operator's web homepage (that is, the authentication interface).

In a specific application of the present invention, mandatory Portal authentication may be an optional service, and the access device may not have this capability. In this case, before the user is authenticated, unless he explicitly visits the operator's WEB website, any other IP packets will be discarded by the access device, and the user must explicitly enter the IP address of the Portal Server in the browser .

Refer to Figure 3 for the network diagram for implementing the proxy authentication structure and the communication relationship between each node. In addition to obtaining the user's username and password, PortalServer will also obtain the user's IP address. Then it communicates directly with the NAS using the RADIUS protocol, and the NAS communicates directly with the RADIUS to complete the user authentication process.

Fig. 4 is the PAP (PPP authentication protocol) authentication mode flowchart in the agent mode, and its concrete authentication process refers to following process:

1. Each user computer connected to the access device automatically obtains a unique IP address from the NAS through the Dynamic Host Configuration Protocol (DHCP) process when it is turned on; if it is a user with a static IP address, this step is omitted;

2. The user visits the Portal website of the access provider, obtains the authentication webpage, and at the same time browses community advertisements, notices, etc.;

3. The user enters security information on the authentication page, such as account number and password, and the WEB client sends it to the Portal Server. The security of user name and password can be guaranteed by HTTPS (Secret HTTP Protocol, HTTP: Hypertext Transfer Protocol);

4. After receiving the information, the Portal Server assembles an authentication request packet encrypted by PAP (PPP Authentication Protocol) according to the RADIUS protocol and sends it to the NAS. There must be a shared key for the MD5 encryption algorithm between the Portal Server and the NAS;

5. The NAS acts as a RADIUS proxy (Proxy) to further send the authentication request to the RADIUS server. In practice, the NAS device may also modify the RADIUS message and add some attributes as needed;

6. The RADIUS server returns the authentication result, which can be accepted (Accept, passed the authentication) and rejected (Reject, not passed the authentication);

7. If successful, the NAS authorizes the user connection locally;

8. The NAS sends an authentication response to the Portal Server;

9. Portal Server notifies the client of the authentication result through WEB.

Fig. 5 is the CHAP (challenge-based handshake authentication protocol, ChallengeHandshake Authentication Protocol) authentication method flowchart in the agent mode, and its specific authentication process refers to the following process:

1. Each user computer connected to the access device automatically obtains a unique IP address from the NAS through the Dynamic Host Configuration Protocol (DHCP) process when it is turned on; if it is a user with a static IP address, this step is omitted;

2. The user visits the Portal website of the access provider, obtains the authentication webpage, and at the same time browses community advertisements, notices, etc.;

3. The user enters security information on the authentication page, such as account number and password, and the WEB client sends it to the Portal Server. The security of user name and password can be guaranteed by HTTPS (Secret HTTP Protocol, HTTP: Hypertext Transfer Protocol);

4. The Portal Server assembles the above security information into an authentication request packet according to the RADIUS protocol and sends it to the NAS. If there is no User-Password and CHAP-Password (user password encrypted by MD5 algorithm), it indicates that it needs a Challenge for CHAP, then,

5. The NAS uses the Access-Challenge message to send the CHAP Challenge to the Portal Server;

6. The Portal Server constructs the authentication request data packet again, encrypts the user password with the MD5-CHAP in the data packet and sends it to the NAS together with the user name and other information;

7. The NAS acts as a RADIUS proxy (Proxy) to further send the authentication request to the RADIUS server. In practice, the NAS device may also modify the RADIUS message and add some attributes;

8. The RADIUS server returns the authentication result, which can be accepted (Accept, passed the authentication) and rejected (Reject, not passed the authentication);

9. If successful, the NAS authorizes the user connection locally;

10. The NAS sends an authentication response to the Portal Server;

11. Portal Server notifies the client of the authentication result through WEB.

Since the above-mentioned Challenge used for encryption can also be obtained from the RADIUS server, there is also the CHAP authentication method in the following proxy mode, refer to Figure 6, and refer to the following process for the specific authentication process:

1. Each user computer connected to the access device automatically obtains a unique IP address from the NAS through the Dynamic Host Configuration Protocol (DHCP) process when it is turned on; if it is a user with a static IP address, this step is omitted;

2. The user visits the Portal website of the access provider, obtains the authentication webpage, and at the same time browses community advertisements, notices, etc.;

3. The user enters security information on the authentication page, such as account number and password, and the WEB client sends it to the Portal Server. The security of user name and password can be guaranteed by HTTPS (Secret HTTP Protocol, HTTP: Hypertext Transfer Protocol);

4. After receiving the information, the Portal Server assembles an authentication request packet encrypted by PAP (PPP Authentication Protocol) according to the RADIUS protocol and sends it to the NAS. There must be a shared key using MD5 encryption algorithm between Portal Server and NAS;

5. The NAS acts as a RADIUS proxy (Proxy) to further send the authentication request to the RADIUS server. In practice, the NAS device may also modify the RADIUS message and add some attributes as needed;

6. RADIUS may send an Access-Challenge message to the NAS, requesting re-authentication;

7. The NAS forwards the message to the Portal Server. In this process, NAS only works as an intermediate agent;

8. The Portal Server will encrypt the user password again, reassemble the authentication request message and send it to the NAS;

9. The NAS acts as a RADIUS proxy (Proxy) to further send the authentication request to the RADIUS server. In practice, the NAS device may also modify the RADIUS message and add some attributes;

10. The RADIUS server returns the authentication result, which can be accepted (Accept, passed the authentication) and rejected (Reject, not passed the authentication);

11. If successful, the NAS authorizes the user connection locally;

12. NAS sends an authentication response to Portal Server;

13. Portal Server notifies the client of the authentication result through WEB.

The above-mentioned methods all use the NAS as an intermediary, so it needs to realize some functions of the RADIUS client and server.

Fig. 7 is the flow chart of the EAP authentication mode in the proxy mode. In the present invention, EAP authentication is used as an extensible access authentication protocol. pass. The specific certification process refers to the following process:

1. Each user computer connected to the access device automatically obtains a unique IP address from the NAS through the Dynamic Host Configuration Protocol (DHCP) process when it is turned on; if it is a user with a static IP address, this step is omitted;

2. The user visits the Portal website of the access provider, obtains the authentication webpage, and at the same time browses community advertisements, notices, etc.;

3. The user enters security information on the authentication page, such as account number and password, and the WEB client sends it to the Portal Server. The security of user name and password can be guaranteed by HTTPS (Secret HTTP Protocol, HTTP: Hypertext Transfer Protocol);

4. The Portal server sends an Access-Request message, and the format of the message conforms to the description about EAP in RFC2869.

5. The NAS device forwards the EAP attribute in the Access-Request message of the Portal server to the RADIUS server, and the format of the message conforms to the description about EAP in RFC2869.

6. The RADIUS server sends a response message Access-Challenge message to the NAS device, and the format of the message conforms to the description about EAP in RFC2869.

7. The NAS device forwards the EAP attribute in the Access-Challenge message of the RADIUS server to the Portal server.

8. Repeat steps 4 to 7 above until the RADIUS server responds with an Access-Accept or Access-Reject message, or the negotiation process is interrupted for some reason.

9. If successful (the NAS receives the Access-Accept message), the NAS authorizes the user connection locally;

10. The NAS sends an authentication response to the Portal Server;

11. Portal Server notifies the client of the authentication result through WEB.

It can be seen from the above process that for the EAP method, the NAS is only used as an intermediary structure to transmit the EAP attributes, and the user's authentication information such as user name and password is encapsulated in the EAP attributes, and the NAS device does not need to know. The EAP negotiation process can be repeated multiple times until the RADIUS server responds with an Access-Accept message or an Access-Reject message. After the RADIUS server responds to the Access-Accept message, the NAS device must execute the operation of enabling the user's access permission, indicating that the user can access the Internet after passing the authentication.

Another authentication method is to use the Portal Server as a RADIUS client to directly interact with the RADIUS server to implement user authentication. Refer to Figure 8. In this method, after the Portal Server obtains the user name and password, it does not pass NAS authentication, but directly goes to the RADIUS Server. Go up and authenticate. A typical situation is that RADIUS Server and Portal Server are on the same machine. Notify the NAS in some way after the authentication is passed. The specific authentication process refers to the process shown in Figure 9:

1. Each user computer connected to the access device automatically obtains a unique IP address from the NAS through the Dynamic Host Configuration Protocol (DHCP) process when it is turned on; if it is a user with a static IP address, this step is omitted;

2. The user visits the Portal website of the access provider, obtains the authentication webpage, and at the same time browses community advertisements, notices, etc.;

3. The user enters security information on the authentication page, such as account number and password, and the WEB client sends it to the Portal Server. The security of user name and password can be guaranteed by HTTPS (Secret HTTP Protocol, HTTP: Hypertext Transfer Protocol);

4. Portal Server sends authentication request directly to RADIUS Server;

5. RADIUS Server sends an authentication response to Portal Server;

6. The Portal Server sends a Trigger Request message to the NAS; the message type is self-defined, and the type code is a value different from the RADIUS message type defined by the standard RFC2865 and RFC2866 (request comment protocol). Attributes include Framed-IP-Address, Event-Timestamp and other authorization information. In order to prevent the third party from resending captured messages to cheat, the Event-Timestamp must be compared with the current time on the device, and the user is allowed to access the device only if the error is within a certain range. If access is allowed, a connection is established to the user's IP and permissions are opened.

7. After the NAS completes setting the permissions for the connection, it returns a Trigger-ack message to the Portal Server, the content of which is the success or failure of the permission setting.

8. Configure the user.

9. The user accesses the network.

Since the RADIUS protocol does not have the ability for the RADIUS server to actively send protocol packets to the NAS device, it is necessary to expand the RADIUS protocol. In the RADIUS+1.1 protocol, two types of numbered packets (Triger-Request, Triger-Ack) are added.

After the RADIUS server authenticates the user, it needs to notify the NAS device to enable the user to access the Internet. The RADIUS server completes this work by sending a Trigger-Request message to the NAS device. After the NAS device receives the Trigger-Request message, it opens the corresponding permissions, and at the same time sends a Trigger-Ack to the RADIUS server to indicate that the user's permissions have been successfully opened. Of course, the Trigger-Ack can also contain information about the failure to open the permissions and indicate the failure. s reason.

In the present invention, the security mechanism of the Triger-Request/Triger-Ack message adopts the same security mechanism as the Accouting-Request/Accouting-Response (accounting request/accounting response) message in the RADIUS protocol, and the shared key adopts the RADIUS server Shared key used to encrypt authentication packets with the NAS.

After the user passes the authentication, he has obtained the right to log in to the Internet, but in the process of surfing the Internet, failures or various abnormal situations may occur at any time, such as:

1. The client browser is faulty and cannot browse the web pages;

2. The client computer stops or the network is interrupted, and cannot communicate with the NAS device;

3. The NAS device fails and cannot provide access services for customers.

When a fault occurs, the user cannot continue to occupy network resources, so the above fault should be detected in time, and billing should be stopped. For various abnormal situations, the present invention adopts the following abnormal detection mechanisms:

1. ARP detection: ARP detection can detect network layer (IP layer faults), such as when the client machine crashes, the network card fails, and the network cable is cut off. If the NAS device detects that the IP address of the client does not respond to the ARP message for several consecutive times, it can be considered that the client is faulty;

2. After the user is authenticated, the user maintains a small WEB window for handshaking during the Internet access process, which is used for handshaking with the Portal server. The handshake message can be a standard HTTP GET/POST request, or through a Java Applet Customized IP packets. The WEB small window can also obtain information such as the traffic that has been connected to the Internet and the remaining fees from the Portal server while completing the handshake function. If the Portal server does not receive the handshake information sent by the client's WEB window for a certain period of time, it can consider the client to be faulty, notify the NAS device to stop billing, and prohibit the user from accessing the Internet.

The above two anomaly detection mechanisms can usually be used in combination, or they can be used alone.

Claims (9)

1, a kind of gate verification implementation method based on authentication, charging, authorized agreement comprises the steps:

Step 11: client computer is obtained the authentication webpage by the portal website of the IP address visit access provider of portal server;

Step 12: the safety information that the portal server subscribing client is imported in the authentication webpage;

Step 13: portal server is assembled into the authentication request packet by authentication, charging, authorized agreement with it and issues network access server after receiving this information;

Step 14: network access server is further issued authentication, charging, authorization server as the agency with above-mentioned authentication request packet;

Step 15: authentication, charging, authorization server return authentication result, described authentication result has reception and refuses two kinds, if authentication result is for receiving, network access server is authorized user's connection in this locality, network access server sends authentication response to portal server simultaneously, notifies the client certificate result by portal server by the authentication webpage.

2, a kind of gate verification implementation method based on authentication, charging, authorized agreement comprises the steps:

Step 21: client computer is obtained the authentication webpage by the portal website of the IP address visit access provider of portal server;

Step 22: the safety information that the portal server subscribing client is imported in the authentication webpage;

Step 23: portal server is after receiving this information, by authentication, charging, authorized agreement it is assembled into the authentication request packet and issues network access server, if the user password that the safety information in the authentication request packet does not have user password and adopts cryptographic algorithm to encrypt, then

Step 24: network access server usefulness cross-examinees that message sends the sign indicating number of cross-examining of cryptographic algorithm needs to portal server;

Step 25: portal server is constructed the authentication request packet once more, in packet user cipher is encrypted the back with cryptographic algorithm and issues network access server with information such as user names;

Step 26: network access server is further issued authentication, charging, authorization server as the agency with above-mentioned authentication request packet;

Step 27: authentication, charging, authorization server return authentication result, described authentication result has reception and refuses two kinds, if authentication result is for receiving, network access server is authorized user's connection in this locality, network access server sends authentication response to portal server simultaneously, notifies the client certificate result by portal server by the authentication webpage.

3, a kind of gate verification implementation method based on authentication, charging, authorized agreement comprises the steps:

Step 31: client computer is obtained the authentication webpage by the portal website of the IP address visit access provider of portal server;

Step 32: the safety information that the portal server subscribing client is imported in the authentication webpage;

Step 33: portal server is assembled into the authentication request packet by authentication, charging, authorized agreement with it and issues network access server after receiving this information;

Step 34: network access server is further issued authentication, charging, authorization server as the agency with above-mentioned authentication request packet;

Step 35: authentication, charging, authorization server are sent out to insert to network access server and are cross-examined message, require authentication once more;

Step 36: network access server is transmitted to portal server with this message, and portal server is encrypted user cipher once more, and re-assemblies the authentication request packet and issue network access server;

Step 37: network access server is further issued authentication, charging, authorization server as the agency with above-mentioned authentication request packet;

Step 38: authentication, charging, authorization server return authentication result, described authentication result has reception and refuses two kinds, if authentication result is for receiving, network access server is authorized user's connection in this locality, network access server sends authentication response to portal server simultaneously, notifies the client certificate result by portal server by the authentication webpage.

4, a kind of gate verification implementation method based on authentication, charging, authorized agreement comprises the steps:

Step 41: client computer is obtained the authentication webpage by the portal website of the IP address visit access provider of portal server;

Step 42: the safety information that the portal server subscribing client is imported in the authentication webpage;

Step 43: portal server sends and inserts request message to network access server;

Step 44: the extendible authentication protocol attribute in the access request message that network access server will receive is transmitted to authentication, charging, authorization server;

Step 45: authentication, charging, authorization server send to insert cross-examinees that message is to network access server equipment;

Step 46: network access server cross-examinees that with access the extendible authentication protocol attribute in the message is transmitted to portal server.

Step 47: repeat above-mentioned steps 43 to step 46, insert message to network access server response reception access message or refusal up to authentication, charging, authorization server;

Step 48: the authentication result that authentication, charging, authorization server return has reception and refuses two kinds, if authentication result is for receiving, network access server is authorized user's connection in this locality, network access server sends authentication response to portal server simultaneously, notifies the client certificate result by portal server by the authentication webpage.

5, a kind of gate verification implementation method based on authentication, charging, authorized agreement comprises the steps:

Step 51: client computer is browsed the portal website that inserts provider by the IP address of portal server, obtains the authentication webpage;

Step 52: the safety information that the portal server subscribing client is imported in the authentication webpage;

Step 53: portal server is directly sent out authentication request to authentication, charging, authorization server;

Step 54: authentication, charging, authorization server are sent out authentication response to portal server;

Step 55: portal server is sent out the trigger request message to network access server, described trigger request message is self-defined message, its attribute comprises IP address, Event Timestamp, compare the current time on Event Timestamp and the network access server, in the time range of setting, allow the user to insert, if allow the user to insert, then the IP to this user connects, and opens the connection authority;

Step 56: network access server returns triggered response message to portal server after connection is provided with authority and finishes, and this message content is that authority is provided with success or failure.

6, according to claim 1,2,3,4 or 5 described gate verification implementation methods based on authentication, charging, authorized agreement, it is characterized in that described method also comprises: client computer is obtained the IP address of network insertion from network access server by DHCP.

7, the gate verification implementation method based on authentication, charging, authorized agreement according to claim 6 is characterized in that: the safety information that portal server is imported in the authentication webpage by the HTML (Hypertext Markup Language) subscribing client of maintaining secrecy.

8, the gate verification implementation method based on authentication, charging, authorized agreement according to claim 7, it is characterized in that described method also comprises: in the network process, adopt the billing operation of the method control of fault detect on after client authentication is passed through to client computer.

9, the gate verification implementation method based on authentication, charging, authorized agreement according to claim 2 is characterized in that described cryptographic algorithm is the information-digest algorithm of the 5th version.

Images