Portal authentication process
Direct authentication and cross-subnet authentication share the same authentication process. Re-DHCP authentication has a different process as it has two address allocation procedures.
Direct authentication/cross-subnet authentication process (with CHAP/PAP authentication)
Figure 52: Direct authentication/cross-subnet authentication process
The direct/cross-subnet authentication process is as follows:
A portal user access the Internet through HTTP or HTTPS, and the HTTP or HTTPS packet arrives at the access device.
If the packet matches a portal free rule, the access device allows the packet to pass.
If the packet does not match any portal-free rule, the access device redirects the packet to the portal Web server. The portal Web server pushes the Web authentication page to the user for him to enter his username and password.
The portal Web server submits the user authentication information to the portal authentication server.
The portal authentication server and the access device exchange CHAP messages. This step is skipped for PAP authentication. The portal authentication server decides the method (CHAP or PAP) to use.
The portal authentication server adds the username and password into an authentication request packet and sends it to the access device. Meanwhile, the portal authentication server starts a timer to wait for an authentication reply packet.
The access device and the RADIUS server exchange RADIUS packets.
The access device sends an authentication reply packet to the portal authentication server to notify authentication success or failure.
The portal authentication server sends an authentication success or failure packet to the client.
If the authentication is successful, the portal authentication server sends an authentication reply acknowledgment packet to the access device.
If the client is an iNode client, the authentication process includes step 9 and step 10 for extended portal functions. Otherwise the authentication process is complete.
The client and the security policy server exchange security check information. The security policy server detects whether or not the user host installs anti-virus software, virus definition files, unauthorized software, and operating system patches.
The security policy server authorizes the user to access certain network resources based on the check result. The access device saves the authorization information and uses it to control access of the user.
Re-DHCP authentication process (with CHAP/PAP authentication)
Figure 53: Re-DHCP authentication process
The re-DHCP authentication process is as follows:
Step 1 through step 7 are the same as those in the direct authentication/cross-subnet authentication process.
After receiving the authentication success packet, the client obtains a public IP address through DHCP. The client then notifies the portal authentication server that it has a public IP address.
The portal authentication server notifies the access device that the client has obtained a public IP address.
The access device detects the IP change of the client through DHCP and then notifies the portal authentication server that it has detected an IP change of the client IP.
After receiving the IP change notification packets sent by the client and the access device, the portal authentication server notifies the client of login success.
The portal authentication server sends an IP change acknowledgment packet to the access device.
Step 13 and step 14 are for extended portal functions.
The client and the security policy server exchanges security check information. The security policy server detects whether or not the user host installs anti-virus software, virus definition files, unauthorized software, and operating system patches.
The security policy server authorizes the user to access certain network resources based on the check result. The access device saves the authorization information and uses it to control access of the user.