USOO8046578B1
`
`(12) United States Patent
`Trudeau et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 8,046,578 B1
`Oct. 25, 2011
`
`(54) SYSTEMAND METHOD FOR PROVIDING
`SSSION USING AN
`
`(75) Inventors: Pierre Trudeau, Lorraine (CA); Gilbert
`Moineau, Montréal (CA)
`
`(73) Assignee: 't shipsteps: S
`omopany, L.P., Houston, TX (US)
`
`(*) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 1133 days.
`
`(21) Appl. No.: 11/105,652
`(22) Filed:
`Apr. 14, 2005
`Related U.S. Application Data
`(60) Provisional application No. 60/562,397, filed on Apr.
`14, 2004.
`51) Int. C
`2006.O1
`(51) h 29M6
`(
`)
`(52) U.S. Cl. ........ r 713,154; 713/162; 726/7, 726/29
`(58) Field of Classification Search ................ 726/7, 17,
`726/19, 21, 28, 29, 30; 713/183, 154, 162
`See application file for complete search history.
`Ref
`Cited
`eerees e
`
`(56)
`
`U.S. PATENT DOCUMENTS
`5,875,296 A * 2/1999 Shi et al. ........................... 726.5
`5,987.606 A * 1 1/1999 Cirasole et al. ..
`... 726/11
`6,023,724. A * 2/2000 Bhatia et al. .....
`709,218
`6,102.965 A * 8/2000 Dye et al. ...................... 717/109
`6,154,776 A * 1 1/2000 Martin ...
`709,226
`6.425,003 B1* 7/2002 Herzog et al. ................ 709,223
`
`3.E. R. '3. Sist on et al... 379.g
`ambertOn et al. ...............
`7,127,524 B1 * 10/2006 Renda et al. .......
`TO9.245
`7,159,183 B1* 1/2007 Kudukoli et al. ..
`715,762
`7,506,054 B1* 3/2009 Fuh et al. .......
`709,225
`7.917,941 B2 * 3/2011 Wallman ........................... T26/4
`2002/0196285 A1* 12/2002 Sojoodi et al. .
`345,771
`2003, OOO9695 A1
`1/2003 Sato ...............
`T13 201
`2003.01.15447 A1* 6, 2003 Pham et al. ....
`T13,153
`2003/0233580 A1* 12/2003 Keeler et al. ...
`T13 201
`2005/0066043 A1* 3, 2005 Wallman ............
`TO9,229
`2005, 0102662 A1* 5/2005 Samsalovic et al.
`T17,168
`2005, 019827O A1* 9, 2005 Rusche et al. .........
`TO9,224
`2006/01 14832 A1* 6/2006 Hamilton et al. ..
`... 370,244
`2006/0190990 A1* 8/2006 Gruper et al. ..................... T26/3
`2008.00892.95 A1 *
`4, 2008 Keeler et al. ...
`370,332
`2008/0097858 A1* 4/2008 Vucina et al. ................... TO5/14
`2009,0265554 A1* 10, 2009 Robles et al. ................. T13,168
`k .
`cited by examiner
`Primary Examiner — David García Cervetti
`(57)
`ABSTRACT
`A system and method for granting access to a computer
`network. The method may include, for example, receiving at
`y
`p
`9.
`an access controller a request by a user to access the network
`using a computing device; providing the user with the option
`to retrieve a login page if authentication is required prior to
`network access being granted; using the access controller to
`Verify user credentials provided by the user on the login page,
`the using the access controller to verify user credentials com
`prising: comparing a source IP address of a transmission
`control protocol connection request with a locally defined list
`of authorized user credentials stored in the access controller;
`and determining whether a White List associated with the
`access controller comprises a destination IP address; and
`granting the user access to the network if the user credentials
`are verified.
`
`12 Claims, 12 Drawing Sheets
`
`weam was a seas sess
`
`
`
`
`
`
`
`402
`
`sSource
`Address of CPU
`Recognized
`
`204
`
`
`
`Is Destination
`PAddress Found
`In White List
`
`GUEST TEK EXHIBIT 1004
`Guest Tek v. Nomadix, IPR2019-01191
`
`

`

`U.S. Patent
`
`Oct. 25, 2011
`
`Sheet 1 of 12
`
`OI I
`
`90 I
`
`
`
`
`
`(SQIGTVRI) RICHARIAS VVVSNCI
`
`
`
`ZI I
`
`SS@HOOV
`
`RIGHTTOLNO O
`
`80I
`
`RIGHARIGIS
`
`00I
`
`ZOI
`
`

`

`U.S. Patent
`
`Oct. 25, 2011
`
`Sheet 2 of 12
`
`US 8,046,578 B1
`
`
`
`uoTjosuuoZ
`
`MOTTV
`
`uIg0']
`
`époarmnbay
`
`P07
`
`OZ
`
`
`
`ssaooyJoulojUy
`
`JasnAgiduony
`
`
`
`S0z907JusMZOUNOUUY93TAI9S
`
`puepapraoigaseg
`
`
`
`poisonbayosegWIs0'y
`
`JasAqpoatooeyypue
`
`807
`
`Jouorsstuqng
`
`
`
`sTeENUSpaIDJase)
`
`Jasy)
`
`éPelHoA
`
`.uoneznominyTayCOIcle
`
`1987)0}poyuRIQ
`
`
`
`adeqUOTSsagpueSUIOOTOAA,
`
`
`
`TIMPeprAolgJes/)
`
`Z1Z
`
`
`
`
`
`
`
`

