Patent Application
20060174127
This application contains subject matter that is protected by copyright.
1. Technical Field
The present invention relates generally to WAN mobility technologies and services.
2. Description of the Related Art
Wireless LAN services are increasingly being offered in public venues. A typical method for user authentication in public venues is based on “HTTP intercept.” In this method, the user starts a HTTP session at a public venue. This session is intercepted by a Network Access Server (NAS), which queries the user for authentication credentials. The authentication information is exchanged between the user and the NAS via HTTP messages. Once authenticated, the NAS passes the user's normal HTTP traffic. To provide a consistent branded user experience, there is an increasing demand from service providers to provide a “smart client” that programmatically provides HTTP-based authentication. While the HTTP-based mechanism is fairly straightforward, there is no industry-specified method or standard for this authentication exchange. Protocols, such as WISPr (defined by the Wi-Fi Alliance), attempt to standardize the NAS authentication, but conforming implementations are not widely deployed. As a result, each NAS uses its own HTTP-exchange for querying the user for authentication credentials. This becomes especially problematic in public WLAN networks, because different venue owners tend to have different architectures with different equipment from vendors. Thus, providing an automated authentication experience is not possible with today's myriad of NAS architectures.
The following description provides additional details regarding the prior art. A wireless hotspot is illustrated in
The above-described mechanism works well with a web browser because the browser simply presents the HTTP message to the user, and it is the user's responsibility to navigate through the web page to find out what to do to log in to the network. Recently, there have been several attempts to automate this process through the use of a so-called “smart” client, which performs navigation (on behalf of the user) automatically. In theory, a smart client provides a good solution to the problem of authenticating a user at a hotspot, but there is no available protocol that is followed by all available NAS products. Until the industry standardizes on a protocol and every NAS uses it, building a smart client that works with all the NAS types is a challenging task.
The present invention addresses this problem.
Automated HTTP-based user authentication in a public WLAN environment is facilitated across heterogeneous network access servers (NASs). Each of a set of network access servers has a given authentication protocol, and these protocols typically differ from one another. According to the invention, each authentication protocol has a unique “signature.” According to the invention, a “smart” client that is executable on a given wireless device seeking access to the public WLAN environment is provided with a set of signatures. These signatures are used by the client to determine the appropriate access protocol to use with respect to a given NAS that is controlling access to the WLAN. The client may also have the capability of discovering an unknown authentication protocol “on-the-fly” as it attempts to obtain wireless access. The set of signatures is updated in the client from time-to-time without requiring the client software to be recompiled. The present invention thus provides a generic mechanism by which a client can work with any NAS.
According to the invention, the authentication used by each type of NAS is captured through a unique signature. In particular, the signature preferably captures protocol identifiers including, for example, host name, URL, and login and password formats. In one embodiment, the signature is captured programmatically through a tool that captures the HTTP responses and requests as the user goes through the sequence manually. Different NAS signatures are bundled into a single signature file that is used by the client. The signature file preferably comprises simple ASCII text. Typically, the signature capture process is performed relatively infrequently and can be triggered by the user, a service provider, or some other entity. The signature capture process can also be automatically started by the client when the client sees that an authentication has failed using existing signatures. When a new NAS is identified, the new signature file can simply be updated to the client without requiring a re-compilation of the client. At runtime, the client sequences through the signature file to see which signature headers match. Once the appropriate signature is selected, the client programmatically responds to the HTTP requests related to the authentication sequence.
The foregoing has outlined some of the more pertinent features of the invention. These features should be construed to be merely illustrative. Many other beneficial results can be attained by applying the disclosed invention in a different manner or by modifying the invention as will be described.
For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
The present invention may be implemented in a WLAN or other network environment. WLAN refers to a wireless local area network, typically based on IEEE 802.11 technology. In a representative embodiment, it is assumed that an end user accesses the WLAN with an 802.11-compliant mobile device, such as a laptop, a cell phone, a PDA with a GPRS NIC, or the like. Client software is downloadable to the user's device in any conventional manner to provide a “smart client.” The client software may be original equipment or otherwise native to the mobile device. While the present invention may be implemented in a smart client, this is not a limitation, as a server-centric embodiment is also described below.
By way of additional background,
If the user has already been logged into this network, then the HTTP GET request is passed to the host in the URL and the host will reply back to the client. If, however, the user is not logged in, then the NAS 202 intercepts the HTTP message and sends back a HTTP REDIRECT message (msg #2). (Alternatively, the smart client may be configured to issue the HTTP redirect itself). A typical HTTP REDIRECT message is as follows:
After receiving the REDIRECT message, the smart client needs to send the user credentials to the host (in this case, the NAS) specified in a Location header of the REDIRECT message. It is insecure to send the user credentials in the clear; thus, the NAS may require the smart client to do a Secure Sockets Layer (SSL) connection to send the user credentials. In such case, the smart client establishes a SSL connection with the NAS (msg#3, msg#4). Although there are several message exchanges in the SSL negotiation, only two messages are shown in the diagram for illustrative purposes. Once the SSL connection is established, the smart client sends the user credentials (user name and password) to the NAS, e.g., using an HTTP POST method under the SSL protection (msg #5). A typical HTTP POST with user credentials is as follows:
The NAS then initiates a RADIUS request to the RADIUS server (msg #6). When the RADIUS server 204 is finished verifying the user credentials, it sends either a RADIUS ACCEPT or RADIUS REJECT to the NAS (msg #7). As an indication of authentication complete and also as a response to the client's HTTP POST message, typically the NAS then sends an HTTP OK message, which optionally may contain a start page. A typical success message is as follows:
The messages shown above (which are merely representative) are from a network access server that does not follow a standards-based protocol, such as WISPr or Pass-One. In particular, Pass-One defines a protocol specifying a list of attributes that the NAS has to send in response to the smart client's HTTP GET and HTTP POST messages. Some of those attributes include: access mechanism type, NAS location ID, NAS's host address, protocol (HTTPS/HTTP), and URL to post the user credentials. In theory, the NAS response should be compatible with all smart clients and also with all web browsers. Because, however, web browsers do not understand these attributes, according to the protocol they are sent as HTML comments. WISPr is similar to Pass-One except that the attributes (in WISPr) are in XML format and these XML messages are embedded in the HTML text (once again as HTML comments).
The present invention provides a generic mechanism within or associated with a smart client that supports any NAS. As will be seen, the mechanism is based generally on the property that all HTTP messages are strings that can be captured deterministically as a “signature” and then matched, preferably in real-time. The present invention exploits these properties in the manner that is now described.
In particular, the invention provides a method to capture a given NAS authentication protocol in a flexible manner through signatures, a method to update the signature within the client (preferably without re-compilation), a method to discover a given NAS type by analyzing an authentication signature in real-time, and a method to authenticate a user via this NAS protocol. One feature of the invention is the ability to capture a method followed by a given NAS and to translate that method into a generic specification form, which (for convenience herein) is called a NAS signature. Generalizing, a NAS signature captures all (or substantially all of) the information necessary for a smart client to complete the HTTP intercept-based authentication and user logoff from the network. With this ability, the support of a new NAS or a new method is straightforward, and it is accomplished merely by adding a new NAS signature to the smart client. No smart client code changes are required. This is highly advantageous in terms of ease of use and reliability.
In particular, and as discussed above, an HTTP REDIRECT message that a given NAS sends contains one or more strings (separately or combined) that uniquely identify a NAS or the method followed by that NAS. This is referred to as a discovery signature. The discovery signature (for a given NAS) can be present in the HTTP header or in the HTTP body itself. For example, an HTTP redirect sent by a given vendor ABC typically will have a string “ABC” in the host name of the location header. In like manner, the NAS response to the user's authentication request also contains one or more strings that uniquely determine whether the authentication is successful or a failure. These strings are referred to as auth success signatures and auth failure signatures, respectively. A set of strings are also generated for the user logoff request, which for convenience are called logoff success signatures and logoff failure signatures, respectively. A given NAS signature captures all or substantially all of this information into a formatted signature file as described below.
A signatures file typically contains several NAS signatures describing many NAS authentication methods. A typical format of a given NAS signature may be as follows, although the following is merely representative of a syntax that may be used for this purpose. All lines starting with a ‘#’ are comments.
As noted above, the above is merely illustrative, as other file formats and syntax may be used.
As can be seen then, typically a given NAS signature has five sections: (1) NAS discovery, (2) authentication procedure, (3) authentication result, (4) logoff discovery, and (5) logoff result. Each of these sections is now described.
The NAS discovery section of the NAS signature preferably specifies the discovery signatures and gives the method a unique name to identify the method. The following are two examples of NAS discovery sections of two different NAS signatures.
The authentication procedure section of the NAS signature specifies the authentication procedure for this NAS method. Thus, for example, if the NAS discovery engine discovers that the NAS is following this method, then the smart client will follow the procedure specified in this section to do the authentication.
An example of an authentication procedure section is set forth below:
The authentication section of the NAS signature specifies the way to verify the authentication result. This section contains auth success signatures and auth failure signatures. Preferably, there are two ways to find the authentication result. In a first way, the NAS sends the result as a response to an authentication POST message. A second approach is to have the smart client poll for the result. In the latter case, the NAS sends a REDIRECT message as a response to the authentication POST.
An example of an authentication result section is set forth below:
The logoff section of the NAS signature describes the logoff procedure for this NAS method.
An example of the Logoff procedure section is as follows:
The logoff result section of the NAS signature specifies the way to verify the logoff result. This section contains logoff success signatures and logoff failure signatures. All the fields are analogous to the authentication result section.
An example of logoff result section is as follows:
The actual tags and headers of the NAS signature preferably are captured in any convenient manner, e.g., by running a tool that monitors the HTTP messages sent and received when the user is manually doing the authentication. By observing the HTTP messages and responses, the signature is identified.
Alternatively, the NAS signature capture process preferably is done off-line, depending on when new NAS devices are identified. One such situation is where the service provider adds a new roaming partner. In such case, the NAS of the partner's network is identified; if it does not already exist, its signature is captured. In another situation, if the client fails to programmatically connect, the client prompts the user to connect through a web page. As the user responds to the web page, the client captures the signature and incorporates it for further use.
Once the NAS signatures are captured, preferably they are combined into the NAS signature file. This file typically is a simple ASCII file, as described above. When a new NAS is added (and its signature identified), the signature file is updated and sent to the client (or an update to the existing client-supported signature file is provided). In either case, there is no need to re-compile the client itself.
In particular,
For example, assume the REDIRECT message is as follows:
Assume that there are two methods defined in the signatures file as shown in the above examples. Then, discovery signatures set will be {“Vendor1,” “login_user,” “Vendor2”}. After the smart client searches for these strings in the entire REDIRECT message, the result set will be {TRUE, TRUE, FALSE}. This result set satisfies the Vendor1_NAS method, so the client thus has determined that the NAS is following the Vendor1_NAS method. The client then will do the rest of the authentication following the NAS Signature named Vendor1_NAS. If no matching signature is found, the client resorts to manual authentication by prompting the user. As mentioned earlier, the signature capture program then runs in the background to capture the signature as the user enters data manually. This signature (if approved) can then be incorporated into the new signature file for subsequent use.
While the present invention has been described in the context of client-based NAS discovery and automated authentication, this is not a limitation of the invention. As illustrated in
In particular, some service providers are provide a client-less solution, which lets a user connect at a hotspot through some other means, such as a web browser. In such case, the service provider often uses a two-phase authentication, such as illustrated in
The present invention has numerous advantages. Thus, for example, a smart client can be used to programmatically authenticate the user at any public hotspot. New NAS equipment can be easily accommodated within the specification. Moreover, the NAS signature file can be updated independent of the smart client code itself, making it possible for a service provider to quickly introduce new roaming partners that support different NAS protocols.
While the above describes a particular order of operations performed by a given embodiment of the invention, it should be understood that such order is exemplary, as alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, or the like. References in the specification to a given embodiment indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic.
While the present invention has been described in the context of a method or process, the present invention also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium including, without limitation, any type of disk including optical disks, CD-ROMs, and magnetic-optical disks, read-only memory (ROM), random access memory (RAM), magnetic or optical cards, or any type of media suitable for storing electronic instructions.
While given components of the system have been described separately, one of ordinary skill also will appreciate that some of the functions may be combined or shared in given instructions, program sequences, code portions, and the like.
This application is based on and claims priority from provisional application Ser. No. 60/625,465, filed Nov. 5, 2004.
| Number | Date | Country | |
|---|---|---|---|
| 60625465 | Nov 2004 | US |
