Web Authentication Process

Concepts

Web authentication, also called portal authentication, is classified as proactive web authentication or mandatory web authentication.

• Proactive web authentication: A user accesses the authentication page of a web server and enters and submits the username and password. After obtaining the username and password, the web server sends them to the BRAS. The BRAS then exchanges messages with the RADIUS server to complete user authentication.

• Mandatory web authentication: A user attempts to access other extranet resources using HTTP/HTTPS and is forcibly redirected to the web authentication page to enter and submit the username and password. After obtaining the username and password, the web server sends them to the BRAS. The BRAS then exchanges messages with the RADIUS server to complete user authentication.

Web Authentication Process

Web authentication is classified as proactive web authentication or mandatory web authentication. The two authentication modes are the same except for how users access the authentication page. The detailed authentication process is as follows:

As shown in Figure 1, the user can access only the web authentication page in the web pre-authentication domain. If the user passes the authentication after entering the username and password on the page, the user is switched to the web authentication domain and can access network resources.

Figure 1 User login process in proactive web authentication mode

As shown in Figure 2, the user accesses other extranet resources through HTTP/HTTPS and is forcibly redirected to the web authentication page by the BRAS. The user can access only the web authentication page in the web pre-authentication domain. If the user passes the authentication after entering the username and password on the page, the user is switched to the web authentication domain and can access network resources.

Figure 2 User login process in mandatory web authentication mode

Web Authentication Modes

Depending on the network layer where web authentication is performed, web authentication is classified as Layer 2 authentication or Layer 3 authentication.

• Layer 2 authentication: Web authentication is enabled on the BRAS interface that connects to Layer 2 users. Only authenticated users are allowed access to external network resources.

• Layer 3 authentication: Web authentication is enabled on the BRAS interface that connects to Layer 3 users. Web authentication on Layer 3 interfaces can be further classified as direct authentication or inter-Layer 3 authentication. If direct authentication is used, Layer 3 forwarding is not performed between the client and the BRAS. If inter-Layer 3 authentication is used, the client and the BRAS can communicate through Layer 3 forwarding devices.

  • Direct authentication: If a user obtains an IP address using DHCP or has an IP address configured before authentication, the user can use this IP address to access only the portal server and the specified addresses for free access. The user can access network resources after it is authenticated. This authentication process is simpler compared with IP address re-assignment-based authentication.

  • Inter-Layer 3 authentication: is implemented in basically the same way as direct authentication, except that the client and the BRAS can communicate through Layer 3 forwarding devices.

  In both direct authentication and inter-Layer 3 authentication, an IP address uniquely identifies a user. The BRAS delivers ACLs based on users' IP addresses to control packet forwarding of authenticated users on interfaces. If direct authentication is used, users and the BRAS do not communicate through Layer 3 forwarding devices. Therefore, the BRAS interface connecting to users can learn the users' MAC addresses, which allows packet forwarding to be controlled based on a finer granularity.

When using the HTTPS redirection function, pay attention to the following points. Otherwise, the web authentication page may not be displayed:

• When user access to an HTTPS website triggers web authentication, a warning message is displayed. The user needs to click Continue to complete web authentication.
• HTTPS redirection fails for browsers and websites with HTTP Strict Transmission Security (HSTS) enabled.
• If the destination port number of the HTTPS request packets sent by a user is not a well-known port number, such as port 443, redirection fails to be performed.
• The client must support TLS1.2 or TLS1.3. Otherwise, HTTPS redirection fails to performed.

HTTPS Redirection

• HTTPS JavaScript

  In web authentication scenarios, before users are authenticated, the BRAS redirects the HTTPS request packets sent by clients to the web server. Clients are classified as browser clients and non-browser clients. If a large number of HTTPS request packets are sent by non-browser clients, HTTPS redirect will be triggered continuously. This exerts pressure on the web server and affects the prompting of the login web page, thereby affecting the normal HTTPS requests of browser clients.

  To address this problem, enable the HTTPS JavaScript function to shield the HTTPS request packets sent by non-browser clients. When the HTTPS noise reduction function is enabled, the BRAS responds to the client with a 200 OK packet carrying a JavaScript script after receiving an HTTPS Get packet from the client.

  • If the client is a browser, the client can execute the JavaScript script after receiving the packet. The client sends an HTTPS get packet carrying a special URL to the BRAS and redirects the packet to the specified web server 1 second later.
  • If the client is a non-browser, the JavaScript script cannot be executed after the packet is received. The BRAS adds the destination address accessed by the client that fails to parse the JavaScript script to the HTTPS redirection cache blacklist. If the number of times that the address is added to the cache blacklist reaches the upper limit within the specified detection time, in this case, the URL is added to the HTTPS redirection blacklist, and HTTPS redirection cannot be performed.
• HTTPS Chasten

  The HTTPS chasten function suppresses flow establishment for HTTPS redirect. If a malicious user uses HTTPS redirect packets to attack the BRAS, the HTTPS hasten function can be used to suppress the packets sent by the user. This prevents the HTTPS redirect function of other users from being affected.

  By default, the HTTPS chasten function is automatically enabled after the HTTPS redirect function is enabled. If a user sends the HTTPS redirect packets carrying a changed destination IP address to attack the BRAS, the HTTPS chasten function allows the BRAS to discard the extra HTTPS TCP SYN packets that the user is not able to process within a specified period when the BRAS receives TCP SYN packets for HTTPS flow establishment or the number of replied HTTPS redirect packets exceeds the specified threshold.