`

`U.S. Patent
`U.S. Patent
`
`Oct. 25, 2011
`Oct. 25, 2011
`
`Sheet 3 of 12
`Sheet 3 of 12
`
`US 8,046,578 B1
`US 8,046,578 B1
`
`
`
`CN
`O
`CN
`
`pOE
`
`90€
`
`
`
`JesMOIgNdDsuedoJesy
`
`YoRoy0}Soy,pue
`
`
`
`ssoIppyvoneunsod
`
`
`
`
`
`
`
`
`
`80€
`
`SHA
`
`
`
`kgpaideoraruyysanboy
`
`
`
`SpusgIasmolgdD
`
`
`
`ysonboySNG
`
`
`
`
`
`pureJajforyuodssoooy
`
`SSOIPPYdIToyTHA
`JasMOIgdd
`
`vedg0}s}dwony
`
`vonoauu0DdL
`
`ssacayAqPpoaisooy
`
`
`
`quespurJsfonUE;
`
`iosMoIgdD
`
`gsuodsayJoAlagSNC
`
`JOAIASSNC01709
`
`
`
`
`

`

`U.S. Patent
`U.S. Patent
`
`Oct. 25, 2011
`Oct. 25, 2011
`
`Sheet 4 of 12
`Sheet 4 of 12
`
`US 8,046,578 B1
`US 8,046,578 B1
`
`
`
`ee i a he ee ee we a ee eeee eee en eee wes eene
`
`vDid
`
`SHA
`
`d]201n0¢Ss}
`
`NdDJOsserppy
`
`épozrusosey
`
`SdA
`
`vonEUTsedSs]
`
`
`
`puno,]ssoippydl
`
`éSPTOIAUT
`
`cov
`ween ew et ee seen ewan
`
`vor
`
`VOC
`
`
`
`
`

