This help contains the following topics:

·     Introduction

¡     Portal authentication server

¡     Portal Web server

¡     Local portal Web server

¡     Portal-free rule

¡     Interface portal policies

·     Restrictions and guidelines

Introduction

Portal authentication controls user access to networks. Portal authenticates a user by the username and password the user enters on a portal authentication page. Therefore, portal authentication is also known as Web authentication.

Portal authentication flexibly imposes access control on the access layer and vital data entries. It has the following advantages:

·     Allows users to perform authentication through webpages without installing client software.

·     Provides ISPs with diversified management choices and extended functions. For example, the ISPs can place advertisements, provide community services, and publish information on the authentication page.

·     Supports multiple authentication modes. For example, re-DHCP authentication implements a flexible address assignment scheme and saves public IP addresses. Cross-subnet authentication can authenticate users who reside in a different subnet than the access device.

A typical portal system consists of the following components:

·     Authentication client—An authentication client is a Web browser that runs HTTP/HTTPS or a user host that runs a portal client application.

·     Access device—An access device refers to a broadband access device such as a switch, a router, or a firewall device.

·     Portal authentication server—The portal authentication server receives authentication requests from authentication clients and interacts with the access device to authenticate users.

·     Portal Web server—The portal Web server pushes the Web authentication page to authentication clients and forwards user authentication information (username and password) to the portal authentication server. The portal Web server can be integrated with the portal authentication server or an independent server.

·     AAA server—The AAA server interacts with the access device to implement authentication, authorization, accounting for portal users.

Portal authentication server

Portal authentication server detection

During portal authentication, if the communication between the access device and portal authentication server is broken, new portal users cannot log in and online portal users cannot log out normally. To address this problem, the access device needs to be able to detect the reachability changes of the portal server quickly and take corresponding actions to deal with the changes.

The portal authentication server detection feature enables the device to periodically detect portal packets from a portal authentication server to determine the reachability of the server. If the device receives a portal packet within a detection timeout and the portal packet is valid, the device determines that the portal authentication server is reachable. Otherwise, the device determines that the portal authentication server is unreachable. Portal packets include user login packets, user logout packets, and heartbeat packets. You can configure the device to take one or more of the following actions when the server reachability status changes:

·     Sending a trap message to the NMS. The trap message contains the name and current state of the portal authentication server.

·     Sending a log message, which contains the name, the current state, and the original state of the portal authentication server.

Portal user synchronization

Once the access device loses communication with a portal authentication server, the portal user information on the access device and that on the portal authentication server might be inconsistent after the communication resumes. To address this problem, the device provides the portal user synchronization feature. This feature is implemented by sending and detecting portal synchronization packets, as follows:

1.     The portal authentication server sends the online user information to the access device in a synchronization packet at the user heartbeat interval. The user heartbeat interval is set on the portal authentication server.

2.     Upon receiving the synchronization packet, the access device compares the users carried in the packet with its own user list and performs the following operations:

¡     If a user contained in the packet does not exist on the access device, the access device informs the portal authentication server to delete the user. The access device starts the synchronization detection timer immediately when a user logs in.

¡     If the user does not appear in any synchronization packet within a synchronization detection interval, the access device considers the user does not exist on the portal authentication server and logs the user out.

Portal Web server

Parameters carried in the portal Web server URL

You can configure parameters such as the user IP address, user MAC address, and the originally-requested URL to be added into the portal Web server URL. After you configure the URL parameters, the device sends the portal Web server URL with these parameters to portal users. For example, assume that the URL of a portal Web server is http://www.test.com/portal, and you add the user IP address and the original URL http://www.abc.com/welcome to the server URL. Then, the access device sends to the user at 1.1.1.1 the URL http://www.test.com/portal?userip=1.1.1.1&userurl=http://www.abc.com/welcome.

Portal Web server detection

A portal authentication process cannot complete if the communication between the access device and the portal Web server is broken. To address this problem, you can enable portal Web server detection on the access device.

With the portal Web server detection feature, the access device simulates a Web access process to initiate a TCP connection to the portal Web server. If the TCP connection can be established successfully, the access device considers the detection successful, and the portal Web server is reachable. Otherwise, it considers the detection to have failed. Portal authentication status on interfaces of the access device does not affect the portal Web server detection feature.

·     Detection parameters

¡     Detection interval—Interval at which the device detects the server reachability.

¡     Max detection attempts—If the number of consecutive detection failures reaches this value, the access device considers that the portal Web server is unreachable.

·     Actions to take when the server reachability status changes

¡     Log—Sends a trap message to the NMS. The trap message contains the name and current state of the portal Web server.

¡     Trap—Sends a log message, which contains the name, the current state, and the original state of the portal Web server.

