Layer 3 portal authentication process
Direct authentication and cross-subnet authentication share the same authentication process. Re-DHCP authentication has a different process because of the presence of two address allocation procedures.
Direct authentication/cross-subnet authentication process (with CHAP/PAP authentication)
Figure 40: Direct authentication/cross-subnet authentication process
The direct authentication/cross-subnet authentication process is as follows:
An authentication client initiates authentication by sending an HTTP request. When the HTTP packet arrives at the access device, the access device allows it to pass if it is destined for the portal server or a predefined free website, or redirects it to the portal server if it is destined for other websites. The portal server pushes a Web authentication page to the user and the user enters the username and password.
The portal server and the access device exchange CHAP messages. This step is skipped for PAP authentication.
The portal server assembles the username and password into an authentication request message and sends it to the access device. Meanwhile, the portal server starts a timer to wait for an authentication acknowledgment message.
The access device and the RADIUS server exchange RADIUS packets to authenticate the user.
The access device sends an authentication reply to the portal server.
The portal server sends an authentication success message to the authentication client to notify it of logon success.
The portal server sends an authentication reply acknowledgment message to the access device.
With extended portal functions, the process includes additional steps:
The security policy server exchanges security check information with the authentication client to check whether the authentication client meets the security requirements.
Based on the security check result, the security policy server authorizes the user to access certain resources, and sends the authorization information to the access device. The access device then controls access of the user based on the authorization information.
Re-DHCP authentication process (with CHAP/PAP authentication)
Figure 41: Re-DHCP authentication process
The re-DHCP authentication process is as follows:
Step 1 through step 6 are the same as those in the direct authentication/cross-subnet authentication process.
After receiving the authentication success message, the authentication client obtains a new public IP address through DHCP and notifies the portal server that it has obtained a public IP address.
The portal server notifies the access device that the authentication client has obtained a new public IP address.
Detecting the change of the IP address by examining ARP packets received, the access device notifies the portal server of the change.
The portal server notifies the authentication client of logon success.
The portal server sends a user IP address change acknowledgment message to the access device.
With extended portal functions, the process includes additional steps:
The security policy server exchanges security check information with the authentication client to check whether the authentication client meets the security requirements.
Based on the security check result, the security policy server authorizes the user to access certain resources, and sends the authorization information to the access device. The access device then controls access of the user based on the authorization information.
Portal support for EAP authentication process
Figure 42: Portal support for EAP authentication process
All portal authentication modes share the same EAP authentication steps. The following example uses direct portal authentication to show the EAP authentication process:
The authentication client sends an EAP Request/Identity message to the portal server to initiate an EAP authentication process.
The portal server sends a portal authentication request to the access device, and starts a timer to wait for the portal authentication reply. The portal authentication request contains several EAP-Message attributes, which are used to encapsulate the EAP packet sent from the authentication client and carry the certificate information of the client.
After the access device receives the portal authentication request, it constructs a RADIUS authentication request and sends it to the RADIUS server. The EAP-Message attributes in the RADIUS authentication request are those carried in the received portal authentication request.
The access device sends a certificate request to the portal server according to the reply received from the RADIUS server. The certificate request also contains several EAP-Message attributes, which are used to transfer the certificate information of the RADIUS server. The EAP-Message attributes in the certificate request are those carried in the RADIUS authentication reply.
After receiving the certificate request, the portal server sends an EAP authentication reply to the authentication client, carrying the EAP-Message attribute values.
The authentication client sends another EAP request to continue the EAP authentication with the RADIUS server, during which there may be several portal authentication requests. The subsequent authentication processes are the same as that initiated by the first EAP request, except that the EAP request types vary with the EAP authentication phases.
After the authentication client passes the EAP authentication, the RADIUS server sends an authentication reply to the access device. This reply carries the EAP-Success message in the EAP-Message attribute.
The access device sends an authentication reply to the portal server. This reply carries the EAP-Success message in the EAP-Message attribute.
The portal server notifies the authentication client of the authentication success.
The portal server sends an authentication reply acknowledgment to the access device.
The remaining steps are for extended portal authentication. For more information about the steps, see the portal authentication process with CHAP/PAP authentication.