`

`U.S. Patent
`
`Oct. 25, 2011
`
`Sheet 5 of 12
`
`US 8,046,578 B1
`
`scervereumerstosnerevssneenttsrttureeern—eervessestemasnestaneneeteantts++/——nrrnrerr—rtthverrerfaretssmennessteevvemmasan|ervevmuneeeterameitiinnisetarsutuenerernrestts
`
`
`
`¥0SasuodsayZLLHspuesraTJoquoZssac0y
`
`elsdOLsuadgIasmoigNdd
`
`
`TIMSOIG(d2)0}JUSSpueJo][oNUODssoo0y
`
`
`q2A\10,4sanboySNCspuagJasMoIgNdD
`
`
`HUTTSaagJOsqQ)JsWYssoIppydIJaarog
`
`
`
`WIAA)ssegJUawIB.UNOUUYSaTAJespue
`
`JasmolgdD0}(o8egUSOT]0}YUrT
`
`
`asegUIdO]SOAIS00YJosMolgdD
`INSMOIG7)WoLsonbsyCLL
`
`
`Agpaatsooyosuodsoyy10A19$SNC
`
`TOAI9§SNC0}U9pureJa[jomu0D
`
`ssaaoyAgpaideorayuyysanboy
`
`
`s)dso1o]U]Jopjomuogsssaoy
`
`IDATaSGa0}UONIUTOD
`
`80¢
`
`907
`
`pO?Woy
`
`802OL
`
`
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Oct. 25, 2011
`
`Sheet 6 of 12
`
`US 8,046,578 B1
`
`Z09
`
`
`
`90Z ULIOIH
`
`
`
`
`
`
`
`019
`
`„----------- - - - - - - - - - - - - ----------------+------- - - - - - - ~~~- - - - - - - - - ~~~~
`
`9 "?IH
`
`

`

`U.S. Patent
`
`Oct. 25, 2011
`
`Sheet 7 of 12
`
`US 8,046,578 B1
`
`802OL
`
`ZOL
`
`JoOAIOgYYVYWollyTonvonuaynyJosy)
`
`iTOAIOgWVV
`
`
`
`
`
`
`
`JOSOONSaATooayJoT[oNUEDssovoy
`
`
`
`SNIAVASpuesJePONUGDssa00yv
`JSMOIGdD0)ed8egpodsur1],
`
`
`JeAlagYYV0}jsanbayssa20V
`
`
`spuagJaToNueDsseooy
`
`
`AgparepieA1987)¥OL
`
`807Wor
`
`
`
`
`

`

`U.S. Patent
`
`Oct. 25, 2011
`
`Sheet 8 of 12
`
`US 8,046,578 B1
`
`
`
`8 "OIH
`
`ZIZ
`
`

`

`U.S. Patent
`
`Oct. 25, 2011
`
`Sheet 9 of 12
`
`US 8,046,578 B1
`
`
`
`Z06
`
`6 "?INH
`
`

`

`U.S. Patent
`
`Oct. 25, 2011
`
`Sheet 10 of 12
`
`US 8,046,578 B1
`
`
`
`
`
`
`
`uorssas ?
`
`

`

`U.S. Patent
`
`Oct. 25, 2011
`
`Sheet 11 of 12
`
`US 8,046,578 B1
`
`90II
`
`
`
`80 II
`
`ZOI I
`
`