Local portal Web server

System components

The access device supports the local portal Web server feature to provide the local portal service for portal users. With this feature, the access device also acts as the portal Web server and the portal authentication server. In this case, the portal system consists of only three components: authentication client, access device, and authentication/accounting server.

Client and local portal Web server interaction protocols

HTTP and HTTPS can be used for interaction between an authentication client and a local portal Web server. If HTTP is used, there are potential security problems because HTTP packets are transferred in plain text. If HTTPS is used, secure data transmission is ensured because HTTP packets are secured by SSL.

Portal page customization

The local portal Web server supports custom portal authentication pages. You can customize multiple sets of authentication pages, compress each set of the pages to a .zip file, and upload the compressed files to the storage medium of the device.

For the local portal Web server to push authentication pages to users during portal authentication, you must specify a custom authentication page file as the default authentication page file. If no authentication page file is specified as the default authentication page file, the local portal Web server feature cannot be implemented.

Custom authentication pages

Authentication pages are HTML files. Local portal authentication requires the following authentication pages: logon page, logon success page, logon failure page, online page, system busy page, and logoff success page.  You must customize the authentication pages, including the page elements that the authentication pages will use, for example, back.jpg for authentication page Logon.htm.

Follow the authentication page customization rules when you edit the authentication page files.

File name rules

The names of the main authentication page files are fixed (see Table 1).

Table 1 Main authentication page file names

Main authentication page	File name
Logon page	logon.htm
Logon success page	logonSuccess.htm
Logon failure page	logonFail.htm
Online page Pushed after the user gets online for online notification	online.htm
System busy page Pushed when the system is busy or the user is in the logon process	busy.htm
Logoff success page	logoffSuccess.htm

 

You can define the names of the files other than the main authentication page files. File names and directory names are case insensitive.

Page request rules

·     The local portal Web server supports only Get and Post requests.

·     Get requests—Used to get the static files in the authentication pages and allow no recursion. For example, if file Logon.htm includes contents that perform Get action on file ca.htm, file ca.htm cannot include any reference to file Logon.htm.

·     Post requests—Used when users submit username and password pairs, log in, and log out.

Post request attribute rules

·     Observe the following requirements when editing a form of an authentication page:

¡     An authentication page can have multiple forms, but there must be one and only one form whose action is logon.cgi. Otherwise, user information cannot be sent to the local portal Web server.

¡     The username attribute is fixed as PtUser. The password attribute is fixed as PtPwd.

¡     The value of the PtButton attribute is either Logon or Logoff, which indicates the action that the user requests.

¡     A logon Post request must contain PtUser, PtPwd, and PtButton attributes.

¡     A logoff Post request must contain the PtButton attribute.

·     Authentication pages logon.htm and logonFail.htm must contain the logon Post request.

The following example shows part of the script in page logon.htm.

<form action=logon.cgi method = post >

<p>User name:<input type="text" name = "PtUser" style="width:160px;height:22px" maxlength=64>

<p>Password :<input type="password" name = "PtPwd" style="width:160px;height:22px" maxlength=32>

<p><input type=SUBMIT value="Logon" name = "PtButton" style="width:60px;" onclick="form.action=form.action+location.search;”>

</form>

·     Authentication pages logonSuccess.htm and online.htm must contain the logoff Post request.

The following example shows part of the script in page online.htm.

<form action=logon.cgi method = post >

<p><input type=SUBMIT value="Logoff" name="PtButton" style="width:60px;">

</form>

Page file compression and saving rules

·     You must compress the authentication pages and their page elements into a standard zip file. The name of a zip file can contain only letters, numbers, and underscores.

·     The authentication pages must be placed in the root directory of the zip file.

Redirecting authenticated users to a specific webpage

To make the device automatically redirect authenticated users to a specific webpage, do the following in logon.htm and logonSuccess.htm:

·     In logon.htm, set the target attribute of Form to _blank.

See the contents in gray:

    <form method=post action=logon.cgi target="_blank">

·     Add the function for page loading pt_init() to logonSuccess.htm.

See the contents in gray:

    <html>

    <head>

    <title>LogonSuccessed</title>

    <script type="text/javascript" language="javascript" src="pt_private.js"></script>

    </head>

    <body onload="pt_init();" onbeforeunload="return pt_unload();">

    ... ...

    </body>

</html>

Portal-free rule

A portal-free rule allows specified users to access specified external websites (determined by the source and destination information in the rule) without portal authentication.

The matching items for a portal-free rule include the source/destination IP address, TCP/UDP port number, source MAC address, access interface, and VLAN. Packets matching a portal-free rule will not trigger portal authentication, so users sending the packets can directly access the specified external websites.