`

`U.S. Patent
`
`Oct. 25, 2011
`
`Sheet 12 of 12
`
`US 8,046,578 B1
`
`User Dey ice
`
`
`
`BrOWSer issues
`HTTP Get URL
`
`WebAuth
`(??EB Serrer)
`
`ACCeSS
`COntroller
`
`FireWall has a Special
`rule to redirect the HTTP
`request to WebAuth.
`Please note that this rule
`is removed Once the USer
`is authenticated
`
`HTTP Redirect LOCin URL
`his is the 302 redirect returred to the Client Browser.
`
`Figure 12
`
`GetStatus (ip)
`Internal AP Cato
`retrieve the
`authentication Status of
`the user With the Source
`P address in the HTTP
`GET request
`
`GetStatus: return Code is
`(NotLoggedin)
`SavefirstURL (ip, uri)
`interra API to let
`ACCeSS Controller Save
`the initial URL from the
`Client BrOWSerfor future
`use (after Successful
`authentication)
`
`GetLoginuRL (ip)
`This API is used by
`WebAfth to obtain the
`Ogin page that should be
`presented to the user,
`this page being
`Customizable per user
`GetLoginURL
`(LOgin JRL
`This is the reply to the
`abobe URL. With the
`proper login page to
`present to the user
`
`

`

`US 8,046,578 B1
`
`1.
`SYSTEMAND METHOD FOR PROVIDING
`HTMLAUTHENTCATION USING AN
`ACCESS CONTROLLER
`
`This application is related to and claims priority from Pro
`visional Application No. 60/562,397, filed Apr. 14, 2004.
`
`FIELD OF THE INVENTION
`
`The present invention relates generally to communications
`networks. More particularly, this invention relates to the use
`of access controllers in communications networks for
`restricting network access among potential users.
`
`10
`
`BACKGROUND OF THE INVENTION
`
`15
`
`25
`
`30
`
`35
`
`Recent improvements in technology have resulted in
`cheaper and more portable (e.g., Smaller and lighter) comput
`ing devices, fueling a need fora Substantial growth in network
`communication technology. In particular, the increasing
`prevalence of laptops and other types of portable computing
`devices has resulted in an increased demand for network
`connectivity in a variety of locations apart from a user's home
`or place of business. For example, the user of a portable
`computing device may wish to establish a connection to the
`Internet when within range of a Wireless Internet Service
`Provider (WISP) or an enterprise network (e.g., in a hotel or
`airport lounge).
`In many circumstances, however, it is not desirable for the
`operator of a communications network to permit indiscrimi
`nate access to the network. For example, in one type of
`situation, it may be desirable to limit network access to pay
`ing Subscribers. In another situation, for example, it may be
`desirable to limit network access to ticketed passengers at an
`airport. Accordingly, there is a great need for network systems
`that permits certain authenticated users partial or total access
`to a network, while partially or completely denying other,
`non-authenticated users access to the network.
`In many network architectures, one or more access con
`trollers or similar components are used for the purpose of
`40
`providing selective access to a network. For example, in some
`network architectures, an access controller orgateway device
`is used to automatically redirect users to a portal page when
`an attempt to access the network is made. Such access con
`trollers and gateway devices are not adequate, however,
`because they fail to provide a secure method to inform the
`user that adequate credentials are required to access a public
`IP network (such as the Internet). In particular, the use of
`current access controllers and gateway devices that automati
`cally redirect users to a portal page following network access
`attempts makes it difficult to detect possible “mad in the
`middle' attacks, where unwanted devices spoof Internet Pro
`tocol (IP) addresses.
`In light of the foregoing, it would be desirable to provide an
`access controller for use in network systems that is capable of
`presenting a service announcement page to a user in the event
`that user credentials must be entered prior to network access
`being granted, such that the security and overall user experi
`ence associated with accessing a network from a public loca
`tion is increased.
`
`45
`
`50
`
`60
`
`BRIEF SUMMARY OF THE INVENTION
`
`The present invention is directed to a system and method
`for granting access to a computer network. The system may
`include, for example, a computing device that requests access
`to the network; and an access controller connected to the
`
`65
`
`2
`computing device by a communication link that receives the
`request and provides to the computing device a link used for
`retrieving a login page if it is determined that authentication is
`required prior to network access being granted, where the
`access controller grants network access to the computing
`device after the user credentials entered into the login page
`have been verified. Moreover, the method may include, for
`example, receiving at an access controller a request by a user
`to access the network using a computing device; providing
`the user with the option to retrieve a login page if authentica
`tion is required prior to network access being granted; using
`the access controller to verify user credentials provided by the
`user on the login page; and granting the user access to the
`network if the user credentials are verified. According to the
`invention, the step of providing the user with the option to
`retrieve a login page may include displaying to the user a
`service announcement page, in which case, the login page
`may be retrieved following the selection of a link on the
`service announcement page by the user. According to one
`embodiment of the invention, using the access controller to
`Verify user credentials may include using an AAA server to
`Verify the user credentials. In this case, granting the user
`access to the network may occur following Successful verifi
`cation of the user credentials against the AAA server. Accord
`ing to another embodiment of the invention, using the access
`controller to Verify user credentials may include using a
`locally defined list of authorized user credentials stored in the
`access controller to Verify the user credentials. In this case,
`granting the user access to the network may occur following
`Successful verification of the user credentials against the
`locally defined list of authorized user credentials.
`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.
`
`BRIEF DESCRIPTION OF THE FIGURES
`
`FIG. 1 illustrates a simplified block diagram of an exem
`plary network system using an access controller according to
`the principles of the present invention.
`FIG. 2 is a flow chart illustrating the exemplary steps
`performed by components depicted in FIG. 1 in granting
`network access to a user according to the principles of the
`present invention.
`FIG. 3 is a more detailed flow chart of a step depicted in
`FIG. 2 according to the principles of the present invention.
`FIG. 4 is a more detailed flow chart of a step depicted in
`FIG. 2 according to the principles of the present invention.
`FIG. 5 is a more detailed flow chart of a step depicted in
`FIG. 2 according to the principles of the present invention.
`FIG. 6 is a more detailed flow chart of a step depicted in
`FIG. 2 according to the principles of the present invention.
`FIG. 7 is a more detailed flow chart of a step depicted in
`FIG. 2 according to the principles of the present invention.
`FIG. 8 is a more detailed flow chart of a step depicted in
`FIG. 2 according to the principles of the present invention.
`FIG.9 illustrates an exemplary embodiment of a loginpage
`in accordance with the principles of the present invention.
`FIG. 10 illustrates an exemplary embodiment of a session
`page in accordance with the principles of the present inven
`tion.
`FIG. 11 illustrates an exemplary embodiment of a service
`announcement page in accordance with the principles of the
`present invention.
`
`

`

`US 8,046,578 B1
`
`3
`FIG. 12 is a process flow diagram illustrating the various
`messages that are passed between components in a given
`implementation wherein a web server is located within an
`access device.
`
`DETAILED DESCRIPTION OF THE INVENTION
`
`4
`personal digital assistant (PDA), fax machine, printer, or any
`other type of portable computing device that is capable of
`sending and/or receiving data using a standard browser pro
`gram (e.g., Internet Explorer(R) or Netscape Navigator R) or a
`similar program.
`As shown in FIG. 1, network system 100 also includes a
`Web server 108, which may be an Internet Service Provider
`(ISP) Web server, for example. In addition, network system
`100 includes an Authentication, Authorization and Account
`ing (AAA) Server, or RADIUS 110, which as explained in
`greater detail below, is used to determine ifa user attempting
`to access network 106 should be granted access. Finally, as
`shown in FIG.1, network system 100 includes a domain name
`system (DNS) server 112, which is used to translate domain
`names entered by a user as part of a Uniform Resource Loca
`tor (URL) into the corresponding IP address. It should be
`understood that, while a single DNS Server 112 is shown in
`FIG. 1, the invention is not limited in this manner. For
`example, in a situation where DNS server 112 does not know
`how to translate a particular domain name, another DNS
`server (not shown) may be referenced, and so on, until the
`correct IP address is returned.
`FIG. 2 is a flow chart illustrating the exemplary steps
`performed by components of network system 100 described
`above in granting a user access to network 106 according to
`the principles of the present invention. In particular, the flow
`chart of FIG. 2 provides an overview of the key steps, each
`explained in greater detail below with respect to FIGS. 3-8.
`that are involved in granting network access to the user after
`the user has requested network traffic using a browser or other
`program in computing device 102.
`In the first step (step 202), the user attempts to access
`network 106, which as explained above, may be the Internet.
`For example, the user may be attempting to access a Web site
`on the Internet via a browser program. It will be understood,
`however, that the invention is not limited by the particular
`manner in which the user attempts to access network 106, and
`that the use of a browser in describing the principles of the
`present invention is for illustrative purposes only. Step 202 is
`illustrated in greater detail by the flowchart of FIG. 3, which
`is explained below.
`In step 204, which is explained in greater detail with ref
`erence to the flowchart of FIG.4, access controller 104 deter
`mines whether the user must go through a login process
`before access to network 106 is granted. This determination is
`made prior to the requested network access (step 202) being
`granted to computing device 102, or the browser thereof. If it
`is determined in step 204 that the user does not need to go
`through a login process, the user attempted connection is
`permitted to go through by access controller 104 in step 205.
`For example, if it is determined that the user has previously
`been authenticated (and remains logged in), for example, then
`the user's attempt to access a Web site will be successful and
`a connection with the Web site will be established such that
`data may be exchanged back and forth. A similar result may
`arise if it is determined that the user is attempting to access a
`Web site that is among those specified in the Web address
`White List (which collectively make up a Walled Garden, or
`the portion of the Web that is available to users even if they
`have not been authenticated). The Web sites specified in the
`White List may include, for example, an intranet Web site that
`provides a user with information relating to gaining full
`access to network 106. It will be understood that Web sites can
`always be added or removed from the White List as desired,
`for example, by a network administrator with authority to
`alter the White List associated with access controller 104.
`
`10
`
`15
`
`In the following description, numerous specific details are
`set forth regarding the system and method of the present
`invention and the environment in which the system and
`method may operate, etc., in order to provide a thorough
`understanding of the present invention. It will be apparent to
`one skilled in the art, however, that the present invention may
`be practiced without Such specific details. In other instances,
`well-known components, structures and techniques have not
`been shown in detail to avoid unnecessarily obscuring the
`subject matter of the present invention. It should be under
`stood that these examples are exemplary. It is contemplated
`that there are other systems and methods that are within the
`Scope of the present invention.
`Generally speaking, the present invention is directed to a
`system and method for granting access to a computer net
`work. The system may include, for example, a computing
`device that requests access to the network; and an access
`controller connected to the computing device by a communi
`25
`cation link that receives the request and provides to the com
`puting device a link used for retrieving a login page if it is
`determined that authentication is required prior to network
`access being granted, where the access controller grants net
`work access to the computing device after the user credentials
`entered into the login page have been verified. Moreover, the
`method may include, for example, receiving at an access
`controller a request by a user to access the network using a
`computing device; providing the user with the option to
`retrieve a login page if authentication is required prior to
`network access being granted; using the access controller to
`Verify user credentials provided by the user on the loginpage;
`and granting the user access to the network if the user cre
`dentials are verified. According to the invention, the step of
`providing the user with the option to retrieve a login page may
`40
`include displaying to the user a service announcement page,
`in which case, the login page may be retrieved following the
`selection of a link on the service announcement page by the
`user. According to one embodiment of the invention, using
`the access controller to Verify user credentials may include
`using an AAA server to verify the user credentials. In this
`case, granting the user access to the network may occur fol
`lowing Successful verification of the user credentials against
`the AAA server. According to another embodiment of the
`invention, using the access controller to Verify user creden
`tials may include using a locally defined list of authorized
`user credentials stored in the access controller to verify the
`user credentials. In this case, granting the user access to the
`network may occur following Successful verification of the
`user credentials against the locally defined list of authorized
`user credentials.
`FIG. 1 illustrates a simplified block diagram of an exem
`plary network system 100 using an access controller accord
`ing to the principles of the present invention. As shown in
`FIG. 1, network system 100 includes a portable computing
`device 102 that is connected by a communication link (physi
`cal or wireless) to an access controller 104. It will be under
`stood that, according to the principles of the present inven
`tion, portable computing device 102 may be any device
`through which a user desires to access network 106 (e.g., the
`Internet). For example, computing device 102 may be a lap
`top or other personal computer, mobile (cellular) telephone,
`
`50
`
`30
`
`35
`
`45
`
`55
`
`60
`
`65
`
`

`

`5
`When a user is not yet authenticated, and is attempting to
`access a Web site not specified in the White List (which will
`be assumed herein unless specified otherwise), step 204 dic
`tates that the network connection requested by the user be at
`least temporarily denied, and the process of granting network
`access continues onto step 206. In step 206, which is
`explained in greater detail with reference to FIG. 5, the user's
`Web browser is provided with a service announcement page
`(which can optionally be protected by a valid Secure Socket
`Layer (SSL) certificate), and a login page is requested by the
`user (e.g., by clicking on a link) and is shortly thereafter
`provided to the user's browser. For example, the login page
`may contain one or more graphic elements, along with one or
`more fields for inputting user credentials (e.g., a username
`and password). Moreover, according to the principles of the
`present invention, the login page may reside within access
`controller 104, or on Web server 108, for example. It will be
`understood that the invention is not limited by the location of
`the login page retrieved by the user. Illustrative examples of a
`Service announcement page and a loginpage according to the
`principles of the present invention are shown in FIGS. 11 and
`9, respectively, and are described below.
`Once provided with the loginpage during step 206, the user
`is given the option in step 208 (which is described in greater
`detail below with reference to FIG. 6) to enter his or her user
`credentials (e.g., an ID and Password), which will ultimately
`be used by access controller 104, Web server 108 and AAA
`server 110 in the user authentication process. It will be under
`30
`stood that, depending on the login method associated with
`system 100, the details of the data exchange will vary slightly.
`For example, an internal login page method, an external login
`page method, or a method using NOC Authentication, each of
`which are supported by the access controller 104, may be
`used according to the principles of the present invention. Each
`of these methods are explained immediately below.
`Using the internal login page method, for example, a
`default loginpage may be created as part of the default factory
`settings of access controller 104. Additionally, for example,
`the default login page may be replaced with a login page that
`is downloaded into an embedded Web server (not shown) of
`access controller 104 and saved into non-volatile storage Such
`that a restart of access controller 104 would not erase the
`stored login page. In this case, the login page can be custom
`ized, for example, to include one or more logos or advertise
`ments. While this method is simple and easy to implement, in
`various embodiments of the invention, the size of the login
`page (including the one or more logos) may sometimes be
`limited by the available storage of the device acting as the
`Web server. When this is the case, it is possible to rely on an
`external standard Web server that does not impose such
`restrictions on the size of the login page.
`The external login page method is similar to the internal
`login page method, except that the login page resides on a
`generic external Web server (e.g., Web server 108), and not
`within access controller 104. In this case, there is generally no
`limitation with regards to the number of graphical objects, or
`the total size, associated with the login page, and the URL of
`the remote login page is stored by access controller 104. This
`method is particularly beneficial when the ISP wants to pro
`vide a consistent experience (“look and feel') to its users at
`any of the locations where the network service is available. In
`particular, it is possible for the ISP to customize the content of
`an external loginpage by using information about the location
`of the login page and other relevant information. Although an
`external Web server is used with the external login page
`
`50
`
`35
`
`40
`
`45
`
`55
`
`60
`
`65
`
`US 8,046,578 B1
`
`10
`
`15
`
`25
`
`6
`method, in preferred embodiments of the present invention,
`the user credentials are nonetheless captured directly by
`access controller 104.
`The final method, using NOC authentication, also relies on
`an external login page. However, the interactions between the
`user's WEB browser, access controller 104 and the external
`Web server are different because the user credentials sent with
`the HTML POST message by the user's browser are captured
`by the external Web server and provided to the access con
`troller 104 via a SSL interface. One advantage obtained by
`using this approach is that the number of digital certificates
`signed by a trusted Certificate Authority (e.g., VeriSignR) is
`limited.
`Once the user has submitted credentials in step 208, and
`once access controller 104 has received them, access control
`ler 104 attempts to validate these credentials against AAA
`server 110 (step 210). In particular, as explained in greater
`detail below with reference to FIG. 7, AAA server 110 is
`responsible for replying to access controller 104 with a posi
`tive or negative answer, depending on whether the user has
`been authenticated or not. Assuming the user is not authenti
`cated in step 210, step 208 may be repeated as illustrated in
`FIG. 2. It will be understood, however, that the invention is
`not limited in this manner: For example, when step 210 does
`not result in Successful authentication, any of the preceding
`steps may then be repeated (with the exception of step 205,
`given that the user should not be given access to network 106
`at this time). Alternatively, for example, the step that follows
`a failed authentication at step 210 may depend on the number
`of previous failed attempts at authentication.
`Assuming that the authentication process is successful at
`step 210, the login process is completed and the user is noti
`fied of the successful authentication with an optional well
`come page at Step 212. The welcome page may notify the user
`that network access has been granted and may include, for
`example, customer information based on the name of the user,
`the location where the network service is being used, and/or
`the URL that was initially requested triggering the user
`authentication process. Moreover, the welcome page may
`include a link to the page that was originally requested (e.g.,
`via a placeholder on the URL pointing to the welcome page).
`If a custom URL is not defined by access controller 104, for
`example, then the originally requested page is automatically
`accessed by the user's browser. In addition to a welcome
`page, a session page for providing session information may
`also be provided to the user following successful authentica
`tion at Step 210. An exemplary session page is shown in FIG.
`10 and described below.
`Following successful authentication at step 210, moreover,
`the user is permitted full access to the network at step 213
`(according to the permissions granted to an authorized user
`by the network administrator, for example), and all IP traffic
`goes unmodified (or modified according to the permission
`granted) across access controller 104 while the user remains
`logged in. In other words, while the user remains logged in
`(authenticated), a determination will be made at step 204 for
`each Subsequent network access attempt that login is not
`required, and that connection to the Internet, for example,
`should be allowed (subject to the permissions granted to the
`user).
`Referring now to FIG. 3, a user's attempt to access the
`network (step 202, FIG. 2) may include the following steps.
`At step 302, the user opens a Web browser on computing
`device 102 and attempts to access a destination address,
`www.google.com for example. As explained below, accord
`
`

`

`US 8,046,578 B1
`
`5
`
`10
`
`15
`
`25
`
`35
`
`7
`ing to step 304, what step follows next depends on whether
`the IP address of the destination address is known to the
`browser.
`In particular, if the user's browser has previously cached
`the IP address of the URL that the user is trying to access (and
`the IP address has not been purged from the cache), a DNS
`request is not sent and the browser attempts to open a TCP
`connection directly with the IP address (e.g.,216.239.39.147)
`for the user entered URL of www.google.com (step 306).
`Similarly, when the user explicitly enters the IP address of
`www.google.com (instead of entering the URL), the browser
`attempts to open a TCP connection directly with the entered
`IP address. In both of these scenarios, the user's browser
`instead opens a TCP connection with access controller 104,
`which uses the IP address of www.google.com as the Source
`IP address for all data sent back to the user's browser. Once
`the user has been authenticated, however, the user's browser
`is able to establish a TCP connection with www.google.com
`and data may thereafter be exchanged between the two.
`When the user's Web browser does not know the IP address
`for the URL entered by the user, it needs to issue a DNS
`request to resolve the destination URL to an IP address.
`According to step 308, the browser sends a DNS request to
`find out the correct IP address to use in order to reach the
`destination address, which in this case is www.google.com.
`At step 310, access controller 104 intercepts this DNS request
`sent by the browser, and sends the request to DNS Server 112
`to obtain the actual IP address for www.google.com. At step
`312, meanwhile, access controller 104 receives the DNS
`reply from the DNS server 112, and provides this reply to the
`30
`browser. Once the DNS reply (e.g., the IP address of the
`originally entered URL of www.google.com) is received
`from access controller 104, the browser attempts to open a
`TCP connection directly with the IP address (as explained
`above with respect to step 306).
`Referring now to FIG. 4, determining whether the user
`must login to obtain network access (step 204, FIG. 2) pref
`erably includes the following steps. At step 402, access con
`troller 104 compares the source IP address of the TCP con
`nection request against its list of logged in users. Assuming
`40
`the source IP address is found in this list, access controller 104
`allows the user's originally requested TCP connection (from
`step 306 of FIG. 3) to go through, and a connection to the
`requested URL is established