Interface portal policies

Portal fail-permit

The portal fail-permit feature takes effects when the portal authentication server or portal Web server is unreachable. When the access device detects that the portal authentication server or portal Web server is unreachable, it allows users on the interface to have network access without portal authentication.

BAS-IP or BAS-IPv6 attribute

The device uses the configured BAS-IP or BAS-IPv6 address as the source IP address of the portal notifications sent to the portal authentication server.

If you do not configure the BAS-IP or BAS-IPv6 attribute, the device selects the source IP address for portal packets sent to the portal authentication server as follows:

·     The BAS-IP attribute of an IPv4 portal reply packet sent to the portal authentication server is the source IPv4 address of the packet. The BAS-IPv6 attribute of an IPv6 portal reply packet sent to the portal authentication server is the source IPv6 address of the packet.

·     The BAS-IP attribute of an IPv4 portal notification packet sent to the portal authentication server is the IPv4 address of the packet's outgoing interface. The BAS-IPv6 attribute of an IPv6 portal notification packet sent to the portal authentication server is the IPv6 address of the packet's outgoing interface.

Online user detection

This feature quickly detects abnormal logouts of portal users. ARP or ICMP detection applies to IPv4 portal users, and ND or ICMPv6 detection applies to IPv6 portal users.

ARP and ND detections apply only to direct and re-DHCP portal authentication. ICMP detection applies to all portal authentication modes.

If the device receives no packets from a portal user within the idle time, the device detects the user's online status as follows:

·     ICMP or ICMPv6 detection—Sends ICMP or ICMPv6 requests to the user at configurable intervals to detect the user status.

¡     If the device receives a reply within the maximum number of detection attempts, it considers that the user is online and stops sending detection packets. Then the device resets the idle timer and repeats the detection process when the timer expires.

¡     If the device receives no reply after the maximum number of detection attempts, the device logs out the user.

·     ARP or ND detection—Sends ARP or ND requests to the user and detects the ARP or ND entry status of the user at configurable intervals.

¡     If the ARP or ND entry of the user is refreshed within the maximum number of detection attempts, the device considers that the user is online and stops detecting the user's ARP or ND entry. Then the device resets the idle timer and repeats the detection process when the timer expires.

¡     If the ARP or ND entry of the user is not refreshed after the maximum number of detection attempts, the device logs out the user.

Restrictions and guidelines

Restrictions and guidelines: Portal authentication server detection

·     Only the IMC portal authentication server supports sending heartbeat packets. To test server reachability by detecting heartbeat packets, you must enable the server heartbeat feature on the IMC portal authentication server.

·     You can configure the device to take one or more actions when the portal authentication server reachability status changes.

Restrictions and guidelines: Portal user synchronization

Portal user synchronization requires a portal authentication server to support the portal user heartbeat function. Only the IMC portal authentication server supports the portal user heartbeat function. To implement the portal user synchronization feature, you also need to configure the user heartbeat function on the portal authentication server. Make sure the user heartbeat interval configured on the portal authentication server is not greater than the synchronization detection timeout configured on the access device.

Restrictions and guidelines: The local portal Web server feature

·     The local portal Web server feature implements only some simple portal server functions. It only allows users to log in and log out through the Web interface. It cannot take the place of independent portal Web and authentication servers.

·     You can create only one local portal Web server for one protocol.

·     If you specify an SSL server policy for an HTTPS-based local portal Web server, do not specify TCP port number 443 as the listening port number for the local portal Web server.

Restrictions and guidelines: Portal-free rules

·     If you specify both a VLAN and an interface, the interface must belong to the VLAN. Otherwise, the portal-free rule does not take effect.

·     You cannot configure two or more portal-free rules with the same filtering criteria. Otherwise, the system prompts that the rule already exists.

·     Regardless of whether portal authentication is enabled or not, you can only add or remove a portal-free rule. You cannot modify it.

Restrictions and guidelines: The BAS-IP or BAS-IPv6 attribute

·     If the device runs Portal 2.0, the unsolicited packets sent to the portal authentication server must carry the BAS-IP attribute. If the device runs Portal 3.0, the unsolicited packets sent to the portal authentication server must carry the BAS-IP or BAS-IPv6 attribute.

·     During a re-DHCP portal authentication, the device sends portal notification packets to the portal authentication server. For the authentication to complete, make sure the BAS-IP/BAS-IPv6 attribute is the same as the device IP or IPv6 address specified on the portal authentication server.

·     You must configure the BAS-IP or BAS-IPv6 attribute on a portal authentication-enabled interface if the following conditions are met:

¡     The portal authentication server is an IMC server.

¡     The portal device IP address specified on the portal authentication server is not the IP address of the portal packet output interface.