US20060069782A1 - Method and apparatus for location-based white lists in a telecommunications network - Google Patents

Method and apparatus for location-based white lists in a telecommunications network Download PDF

Info

Publication number
US20060069782A1
US20060069782A1 US10944484 US94448404A US2006069782A1 US 20060069782 A1 US20060069782 A1 US 20060069782A1 US 10944484 US10944484 US 10944484 US 94448404 A US94448404 A US 94448404A US 2006069782 A1 US2006069782 A1 US 2006069782A1
Authority
US
Grant status
Application
Patent type
Prior art keywords
list
hosts
user
location
client session
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10944484
Inventor
Michael Manning
Chen Burshan
Nathan Sowatskey
Ritesh Kumar
Gregory Wilkins
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cisco Technology Inc
Original Assignee
Cisco Technology Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents
    • H04L29/02Communication control; Communication processing contains provisionally no documents
    • H04L29/06Communication control; Communication processing contains provisionally no documents characterised by a protocol
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/168Implementing security features at a particular protocol layer above the transport layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/18Network-specific arrangements or communication protocols supporting networked applications in which the network application is adapted for the location of the user terminal

Abstract

A method is disclosed for determining whether access to a host requested by a client session connection is permitted. After determining attributes of the client session connection, a list of hosts is selected based on the determined attributes of the client session connection. The list of hosts is then used to determine whether access to the requested host is permitted. The disclosed method can be used to allow for location-specific white lists of free URLs for a user at a wireless network hotspot that the user can access before being authenticated.

Description

    FIELD OF THE INVENTION
  • The present invention generally relates to providing a set of Internet destinations or services that are “free of charge” to a user of a wireless network hotspot. The invention relates more specifically to a method and system for determining the location from which a user attempts to connect to the network and using the location to select a white list of hosts that the user can connect to before authentication.
  • BACKGROUND
  • The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
  • Public Wireless Local Area Networks (PwLAN) enable mobile computer users using a laptop or portable computing device to access information through continuous high-speed communications. PwLAN “hotspots” are the public locations where wireless Internet access can be obtained. Hotspots are typically located in such public areas as coffee shops, hotel lobbies or airport lounges.
  • PwLAN hotspots are capable of applying different behaviors to user sessions, depending on where the user connects to the network. This “location awareness” feature allows for the presentation of location-specific or branded retail pages or different elements within a page based on the user's connection attributes.
  • Although network access through a PwLAN hotspot typically requires a user to authenticate before access is allowed, a hotspot may allow the user to access certain designated free services before requiring the user to authenticate. When access to an Internet destination does not require identification and/or authentication of the user, the destination is considered to be “free of charge.” Two mechanisms used to determine when a destination is “free of charge”, and therefore accessible by an unauthenticated user, are “Open Gardens” and “White Lists.” An “Open Garden” refers to a collection of domains that a user can access without providing authentication information. A “White List” is a set of specific Internet destinations that are accessible by an unauthorized user. The primary difference between Open Gardens and White Lists is the level at which accessible destinations are defined. Open Gardens allow or deny access to routing domains, while White Lists do not require a physical address and can define specific accessible destinations by URL (Uniform Resource Locator). Closely related to a White List is a “Black List.” When a Black List is used to control access to specific destinations, the user is allowed access to all destinations that are not in the Black List.
  • White Lists, Black Lists and Open Gardens are typically implemented at the gateway through which the PwLAN hotspot connects to the network. As many hotspots can connect to the network through the same gateway, in these implementations the Open Garden or White List at the gateway applies to all users that connect through a gateway, no matter which hotspot they are using to access the network.
  • It would be advantageous to be able to configure a White List service such that different White Lists could be applied to different users. In particular, it would be advantageous to apply a location-awareness feature similar to the branding feature to a White List service such that different white lists can be configured for each hotspot from a centrally managed location.
  • Known implementations of location-aware branding are based on the ability to derive the connection attributes of the user's subnet based on the user's source IP or gateway through which the user connects, and present branded pages or different elements within a page based on those attributes. However, the ability to have a “location-based white list service” is more complex than merely providing a branded user web-based experience, as White Lists may be used before a user is authenticated, and therefore the known methods of implementing location awareness that rely on a user name or other authentication information cannot be used to implement a location-based white list service.
  • The concept of “location” can be more complex than a simple client IP address. A finer resolution of location, such as a particular access point or even switch access-port through which the user gains access, is desirable. Furthermore, location is often a hierarchical concept. For example, the United Kingdom, Heathrow, Terminal 1, and a specific airline first-class lounge can all be considered to be “locations”. It is desirable to allow for different customizations at different location levels.
  • In addition to location, it is desirable to use any attribute of the user and/or the user's session to dynamically define a list of free services for the user in a particular session, such as authentication information, service level information, etc.
  • Furthermore, in addition to a White List service, it is desirable to apply location-awareness to other services, such as determining payment methods, setting Quality of Service parameters for a session, selecting an ISP, determining the rate at which to charge a user, determining how to perform authentication, or determining how to aggregate and distribute accounting information.
  • Based on the foregoing, there is a clear need for a method of dynamically defining available services for each user based on attributes of the user and/or the user's session. In particular, there is a need to dynamically define a White List for each user based on the location of the user when accessing the network, whether the user has been authenticated, and the services available to the user. Such a method should preferably be able to handle any type of request from a client browser without necessitating any configuration changes on the client (i.e. zero-configuration).
  • The method disclosed herein uses a granular approach for determining whether to allow access to destinations according to the location of a client session. The location is determined according to key characteristics or attributes of the client connection. In one embodiment of the disclosed method, a router redirects requests for access to a host to a Captive Portal Web Server which is capable of handling normal and proxy HTTP requests. The Captive Portal permits or denies access to hosts through configurable White and/or Black Lists. The lists can be default or location-specific, and can be used for other purposes in addition to providing a configurable White List service.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
  • FIG. 1A is a block diagram that illustrates a high-level overview of the components of a PwLAN system implemented using a network management system;
  • FIG. 1B is a block diagram illustrating a high-level overview of how a Captive Portal application can be used to redirect an access request from an unauthorized user to an authentication service in order to provide access to the requested service;
  • FIG. 1C is a block diagram that illustrates a high-level overview of the components of a PwLAN system implemented using a network management system that includes a Web proxy;
  • FIG. 1D is a block diagram that illustrates the components of a network management system as used by one embodiment of the disclosed method;
  • FIG. 2 is a flow diagram that illustrates a high level overview of one embodiment of a method for dynamically defining a White List;
  • FIG. 3 is a sequence diagram that illustrates the system flow for an unauthenticated users requesting a host that is in the White List;
  • FIG. 4 is a block diagram that illustrates a computer system upon which an embodiment may be implemented; and
  • FIG. 5 is a sequence diagram that illustrates the system flow for an unauthenticated proxy user requesting a host not in a White List who then subsequently authenticates.
  • DETAILED DESCRIPTION
  • A method and apparatus for location-based white lists in a telecommunications network is described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
  • Embodiments are described herein according to the following outline:
    • 1.0 General Overview
    • 2.0 Structural and Functional Overview
      • 2.1 Gateway Redirection and Captive Portal Overview
      • 2.2 Web Proxy Overview
    • 3.0 Method of Providing a Location-Based White List Service
    • 3.1 Mapping Connection Attributes to a List of Hosts
      • 3.1.1 Unauthenticated User
      • 3.1.2 Authenticated User
    • 3.2 Proxy and Non-Proxy Requests (Transparent Proxy)
    • 3.3 HTTP and HTTPS proxy requests
    • 3.4 Sequence Diagrams
    • 3.5 Partial Domain Names in White Lists
    • 3.6 White List Groups
    • 4.0 Implementation Mechanisms—Hardware Overview
    • 5.0 Extensions and Alternatives
      1.0 General Overview
  • The needs identified in the foregoing Background, and other needs and objects that will become apparent from the following description, are achieved in the present invention, which comprises, in one aspect, a method of determining whether access to a host requested by a user during a client session connection is permitted. Attributes of the user's client session connection are determined. A list of hosts is selected based on the determined attributes of the client session connection. The list of hosts can be a white list of permissible hosts, or a black list of impermissible hosts. The list of hosts is used to determine whether access to the requested host is permitted for this particular client session connection.
  • In other aspects, the invention encompasses a computer apparatus and a computer-readable medium configured to carry out the foregoing steps.
  • 2.0 Structural and Functional Overview
  • FIG. 1A illustrates a network topology that may be used by a PwLAN operator to provide Internet services to users in a PwLAN hotspot. The components of the network topology of FIG. 1A will be used to describe the method of the present invention, however it will be apparent to those skilled in the art that the inventive method can be used with any type of network configuration, and not all of the components of FIG. 1A are required to implement the inventive method. Furthermore, although the present invention is described using a PwLAN hotspot as an example, it will be apparent to those skilled in the art that the inventive methods can be used in many different contexts, such as DSL (Digital Subscriber Line) access, for example.
  • In the example network of FIG. 1A, users 10 connect to Access Points (AP) 15 in an airport lounge or coffee shop hotspot 18. Within hotspot 18, APs 15 communicate with Access Zone Router (AZR) 20. The hotspot Internet Service Provider (ISP) routes network traffic from the WAN (Wide Area Network) interfaces of the AZRs, via a private network, for example, to an aggregation router 100.
  • In the example network topology shown in FIG. 1A, edge device 100 may be a router. In this example embodiment, router 100 acts as a gateway. One commercial example of such a router is a Cisco router running SSG (Service Selection Gateway). SSG is a software module typically embedded in Cisco IOS software that runs on Cisco devices, however, the functionality that is provided by the gateway (SSG) in the example configuration does not have to be embedded in the edge device. The gateway provides authentication, service connection, connection management and session management capabilities. In this example topology, the gateway performs authentication and service connection tasks on behalf of the network management system portal 110 through Authentication, Authorization and Accounting (AAA) server 120.
  • One commercial example of network management system 110 is Cisco's SESM (Subscriber Edge Services Manager). Network management system (SESM) 110 is a set of components designed to work in conjunction with the gateway. Network management system 110 comprises software for controlling access at the network edge and can bill users for using services in the data center. Network management system 110 may be deployed by ISPs and network access providers (NAPs) to provide value-added services to their subscribers and management capabilities to their administrators. Network management system 110 typically includes several web portals that interact with the edge device 100 acting as a gateway. These web portals are preferably J2EE (Java 2 Platform, Enterprise Edition) web applications that can run in a J2EE-compliant web application server.
  • 2.1 Gateway Redirection and Captive Portal Overview
  • One web portal that is typically provided through the network management system is a “Captive Portal.” Typically, when a user of a PwLAN hotspot who has not yet logged into the network attempts to access an Internet site through a hotspot access point, the user is redirected to this Captive Portal. The Captive Portal application looks at the user's request and determines if it is in a White List. If so, the user is allowed access to the requested host. Otherwise, the Captive Portal will redirect the user to a subscriber portal that provides the user with an opportunity to authenticate in order to access the network. The Captive Portal can be any server that is programmed to respond to a request from an unauthenticated user.
  • In a network configuration such as the one in the example topology shown in FIG. 1A, the ability to force subscribers to authenticate before accessing the network or specific services, and the ability to ensure that subscribers are only allowed to access the services that the service provider wants them to, may be implemented by redirecting unauthenticated or unauthorized users from the gateway to the Captive Portal. For example, if edge device 100 is a Cisco router running SSG, the TCP (Transmission Control Protocol) Redirect feature of SSG may be used in combination with a Captive Portal application of the network management system (SESM). The TCP Redirect feature intercepts TCP packets and reroutes the packets to server groups configured on the gateway. For packets which would otherwise be dropped, a server group on the gateway may be configured such that the packets are rerouted by the gateway to the Captive Portal.
  • FIG. 1B illustrates how a user in the PwLAN of FIG. 1A who accesses the network and has not been authenticated is handled using TCP-Redirect and the Captive Portal application.
  • As shown in FIG. 1B, an unauthorized subscriber 10 associates with an Access Point and starts a standard browser. The user then enters a URL into the browser, such as “www.yahoo.com”, for example. The browser resolves the DNS (Domain Name System) address and issues a HTTP (Hypertext Transfer Protocol) request, as shown by Arrow A. At Arrow B, the gateway redirects the HTTP packet to the Captive Portal application by changing the destination IP address and port in the TCP packets that constitute the request to the Captive Portal address and port. The IP address that the user is trying to connect to is also stored with the request as it is the IP address that the host name of the HTTP request will be resolved to by DNS.
  • As the network management system requires a user identifier to make further policy decisions, at arrow C the Captive Portal issues a HTTP redirect to a subscriber portal, such as Logon Page 80 on the Web Portal. The user logs in and is authenticated/authorized through the AAA (Authentication, Authorization and Accounting) server. A host object is created for this session, and at arrow D, the Captive Portal then causes the browser to be redirected to the originally requested URL (e.g. www.yahoo.com) using HTTP redirect, or any other method known to those skilled in the art.
  • In a configuration such as the example shown in FIG. 1A, the Captive Portal application acts as a logical router or dispatcher for all of the different redirected requests coming from the gateway. The Captive Portal does not provide any content to subscribers. Its main purpose is to apply business logic that determines what will happen next.
  • In one embodiment, the Captive Portal application is a web application with multiple listeners for requests. Each listener in the Captive Portal is configured as a different port number. When the gateway modifies the IP address in the TCP packet to cause the redirection to a web server running the Captive Portal application (Arrow B in FIG. 1B), it also modifies an outgoing port value indicating a type for the TCP redirection. In this manner, the port number in a redirected request identifies the type of redirection to the Captive Portal application.
  • Types of redirection and destination ports are preferably configurable on the gateway. In one embodiment, server groups containing a list of servers are defined, each server group associated with a type of redirection.
  • A configuration file on the Captive Portal can be used to associate an incoming port number to a content application URL. The information in this configuration file specifies how requests on each incoming port number should be redirected. In one embodiment, the configuration file is a XML (extensible Markup Language) file, “captiveportal.xml”, however the configuration information can be stored and managed using any method known to those skilled in the art.
  • The Captive Portal application then issues an HTTP redirect that redirects the user's browser to the content application URL associated with the port number in the request redirected by the gateway to the Captive Portal application. Like the original request redirected to the Captive Portal from the gateway, the request redirected by Captive Portal to the associated content application URL can include information from the original HTTP request, in the form of query parameters appended to the HTTP redirect URL. That is, all of the information in the user's original HTTP request is preserved throughout the redirections.
  • Significantly, the Captive Portal determines which content application URL should handle the request based on configuration attributes that associate incoming port numbers to content application URLs. Each type of redirection uses a different port value. The port number identifies the type of redirection to the Captive Portal.
  • In a preferred embodiment, the network management system may use the Java Management Extensions (JMX) specification and its related JMX MBean standards for application configuration. Managed beans are Java objects that represent a JMX manageable resource. MBeans for each network management system application are specified in configuration XML files. Administrators can change application configuration by changing MBean attribute values through a network management system application that presents a web-based view of managed resources and associated MBeans, or by manually editing associated configuration XML files. As will be apparent to those skilled in the art, use of JMX is not required, as there are many means of providing and managing configuration information that can be used. The configuration files that are used in one example implementation of the inventive method are described in more detail below.
  • Although the specific configuration of SSG/SESM is used herein to describe how unauthenticated users are handled in one PwLAN configuration, those skilled in the art will recognize that there are many ways to implement a Captive Portal, and the particular SSG/SESM configuration discussed above is not required in order to redirect host requests through a Captive Portal. Although the method of the present invention will be described using a SSG/SESM network configuration, the method of the present invention can be implemented in many different PwLAN configurations. In addition, it is not required that a wireless network be used to implement the disclosed method as the method of the present invention can also be used in any type of telecommunications network.
  • 2.2 Proxy Server Overview
  • Clients accessing PwLANs may be using browsers that have a variety of different web proxy and related configuration settings. In addition, the OS (Operating System) connection settings of a client's computer may have a variety of DNS settings. Some of these settings will refer to hosts or IP addresses that are not normally resolvable or reachable in a given PwLAN. As a result, these users will not be able to operate properly in a PwLAN environment.
  • One example of this situation is a proxy client. Proxy clients use an intermediate preconfigured proxy service to access the Internet. A proxy client's browser may be configured to use a proxy server with an unresolvable name or an unreachable IP address. This may occur either because the user is not yet authenticated to access the network from the hotspot or because the browser is intended to be used within an intranet such as a corporate network. For these types of situations, the gateway can be configured to TCP redirect web requests from such users through a web proxy in the network management system.
  • FIG. 1C illustrates the network components in one PwLAN configuration that uses a web proxy configuration. As in FIG. 1A, user 10 connects to AP 15 in a coffee shop hotspot. Within the hotspot, AP 15 communicates with AZR 20. The hotspot ISP routes network traffic to aggregation router 100. In one example of a commercial embodiment, Router 100 is running SSG.
  • As shown by FIG. 1D, in this configuration, after user 10 associates with AP 15, the browser issues a request to the IP address of its configured web proxy server 130. Because the user is not yet authenticated, the gateway 100 performs a TCP redirect to the Captive Portal 111 of the network management system 110. Captive Portal 111 receives the request and determines that it is a proxy request. Captive Portal can then instruct the gateway to set permanent TCP redirection to the network management system Web proxy 112. In one embodiment, Web proxy 112 may be a logical function of Captive Portal 111. Through TCP permanent redirection, web proxy 112 will then act as a local proxy server. The Captive Portal then redirects the user to the network management system login web portal 113. In this way, after authentication by web portal 113, all future web requests from the user's session will be redirected to the network management system for handling.
  • Once the gateway is notified that the permanent TCP redirection for the user, all requests from this user will be redirected to local network management system Web proxy. In an alternative embodiment, a third-party server or gateway can be installed and configured as proxy server to permanently redirect requests to.
  • When this configuration is used for web proxy users, all pre-authentication requests will be handled by Captive Portal through TCP redirection by the gateway, and all post-authentication requests will be handled by the local network management system Web proxy. By having different configurations for these two cases, it is possible to achieve differentiated behavior in White List services. For example, post-authentication White Lists can include more or different hosts than the pre-authentication White Lists.
  • As will be discussed below, one embodiment of the method of the present invention is implemented using features of this configuration. A high-level overview of the method is discussed, followed by a description of an implementation of the inventive method in the example SSG/SESM web proxy configuration. However, as will be apparent to those skilled in the art, alternative implementations are possible, and are intended to come within the scope of the present invention.
  • 3.0 Method of Providing a Location-Based White List Service
  • In the present invention, instead of requiring unauthorized users to authenticate themselves before any network access is allowed, users are allowed to access Internet websites that are defined in a “White List.” Alternatively, users may be allowed to access any Internet website that is not in a “Black List.” Typically, Black Lists are used after authentication or authorization, however, a Black List could potentially be used pre-authentication. Likewise, White Lists are typically used before a user has been authenticated, however, White Lists could be implemented for authenticated users. In addition, a combination of White Lists and Black Lists can be used both pre and post-authentication. The White List/Black List feature allows for value-add for a Service Provider in the form of free services prior to authentication and control of access after authentication.
  • In the present invention, the system allows for mapping of key characteristics or attributes of the user's connection to resolve to a location. The location is then used to determine what the user can and cannot do, i.e. which destinations the user can access or which services the user can take advantage of. More specifically, key attributes of the connection are mapped to a location, and the location is used to look up the associated White List and/or Black List for that location.
  • FIG. 2 illustrates a high-level overview of one embodiment of a method of the present invention. As shown in steps 210 and 215, once the user has connected, such as for example to an access point in a PwLAN, access to a host is requested. For example, the user can initiate an Internet browser on his mobile device and type a URL (Uniform Resource Locator) in his browser address bar. Although the invention is described using the example of entering a URL into a browser, there are many different ways a user can request host access. For instance, a browser may be configured to startup to a home website, and a request to access the home website is automatically requested upon the user starting the browser.
  • In step 220, the attributes of the connection established in step 210 are examined in order to determine key attributes of the client connection. In one embodiment, a location of the client is determined from the connection attributes. However, any parameter or attribute derived from connection information can be used to select a White List, not just location parameters. For example, whether a user has been authenticated can be used when selecting a White List. As another example, the particular services that have been activated for a user can be used when selecting a White List. As another example, the type of client (e.g. Internet Explorer, Netscape, etc.) that the user is using can be used when selecting a White List. Any combination of these attributes can also be used together, as they are not mutually exclusive.
  • In an embodiment implemented using SSG/SESM, the connection attributes can be derived from the “Complete ID” of the client connection. “Complete ID” is a term used by Cisco Systems to describe information about an edge session. In an SSG/SESM network deployment, the SSG makes the Complete ID available to SESM through the RADIUS protocol. In particular, the Complete ID is sent from an SSG router to SESM in response to a query from SESM to SSG about the presence of a Host Object which represents a session.
  • A Complete ID can contain a number of key characteristics or attributes for a given connection, such as IP address, MAC (Media Access Control) address, VPI (Virtual Path Identifier) information, VCI (Virtual Channel Identifier), SSG sub-interface information, subnet information or MSISDN (Mobile Station International ISDN). The attributes in the Complete ID are valid and available at any time, even before the client/session has been authenticated. In addition, after the user has authenticated, the Complete ID may contain the user name used to authenticate the connection. A Complete ID can be used to identify a client, which can be a single user on a PC, a site managing many users, or a transit user at a PwLAN hot spot location.
  • In one embodiment, a location is determined from the attributes derived from the user's “Complete ID”. There are many ways of using the information in a Complete ID to determine the location of the connection. For example, location can be defined for a subscriber IP address range, VPI range, or subinterface, or any combination thereof.
  • As will be apparent to those skilled in the art, other network configurations will have similar functions to obtain the type of information that is stored in a “Complete ID.”
  • In addition, a “Complete ID” is not required to determine connection attributes. For example, in one alternative embodiment, a location for the connection session can be determined from configuration data that maps IP addresses (or subnets) to locations. As will be apparent to those skilled in the art, there are many alternative methods of determining attributes of a client connection. The scope of the present invention is intended to include any such alternative method, and not to be dependent on any particular network components or configuration.
  • Any parameter derived from connection information can be used to select a White List. For example, whether a user has been authenticated is an attribute that can be used to select a White List. As another example, the particular services that have been activated for a user can be determined from the connection information and used to select a White List. A combination of parameters, such as for example location and authentication information, can also be used to select a White List.
  • Once the connection attributes are determined, these attributes are used to select a White List for this connection, as shown by step 230. Location and/or other attributes of the user's connection are in effect used as a key to look up the White List.
  • At step 240, the host requested in step 215 is compared to the list of hosts selected in step 230. If the list is a White List and the requested host is in the list, then access is allowed to the requested host, as shown by step 250. Likewise, if the list of hosts is a Black List, and the requested host is not in the list, then access is allowed to the requested host at step 250.
  • The process is repeated for the next requested host at step 215.
  • If the host requested in step 215 is not in the White List selected in step 230 (or is in the Black List selected in step 230), then the user can be forced to authenticate, as shown by steps 270 and 275. If, however, the user has already been authenticated, then in this case the user is attempting to access an unauthorized host. An appropriate message is displayed to the user at step 265, and the entire process is repeated for the next requested host at step 215.
  • The method shown in FIG. 2 illustrates an embodiment in which the list of hosts is determined each time a user makes a request. In an alternative embodiment, a list of hosts may be determined for the first request, then cached. When the user makes a second request, the cached list may be consulted in order to determine if the second requested host is in the list of hosts. By caching the list, processing speed may be reduced. In this alternative embodiment, the list of hosts may be re-determined when the user authenticates, as the list may change for authenticated users.
  • The method of FIG. 2 or any alternative methods may be implemented in a number of different ways. When a SSG/SESM configuration is used, the TCP-Redirect feature of SSG and the SESM Captive Portal application may be used to implement the above process. While this implementation is described in more detail herein, alternative implementations will be apparent to those skilled in the art.
  • 3.1 Mapping Connection Attributes to a List of Hosts
  • In one embodiment, the listener port of the Captive Portal is used to look up a specific White/Black List. A White/Black List can be specified for each listener port of the Captive Portal. Therefore, use of a listener port allows redirection-specific White Lists for unauthenticated user redirection, unauthorized service redirection, prepaid session redirection, prepaid service redirection, initial captivation and advertising captivation.
  • However, as will be apparent to those skilled in the art, alternative means of looking up a specific White/Black List are available, and it is not required that a listener port be used to perform this function.
  • In one embodiment, if a user is authenticated, this attribute is determined in step 220, and used to redirect the request to a specific port on Captive Portal. The specific port to redirect the request to is determined by how server groups are configured on the gateway. Each of the listener ports of Captive Portal used in this manner matches a port of a server defined in each of the server groups for which the connections are being redirected. The chosen server group is specified in the profile of the active service for the user. For example, this can be done through the Server-Info=KW<server-group> (RADIUS Vendor Specific) attribute.
  • Prior to authentication, location information is available for the connection session, and determined in step 220. Requests from users who have not yet been authenticated are redirected to a specific user port in Captive Portal designated for unauthenticated users. When the Captive Portal receives a request on this port, it can determine a location from the information passed with the request, and use the determined location to look up a specific White/Black List for that location. Alternatively, the Captive Portal may query for the Complete ID, or similar information, in order to determine location attributes.
  • In addition, global default White/Black Lists can be defined. Typically, a default White List will contain hosts used by the network management system. A host is permitted if it is present in the default or specific White List determined by the listener port.
  • In this embodiment, the lookup of White/Black Lists occurs with the following precedence:
    • (1) Listener Port
    • (2) Location
    • (3) Default
  • By following this precedence order, in this embodiment White Lists are first specified according to the type of redirection. For example, authenticated users are redirected to specific ports that the Web Proxy is listening on. Only if no White List for the listener port in use is found will a White List specific to the user's location (or other connection attributes) be used. Only if no White List for the listener port is found and if a location cannot be determined will a default White List apply.
  • In alternative embodiments, a different precedence order may be used, and different features may be used to determine the precedence order. Any combination of features can be used to look up White Lists or Black Lists. For example, a system can be configured to retrieve location-specific White Lists and default White Lists or to retrieve Black Lists for listener ports (authenticated users).
  • 3.1.1 Unauthenticated User
  • By default, when a user is not authenticated, requests are redirected to Captive Portal on port 8090. This port is configurable, however, and any port number can be used. Both the gateway and the Captive Portal are configured to use the same port for this type of redirection.
  • In the “captiveportal.xml” configuration file (or other configuration file) on the Captive Portal, a “Location” MBean can be used to define locations. As will be apparent to those skilled in the art, alternative methods of defining locations can be used, and are intended to come within the scope of the present invention.
  • Table 1 illustrates an example section of “captiveportal.xml” that configures a location “Heathrow” for the client subnet 10.0.0.0 to 10.10.0.0. This configuration is used by the Location MBean to determine if a connection session is from the Heathrow location.
    TABLE 1
    <Configure jmxname=“com.cisco.sesm:name=Location”>
     <Set name=“locations”>
      <Array class=“com.cisco.sesm.core.location.Location”>
       <Item>
        <New class=“com.cisco.sesm.core.location.Location”>
         <Set name=“name”>Heathrow</Set>
         <Set name=“parameters”>
           <Array class=“com.cisco.sesm.core.location.LocationParameter”>
            <Item>
             <New class=“com.cisco.sesm.core.location.IPRangeParam”>
              <Set name=“start” type=“String”>10.0.0.0</Set>
              <Set name=“end” type=“String”>10.10.0.0</Set>
             </New>
            </Item>
           </Array>
          </Set>
         </New>
       </Item>
  • If the client IP address is in the range defined as “Heathrow” in the Location MBean, then the location-specific white list for Heathrow will be selected and used to determine whether access to the requested host is allowed. Configuration file “captiveportal.xml” can also be used to map the value of the White List for a location defined in captiveportal.xml. Table 2 is an example of a section of the captiveportal.xml configuration file that could be used to map a White List to the Heathrow location defined in Table 1. Alternatively, this information could be in a separate configuration file, such as “web-jetty.xml.” In this example, if the location is determined to be “Heathrow”, then the White List consists of the URLs “www.Heathrow.com” and “www.yahoo.com.”
    TABLE 2
     <Set name=“proxyHostsWhiteLists”>
       <New class=”java.util.HashMap”>
        <Put name=”heathrow”>
         <Array class=“java.lang.String”>
          <Item>www.Heathrow.com</Item>
          <Item>www.yahoo.com</Item>
         </Array>
        </Put>
       </New>
      </Set>
    ....
  • As discussed above, if the connection attributes for an unauthorized user do not map to any defined location, a default list can be defined and used. Table 3 illustrates an example of a default list defined in “captiveportal.xml” or other configuration file. In this example, the default list includes SESM hosts, specific IP addresses as well as the URL “www.default.com.”
    TABLE 3
    <Set name=“proxyHostsWhiteLists”>
      <New class=”java.util.HashMap”>
       <Put name=”default”
        <Array class=“java.lang.String”>
         <Item>sesm</Item>
         <Item>localhost</Item>
         <Item>127.0.0.1</Item>
         <Item>www.default.com</Item>
        </Array>
       </Put>
      </New>
     </Set>
     ...

    3.1.2 Authenticated User
  • When a user has been authenticated, this can be determined from the connection attributes determined in step 220 in FIG. 2. In one embodiment, a specific White List defined by that user's ISP provider for authenticated users can be used instead of the location-based White List for unauthenticated users described above.
  • In one embodiment, authenticated but not authorized proxy users can be redirected to a specific network management system web proxy server. The same web proxy functionality applies to both the Captive Portal and web proxy. Therefore, either port-specific lists on the Captive Portal or web proxy servers with default lists can be used. For example, for a web proxy server with authenticated but unauthorized users, a Black List may contain domains A, B and C. When a user has been authorized for service A, the user may be redirected to a web proxy server with a Black List containing B and C. When a user has been authorized for service B, the user may be redirected to a web proxy server with a Black List containing A and C, and so forth.
  • As an example, consider an authenticated user with service IspA as auto-logon. In this example, the “captiveportal.xml” configuration file is configured such that port ‘8103’ is defined as the redirection port for IspA. Likewise, the gateway is configured to redirect requests to port 8103 of the Captive Portal for authenticated IspA users.
  • In this example, the configuration file “captiveportal.xml” (or other configuration file) on Captive Portal is configured such that a White List is defined for port 8103. An example of this section of “captiveportal.xml” is shown in Table 4.
    TABLE 4
    <Set name=“proxyHostsWhiteLists”>
     <New class=”java.util.Hashmap”>
      <Put name=”8103”>
       <Array class=“java.lang.String”>
        <Item>www.IspA.com</Item>
       </Array>
      </Put>
     </New>
    </Set>
    ...
  • When a request is redirected from the gateway to the Captive Portal using port 8103, www.IspA.com is the White List for this user authenticated by IspA.
  • Table 5 illustrates an example section of “captiveportal.xml” or other configuration file that combines the above concepts. The configuration in Table 5 provides mappings from locations “Heathrow” and “Gatwick” to specific White Lists. The configuration in Table 5 also provides mappings from specific listener ports to specific White Lists. This example configuration provides location-specific pre-authentication, port-based post-authentication and default White Lists at lines 3-12, 13-27, and 28-35, respectively.
    TABLE 5
    1 <Set name=“proxyHostsWhiteLists”>
    2  <New class=”java.util.HashMap”>
    3   <Put name=”heathrow”>
    4    <Array class=“java.lang.String”>
    5     <Item>www.Heathrow.com</Item>
    6    </Array>
    7   </Put>
    8   <Put name=”Gatwick”>
    9    <Array class=“java.lang.String”>
    10     <Item>www.Gatwick.com</Item>
    11    </Array>
    12   </Put>
    13   <Put name=“8103”>
    14    <Array class=“java.lang.String”>
    15     <Item>www.ispA.com</Item>
    16    </Array>
    17   </Put>
    18   <Put name=“8104”>
    19    <Array class=“java.lang.String”>
    20     <Item>www.ispB.com</Item>
    21    </Array>
    22   </Put>
    23   <Put name=”8105”>
    24     <Array class=“java.lang.String”>
    25      <Item>www.ispC.com</Item>
    26     </Array>
    27   </Put>
    28   <Put name=”default”>
    29     <Array class=“java.lang.String”>
    30      <Item>sesm</Item>
    31      <Item>localhost</Item>
    32      <Item>127.0.0.1</Item>
    33      <Item>www.default.com</Item>
    34     </Array>
    35   </Put>
    36  </New>
    37 </Set>
  • The client session attributes that map to locations “Heathrow” and “Gatwick” are defined in configuration file “captiveportal.xml”, as discussed in connection to Table 1 above; listener-ports are defined for ISPs A, B and C as discussed in connection to Table 4 above.
  • In a preferred embodiment, a means to poll the xml configuration file for changes is provided so that when any configuration changes are made in the configuration file, the Captive Portal will read and apply the new configuration. For example, a timestamp of captiveportal.xml may be used to determine that the configuration has changed, and that captiveportal.xml needs to be re-parsed in order to apply the latest configuration changes.
  • 3.2 Proxy and Non-Proxy Requests
  • The implementation described above assumes that the requests are all HTTP proxy requests. An HTTP proxy request occurs when a user's browser has been configured to use a proxy server. The need to handle proxy requests typically arises because the proxy server given in the browser's configuration may be unreachable or have a name that is unresolvable. Typically, these situations occur when a user is not yet authenticated to access the network from the hotspot and the browser is intended to be used within an intranet such as a corporate network. This may also occur when a laptop is configured with static domain names or IP addresses for DNS, DHCP and web proxies.
  • In the embodiment described above, all HTTP proxy requests are redirected to the Captive Portal by the gateway using TCP-Redirect. Therefore, Captive Portal can determine White Lists as part of servicing the proxy request. However, non-proxy requests are not automatically redirected to the Captive Portal. The example below describes an alternative implementation that handles non-proxy as well as proxy requests.
  • In this alternative implementation, all web requests are redirected through the Captive Portal whether the client has a web proxy configured or not. In order to redirect all requests, including requests from non-proxy clients, to the Captive Portal, a “transparent proxy” may be used. Transparent proxies intercept all web requests and redirect them to the web proxy. Transparent proxies, such as “Squid”, are known to those skilled in the art, and will not be discussed in detail. Any implementation of a transparent proxy can be used to redirect non-proxy requests to the Captive Portal.
  • In one embodiment, Captive Portal listener ports where transparent proxying will occur for non-proxy users may be configured for both unauthenticated user redirection and default unauthorized service redirection.
  • As will be apparent to those skilled in the art, alternative means of handling proxy and non-proxy requests are available, and can be used when implementing the inventive method.
  • 3.3 HTTP and HTTPS Proxy Requests
  • In one embodiment, HTTP and HTTPS proxy requests may require special handling as the network management system typically requires a host key based on source IP and source port in order to identify the edge session. This needed client information may be conveyed via the Proxy Server in one embodiment.
  • When a request is proxied by the proxy server to the Web Portal, the host key information is not directly available to the Web Portal. In one example embodiment, this information is inserted into the headers of requests proxied by the Proxy Server to the Web Portal.
  • For HTTP requests, the required information may be directly included in HTTP headers sent with the proxied request. For example, the headers ‘com-cisco-sesm-RemoteAddress’ and ‘com-cisco-sesm-RemotePort’ may be used to pass the source IP address and source port in the proxied request.
  • However, it is not possible to modify an HTTPS request due to the confidential and integral nature of SSL. Therefore, since it is not possible to modify a HTTPS proxied request, in one embodiment, out-of-band signaling may be used to handle these requests. After the proxy server (Captive Portal or Web Proxy) has opened a HTTPS connection to the network management system Web Portal, but before the connection is used, the proxy server may make a new out-of-band request to an HTTP port on the network management system Web Portal. The request may contain the headers ‘com-cisco-sesm-RemoteAddress’ for the remote address, ‘com-cisco-sesm-RemotePort’ for the remote port, ‘com-cisco-sesm-Proxy’ for the address and port that the proxy server received the connection on, and ‘com-cisco-sesm-ProxyConnection’ for the source address and port of the real connection from the proxy server to the network management system Web Portal. This information may be collectively referred to as the “proxy meta-data.” Using this proxy meta-data information the network management system Web Portal is then able to look up the hostkey using the remote address and port of the actual HTTPS connection, which is the same as what was passed in the ‘com-cisco-sesm-ProxyConnection’ header in the out-of-band request.
  • It will be apparent to those skilled in the art that other types of out-of-band requests may similarly be used in different network configurations.
  • 3.4 Sequence Diagrams
  • FIG. 3 is a sequence diagram that illustrates one embodiment of the system flow for a user who is not yet authenticated requesting a host that is in a White List. In the example shown in this diagram, the user can either be a proxy or a non-proxy user.
  • As shown, when a request from an unauthenticated user is received at the gateway, it is redirected to the Captive Portal. In the embodiment shown in FIG. 3, the Captive Portal handles the request for a host that is in the White List through a transparent proxy. In this manner, all proxy and non-proxy requests for White List hosts can be handled in the same manner. When the requested host is in the White List, the Captive Portal will proxy the request, as shown by arrows 1.1.1.1 and 1.1.2.
  • FIG. 5 is a sequence diagram that illustrates one embodiment of the system flow for a proxy user who is not yet authenticated requesting a host that is NOT in a White List. As shown at the bottom of FIG. 5, once the user is authenticated, the requested host (in this example, “www.yahoo.com”) is proxied.
  • 3.5 Partial Domain Names in White Lists
  • In addition to specifying a host using a URL or IP address through exact string matching, one embodiment of the present invention also allows for partial domain names in a White/Black List. In this embodiment, partial string matching is used. For example, a White List may contain ‘.cisco.com’. In this example, all hosts in the cisco.com domain will be considered to be in the White List.
  • 3.6 White List Groups
  • In one embodiment of the present invention, a group of hosts can be explicitly defined, and then used in a White or Black List. As a host group name can be explicitly used in the White List definition, it makes the list easier to maintain, as use is clearly visible. Explicit use of a separate list of host groups identifies these clearly.
  • Table 6 illustrates how a group of hosts named “freeservices” may be defined in a separate MBean attribute.
    TABLE 6
    <Set name=“hostGroups”>
     <New class=”java.util.Hashmap”>
      <Put name=”freeservices”>
       <Array class=“java.lang.String”>
        <Item>www.multimap.com</Item>
        <Item>www.google.com</Item>
        <Item>192.168.1.1</Item>
       </Array>
      </Put>
     </New>
    </Set>
    ...
  • Table 7 illustrates an example of how the group of hosts named “freeservices” defined in Table 6 can be used in a White List definition in a separate MBean attribute.
    TABLE 7
    <Set name=“proxyHostsWhiteLists”>
      <New class=”java.util.Hashmap”>
       ...
       <Put name=”paris”>
        <Array class=“java.lang.String”>
         <Item>www.orly.fr</Item>
         <Item>freeservices</Item>
        </Array>
       </Put>
      </New>
     </Set>
     ...
  • In an alternative embodiment, a group of hosts may be defined implicitly. In this case the host group and White List are defined in a single MBean attribute.
  • In one embodiment of the present invention, the ability to define hierarchical locations is provided. In an alternative embodiment, groups of hosts can be defined recursively. In this case, host groups can contain the names of other host groups as well as the names of hosts.
  • Table 8 illustrates an example of how groups of locations can be defined and used in a White List.
    TABLE 8
    <Set name=“locationGroups”>
      <New class=”java.util.Hashmap”>
       <Put name=”paris”>
        <Array class=“java.lang.String”>
         <Item>orly</Item>
         <Item>roissy</Item>
        </Array>
       </Put>
      </New>
     </Set>
     ...
     <Set name=“proxyHostsWhiteLists”>
      <New class=”java.util.Hashmap”>
       ...
       <Put name=”paris”>
        <Array class=“java.lang.String”>
         <Item>www.champselysees.fr</Item>
        </Array>
       </Put>
       <Put name=”orly”>
        <Array class=“java.lang.String”>
         <Item>www.orly.fr</Item>
        </Array>
       </Put>
      </New>
     </Set>
     ...
  • A reverse lookup may be used to determine what the White Lists are for a location. For the example configuration shown in Table 8, the location ‘roissy’ is determined as belonging to the location group ‘paris’, so its White List consists of “www.champselysees.fr”. The example in Table 8 also includes a location ‘paris’ which has the same White List, i.e. “www.champselysees.fr”. Because it additionally has its own definition, the location ‘orly’ has the White List “www.champselysees.fr” and “www.orly.fr”.
  • By including a location in a location group, the location does not need its own definition in the White Lists. A location may also have a White List even though it does not have a White List definition. For example, in Table 8 ‘roissy’ has a White List of “www.champselysees.fr” through its membership to the location group ‘paris’.
  • As with groups of hosts, locations groups may be defined explicitly in separate MBeans, or implicitly in the same MBean.
  • 4.0 Implementation Mechanisms—Hardware Overview
  • FIG. 4 is a block diagram that illustrates a computer system 400 upon which an embodiment of the invention may be implemented. Computer system 400 includes a bus 402 or other communication mechanism for communicating information, and a processor 404 coupled with bus 402 for processing information. Computer system 400 also includes a main memory 406, such as a random access memory (“RAM”) or other dynamic storage device, coupled to bus 402 for storing information and instructions to be executed by processor 404. Main memory 406 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 404. Computer system 400 further includes a read only memory (“ROM”) 408 or other static storage device coupled to bus 402 for storing static information and instructions for processor 404. A storage device 410, such as a magnetic disk or optical disk, is provided and coupled to bus 402 for storing information and instructions.
  • Computer system 400 may be coupled via bus 402 to a display 412, such as a cathode ray tube (“CRT”), for displaying information to a computer user. An input device 414, including alphanumeric and other keys, is coupled to bus 402 for communicating information and command selections to processor 404. Another type of user input device is cursor control 416, such as a mouse, trackball, stylus, or cursor direction keys for communicating direction information and command selections to processor 404 and for controlling cursor movement on display 412. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.
  • The invention is related to the use of computer system 400 for providing location-specific white lists. According to one embodiment of the invention, a location-specific white list is provided by computer system 400 in response to processor 404 executing one or more sequences of one or more instructions contained in main memory 406. Such instructions may be read into main memory 406 from another computer-readable medium, such as storage device 410. Execution of the sequences of instructions contained in main memory 406 causes processor 404 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
  • The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor 404 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 410. Volatile media includes dynamic memory, such as main memory 406. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 402. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.
  • Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
  • Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 404 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 400 can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector can receive the data carried in the infrared signal and appropriate circuitry can place the data on bus 402. Bus 402 carries the data to main memory 406, from which processor 404 retrieves and executes the instructions. The instructions received by main memory 406 may optionally be stored on storage device 410 either before or after execution by processor 404.
  • Computer system 400 also includes a communication interface 418 coupled to bus 402. Communication interface 418 provides a two-way data communication coupling to a network link 420 that is connected to a local network 422. For example, communication interface 418 may be an integrated services digital network (“ISDN”) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 418 may be a local area network (“LAN”) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 418 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
  • Computer system 400 can send messages and receive data, including program code, through the network(s), network link 420 and communication interface 418. In the Internet example, a server 430 might transmit a requested code for an application program through Internet 428, ISP 426, local network 422 and communication interface 418. In accordance with the invention, one such downloaded application provides for a location-specific White List service as described herein.
  • The received code may be executed by processor 404 as it is received, and/or stored in storage device 410, or other non-volatile storage for later execution. In this manner, computer system 400 may obtain application code in the form of a carrier wave.
  • 5.0 Extensions and Alternatives
  • In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims (35)

  1. 1. A method of determining whether access to a host requested by a client session connection is permitted, the method comprising the computer-implemented steps of:
    determining attributes of the client session connection;
    selecting a list of hosts based on the determined attributes of the client session connection;
    using the list of hosts to determine whether access to the requested host is permitted.
  2. 2. A method as recited in claim 1, wherein the list of hosts is a white list of permissible hosts, and the step of using the list of hosts to determine whether access to the requested host is permitted comprises determining whether the requested host is in the list of hosts, and if the requested host is in the list, allowing the client session connection to access the requested host.
  3. 3. A method as recited in claim 2, wherein the list of hosts is a white list of free access URLs.
  4. 4. A method as recited in claim 1, wherein the list of hosts is a black list of impermissible hosts, and the step of using the list of hosts to determine whether access to the requested host is permitted comprises determining whether the requested host is in the list of hosts, and if the requested host is not in the list, allowing the client session connection to access to the requested host.
  5. 5. A method as recited in claim 1, additionally comprising the step of mapping the determined attributes of the client session to a location and selecting a list of hosts based on the location.
  6. 6. A method as recited in claim 1, wherein the step of determining attributes of the client session connection comprises obtaining a Complete ID for the client session connection.
  7. 7. A method as recited in claim 6, wherein the Complete ID includes at least one attribute selected from the group consisting of IP address, MAC address, VPI, VCI, Subnet address and MISIDN.
  8. 8. A method as recited in claim 1, wherein the client session connection is originated by an authenticated user.
  9. 9. A method as recited in claim 1, wherein the client session connection is originated by a user at a PwLAN hotspot.
  10. 10. A method as recited in claim 9, wherein the user has not been authenticated.
  11. 11. A method as recited in claim 1, wherein the list of hosts includes at least one partial domain name.
  12. 12. A method as recited in claim 1, wherein the list of hosts includes at least one group list identifier, said group list identifier identifying a separate list of hosts, and the step of using the list of hosts to determine whether access to the requested host is permitted comprises determining whether the requested host is in the list of hosts or in the separate list of hosts identified by the group list identifier.
  13. 13. A method as recited in claim 12, wherein the group list identifier identifies a group by a location.
  14. 14. A method of determining whether access to a host requested by a client session connection is permitted, the method comprising the computer-implemented steps of:
    determining attributes of the client session connection;
    resolving a location of the client session connection through attributes of the client session connection;
    selecting a list of hosts based on the location of the client session connection;
    using the list of hosts to determine whether access to the requested host is permitted.
  15. 15. The method of claim 14, wherein location is resolved by comparing attributes of the client session connection with stored configuration data.
  16. 16. A system for managing a white list service in a telecommunications network, said system comprising:
    a gateway server, and
    a edge services manager, wherein said edge services manager comprises a captive portal application;
    wherein said gateway server is configurable to redirect a request from a user to a particular port of the captive portal application, said particular port being determined through attributes of the user's connection to the telecommunications network.
  17. 17. The system of claim 16, wherein if the user is authenticated, the particular port is determined by the user's subscriber information, and when the captive portal receives the request redirected to the determined particular port, a white list specific to the user's subscription is applied by the captive portal application.
  18. 18. The system of claim 16, wherein if the user is not authenticated, the particular port is a port configured for unauthenticated users.
  19. 19. The system of claim 18, wherein the Captive Portal determines a location for the unauthenticated user from attributes of the user's connection and applies a white list configured for that location.
  20. 20. The system of claim 16, wherein said edge services manager additionally comprises a web proxy server, and the gateway is configured to redirect all requests from authenticated users to the web proxy server.
  21. 21. A computer-readable medium carrying one or more sequences of instructions for determining whether access to a host requested by a client session connection is permitted, which instructions, when executed by one or more processors, cause the one or more processors to carry out the steps of:
    determining attributes of the client session connection;
    selecting a list of hosts based on the determined attributes of the client session connection;
    using the list of hosts to determine whether access to the requested host is permitted.
  22. 22. A computer-readable medium as recited in claim 21, wherein the list of hosts is a white list of permissible hosts, and the instructions for causing the one or more processors to use the list of hosts to determine whether access to the requested host is permitted further comprises instructions that cause the one or more processors to carry out the step of:
    determining whether the requested host is in the list of hosts, and if the request host is in the list, allowing the client session connection to access the requested host.
  23. 23. A computer-readable medium as recited in claim 22, wherein the list of hosts is a white list of free access URLs.
  24. 24. A computer-readable medium as recited in claim 21, wherein the list of hosts is a black list of impermissible hosts, and the instructions for causing the one or more processors to use the list of hosts to determine whether access to the requested host is permitted further comprises instructions that cause the one or more processors to carry out the step of:
    determining whether the requested host is in the list of hosts, and if the request host is not in the list, allowing the client session connection to access the requested host.
  25. 25. A computer-readable medium as recited in claim 21, additionally comprising instructions that case the one or more processors to carry out the step of: mapping the determined attributes of the client session to a location and selecting a list of hosts based on the location.
  26. 26. A computer-readable medium as recited in claim 21, wherein instructions that cause the one or more processors to determine attributes of the client session comprise instructions for carrying the step of obtaining a Complete ID for the client session connection.
  27. 27. A computer-readable medium as recited in claim 26, wherein the Complete ID includes at least one attribute selected from the group consisting of IP address, MAC address, VPI, VCI, Subnet address and MISIDN.
  28. 28. A computer-readable medium as recited in claim 21, wherein the list of hosts includes at least one partial domain name.
  29. 29. A computer-readable medium as recited in claim 21, wherein the list of hosts includes at least one group list identifier, said group list identifier identifying a separate list of hosts, and the instructions that cause the one or more processors to use the list of hosts to determine whether access to the requested host is permitted comprises instructions for determining whether the requested host is in the list of hosts or in the separate list of hosts identified by the group list identifier.
  30. 30. A computer-readable medium as recited in claim 29, wherein the group list identifier identifies a group by a location.
  31. 31. A system for providing a dynamic white list service, comprising: a network management system comprising a Captive Portal and a Web Portal, said Captive Portal including a listener port configured to receive requests from unauthenticated users; and a gateway configured to redirect requests from unauthenticated users to the listener port of the Captive Portal configured to receive requests from unauthenticated users; wherein for each request redirected by the gateway to the listener port, the Captive Portal determines a location for a request, and selects a white list of hosts based on the determined location.
  32. 32. The system of claim 31, wherein if a request is requesting access to a host in the selected white list of hosts, the Captive Portal proxies the request.
  33. 33. The system of claim 31, wherein said Captive Portal additionally includes at least one listener port configured to receive requests for users authenticated for a service.
  34. 34. A method of managing a client session connection in a wireless network, the method comprising the computer-implemented steps of:
    receiving a request from a user's client session for access to a host;
    determining attributes of the client session connection;
    if the determined attributes indicate that the user has been authenticated for a service, selecting a list of hosts that is associated with the authenticated service;
    if the determined attributes indicate that the user has not been authenticated, mapping the determined attributes to a location of the user, and selecting a list of hosts associated with the location; and
    using the selected list of hosts to determine whether access to the requested host is permitted.
  35. 35-36. (canceled)
US10944484 2004-09-16 2004-09-16 Method and apparatus for location-based white lists in a telecommunications network Abandoned US20060069782A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10944484 US20060069782A1 (en) 2004-09-16 2004-09-16 Method and apparatus for location-based white lists in a telecommunications network

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US10944484 US20060069782A1 (en) 2004-09-16 2004-09-16 Method and apparatus for location-based white lists in a telecommunications network
US11110340 US8127008B2 (en) 2004-09-16 2005-04-19 Method and apparatus for managing proxy and non-proxy requests in telecommunications network
US11205538 US8996603B2 (en) 2004-09-16 2005-08-16 Method and apparatus for user domain based white lists
US13219337 US8527629B2 (en) 2004-09-16 2011-08-26 Method and apparatus for managing proxy and non-proxy requests in a telecommunications network

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US11110340 Continuation US8127008B2 (en) 2004-09-16 2005-04-19 Method and apparatus for managing proxy and non-proxy requests in telecommunications network
US11205538 Continuation-In-Part US8996603B2 (en) 2004-09-16 2005-08-16 Method and apparatus for user domain based white lists

Publications (1)

Publication Number Publication Date
US20060069782A1 true true US20060069782A1 (en) 2006-03-30

Family

ID=36033784

Family Applications (3)

Application Number Title Priority Date Filing Date
US10944484 Abandoned US20060069782A1 (en) 2004-09-16 2004-09-16 Method and apparatus for location-based white lists in a telecommunications network
US11110340 Active 2028-10-01 US8127008B2 (en) 2004-09-16 2005-04-19 Method and apparatus for managing proxy and non-proxy requests in telecommunications network
US13219337 Active US8527629B2 (en) 2004-09-16 2011-08-26 Method and apparatus for managing proxy and non-proxy requests in a telecommunications network

Family Applications After (2)

Application Number Title Priority Date Filing Date
US11110340 Active 2028-10-01 US8127008B2 (en) 2004-09-16 2005-04-19 Method and apparatus for managing proxy and non-proxy requests in telecommunications network
US13219337 Active US8527629B2 (en) 2004-09-16 2011-08-26 Method and apparatus for managing proxy and non-proxy requests in a telecommunications network

Country Status (1)

Country Link
US (3) US20060069782A1 (en)

Cited By (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060085681A1 (en) * 2004-10-15 2006-04-20 Jeffrey Feldstein Automatic model-based testing
US20070094401A1 (en) * 2005-10-21 2007-04-26 Francois Gagne Support for WISPr attributes in a TAL/CAR PWLAN environment
US20070214265A1 (en) * 2006-03-07 2007-09-13 Sbc Knowledge Ventures Lp Scalable captive portal redirect
US20080060064A1 (en) * 2006-09-06 2008-03-06 Devicescape Software, Inc. Systems and methods for obtaining network access
US20080140841A1 (en) * 2006-12-08 2008-06-12 Robert Ott Method and apparatus for detecting the IP address of a computer, and location information associated therewith
US20080209524A1 (en) * 2007-02-23 2008-08-28 Microsoft Corporation Caching public objects with private connections
US20090024550A1 (en) * 2006-09-06 2009-01-22 Devicescape Software, Inc. Systems and Methods for Wireless Network Selection
EP2061205A2 (en) * 2007-11-16 2009-05-20 Hewlett-Packard Development Company, L.P. Method and apparatus for accessing a network
US20090178116A1 (en) * 2005-02-18 2009-07-09 Duaxes Corporation Communication control device and communication control system
US20100095359A1 (en) * 2008-10-13 2010-04-15 Devicescape Software, Inc. Systems and Methods for Identifying a Network
US7760722B1 (en) * 2005-10-21 2010-07-20 Oracle America, Inc. Router based defense against denial of service attacks using dynamic feedback from attacked host
US20100215163A1 (en) * 2009-02-23 2010-08-26 International Business Machines Corporation System and method of location sensitive caller and callee based call prioritization
US20100263022A1 (en) * 2008-10-13 2010-10-14 Devicescape Software, Inc. Systems and Methods for Enhanced Smartclient Support
US20110040870A1 (en) * 2006-09-06 2011-02-17 Simon Wynn Systems and Methods for Determining Location Over a Network
US20110047603A1 (en) * 2006-09-06 2011-02-24 John Gordon Systems and Methods for Obtaining Network Credentials
US8006285B1 (en) 2005-06-13 2011-08-23 Oracle America, Inc. Dynamic defense of network attacks
US20120039452A1 (en) * 2009-03-16 2012-02-16 Guenther Horn Communication Connection Establishment Control for Preventing Unsolicited Communication
US20120047270A1 (en) * 2010-08-18 2012-02-23 Microsoft Corporation Directing modalities over different networks in multimodal communications
US8169945B2 (en) 2010-06-17 2012-05-01 Google Inc. Maintaining network connectivity
US20130333038A1 (en) * 2005-09-06 2013-12-12 Daniel Chien Evaluating a questionable network communication
US8667596B2 (en) 2006-09-06 2014-03-04 Devicescape Software, Inc. Systems and methods for network curation
US8996603B2 (en) 2004-09-16 2015-03-31 Cisco Technology, Inc. Method and apparatus for user domain based white lists
CN104735101A (en) * 2013-12-19 2015-06-24 中兴通讯股份有限公司 Network resource sharing processing method and device and network resource sharing method and system
US20150229609A1 (en) * 2005-09-06 2015-08-13 Daniel Chien Evaluating a questionable network communication
US20160261499A1 (en) * 2015-03-03 2016-09-08 APPLIED RESEARCH WORKS Inc. Computerized System and Method for Providing Sponsored Internet Access
US9462071B2 (en) 2012-03-06 2016-10-04 Cisco Technology, Inc. Spoofing technique for transparent proxy caching
US9665881B1 (en) * 2012-05-04 2017-05-30 Amazon Technologies, Inc. Physical store online shopping control
US9912677B2 (en) 2005-09-06 2018-03-06 Daniel Chien Evaluating a questionable network communication
US10084791B2 (en) 2013-08-14 2018-09-25 Daniel Chien Evaluating a questionable network communication

Families Citing this family (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060069782A1 (en) * 2004-09-16 2006-03-30 Michael Manning Method and apparatus for location-based white lists in a telecommunications network
US8381297B2 (en) 2005-12-13 2013-02-19 Yoggie Security Systems Ltd. System and method for providing network security to mobile devices
JP2008072655A (en) * 2006-09-15 2008-03-27 Fujitsu Ltd Service communication control method, service relaying apparatus and service communication control system
US20080177846A1 (en) * 2007-01-19 2008-07-24 Weishi Feng Method for Providing E-Mail Spam Rejection Employing User Controlled and Service Provider Controlled Access Lists
US8365272B2 (en) 2007-05-30 2013-01-29 Yoggie Security Systems Ltd. System and method for providing network and computer firewall protection with dynamic address isolation to a device
US8237546B2 (en) * 2007-06-28 2012-08-07 Symbol Technologies, Inc. Backscatter limited tags
US8631488B2 (en) 2008-08-04 2014-01-14 Cupp Computing As Systems and methods for providing security services during power management mode
US8423631B1 (en) * 2009-02-13 2013-04-16 Aerohive Networks, Inc. Intelligent sorting for N-way secure split tunnel
US20110307490A1 (en) * 2010-06-15 2011-12-15 Usm China/Hong Kong Limited Context Level Protocols And Interfaces
WO2012017561A1 (en) * 2010-08-06 2012-02-09 富士通株式会社 Mediation processing method, mediation device, and system
US8448231B2 (en) 2010-10-05 2013-05-21 Guest Tek Interactive Entertainment Ltd. Walled garden system for providing access to one or more websites that incorporate content from other websites and method thereof
US9456018B2 (en) * 2010-12-22 2016-09-27 Aruba Networks, Inc. HTTP proxy based captive portal
US9461878B1 (en) * 2011-02-01 2016-10-04 Palo Alto Networks, Inc. Blocking download of content
US8650495B2 (en) * 2011-03-21 2014-02-11 Guest Tek Interactive Entertainment Ltd. Captive portal that modifies content retrieved from designated web page to specify base domain for relative link and sends to client in response to request from client for unauthorized web page
US9332054B2 (en) * 2012-04-04 2016-05-03 Aruba Networks, Inc. Captive portal redirection using display layout information
US8984598B2 (en) * 2012-06-27 2015-03-17 International Business Machines Corporation Web-based security proxy for computing system environment scanning
US8977560B2 (en) * 2012-08-08 2015-03-10 Ebay Inc. Cross-browser, cross-machine recoverable user identifiers
CA2788573C (en) * 2012-09-06 2013-07-09 Guest Tek Interactive Entertainment Ltd. Allowing guest of hospitality establishment to utilize multiple guest devices to access network service
US20140089661A1 (en) * 2012-09-25 2014-03-27 Securly, Inc. System and method for securing network traffic
CN102868758B (en) * 2012-09-29 2016-12-21 华为技术有限公司 Push method portals and network equipment
US9973501B2 (en) 2012-10-09 2018-05-15 Cupp Computing As Transaction security systems and methods
US9178861B2 (en) 2012-10-16 2015-11-03 Guest Tek Interactive Entertainment Ltd. Off-site user access control
US20140153577A1 (en) 2012-12-03 2014-06-05 Aruba Networks, Inc. Session-based forwarding
US20140280883A1 (en) * 2013-03-15 2014-09-18 International Business Machines Corporation Secure URL update for HTTP redirects
GB201306443D0 (en) * 2013-04-09 2013-05-22 Mobbra Ltd Improvements in or relating to communicating with electronics devices
US20140325089A1 (en) * 2013-04-28 2014-10-30 Tencent Technology (Shenzhen) Company Limited Method, terminal, server and system for page jump
CA2851709A1 (en) 2013-05-16 2014-11-16 Peter S. Warrick Dns-based captive portal with integrated transparent proxy to protect against user device caching incorrect ip address
US8601565B1 (en) * 2013-06-19 2013-12-03 Edgecast Networks, Inc. White-list firewall based on the document object model
US9619644B2 (en) * 2013-07-03 2017-04-11 Facebook, Inc. Third-party captive portal
US9503371B2 (en) * 2013-09-04 2016-11-22 Nicira, Inc. High availability L3 gateways for logical networks
CN104426660A (en) * 2013-09-04 2015-03-18 中兴通讯股份有限公司 Portal authentication method, BNG (broadband network gateway), Portal server and Portal authentication system
US9577845B2 (en) 2013-09-04 2017-02-21 Nicira, Inc. Multiple active L3 gateways for logical networks
US9294462B2 (en) 2014-01-15 2016-03-22 Cisco Technology, Inc. Redirect to inspection proxy using single-sign-on bootstrapping
WO2015123611A3 (en) 2014-02-13 2015-11-05 Cupp Computing As Systems and methods for providing network security using a secure digital device
US9590901B2 (en) 2014-03-14 2017-03-07 Nicira, Inc. Route advertisement by managed gateways
US9426152B2 (en) 2014-07-08 2016-08-23 International Business Machines Corporation Secure transfer of web application client persistent state information into a new domain
US9118582B1 (en) 2014-12-10 2015-08-25 Iboss, Inc. Network traffic management using port number redirection
US10038628B2 (en) 2015-04-04 2018-07-31 Nicira, Inc. Route server mode for dynamic routing between logical and physical networks
WO2017078715A1 (en) * 2015-11-05 2017-05-11 Aruba Networks Inc. Policy enforcement based on host value classification
US9900301B2 (en) * 2015-12-14 2018-02-20 Amazon Technologies, Inc. Device management with tunneling
US20170279912A1 (en) * 2016-03-24 2017-09-28 Verizon Patent And Licensing Inc. Proxy for monitoring special handling of content within a service network
US10091161B2 (en) 2016-04-30 2018-10-02 Nicira, Inc. Assignment of router ID for logical routers

Citations (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5805803A (en) * 1997-05-13 1998-09-08 Digital Equipment Corporation Secure web tunnel
US5987611A (en) * 1996-12-31 1999-11-16 Zone Labs, Inc. System and methodology for managing internet access on a per application basis for client computers connected to the internet
US6088738A (en) * 1996-07-02 2000-07-11 Fujitsu Limited Communication control method and apparatus to connect a terminal to a host computer storing a desired program
US20020103760A1 (en) * 1998-01-16 2002-08-01 Ameritech Corporation Method and system for tracking computer system usage through a remote access security device
US6442257B1 (en) * 1999-06-15 2002-08-27 Siemens Aktiengesellschaft Configuration for charging in a telephone network and method for operating such a configuration
US20020164952A1 (en) * 2001-05-03 2002-11-07 Reefedge, Inc. Location-aware service proxies in a short-range wireless environment
US20020167919A1 (en) * 2001-04-10 2002-11-14 David Marples Location aware services infrastructure
US20020188562A1 (en) * 2001-06-07 2002-12-12 Yoichiro Igarashi Billing system, and device constituting same
US20030028532A1 (en) * 2000-03-31 2003-02-06 Toshio Dougu Method of and apparatus for controlling access to the internet in a computer system and computer readable medium storing a computer program
US6636894B1 (en) * 1998-12-08 2003-10-21 Nomadix, Inc. Systems and methods for redirecting users having transparent computer access to a network using a gateway device having redirection capability
US6684250B2 (en) * 2000-04-03 2004-01-27 Quova, Inc. Method and apparatus for estimating a geographic location of a networked entity
US20040054598A1 (en) * 2001-01-04 2004-03-18 Jan Kall Method of invoking privacy
US20040059802A1 (en) * 2002-06-24 2004-03-25 Christian Jacquemot Modeling states and/or transitions in a computer system
US6757518B2 (en) * 2000-03-11 2004-06-29 Hewlett-Packard Development Company, L.P. Position discovery using short range mobile devices
US20040139204A1 (en) * 2001-04-23 2004-07-15 Siegried Ergezinger Architecture for providing services in the internet
US6772214B1 (en) * 2000-04-27 2004-08-03 Novell, Inc. System and method for filtering of web-based content stored on a proxy cache server
US20040196806A1 (en) * 2002-05-30 2004-10-07 Siegried Loeffler Method and device for access control to a wireless local access network
US20040210640A1 (en) * 2003-04-17 2004-10-21 Chadwick Michael Christopher Mail server probability spam filter
US20040214576A1 (en) * 2003-04-28 2004-10-28 Chantry Networks Inc. Wireless network communication system and method
US6816460B1 (en) * 2000-03-14 2004-11-09 Lucent Technologies Inc. Location based routing for mobile ad-hoc networks
US20050026596A1 (en) * 2003-07-28 2005-02-03 Oren Markovitz Location-based AAA system and method in a wireless network
US20050055578A1 (en) * 2003-02-28 2005-03-10 Michael Wright Administration of protection of data accessible by a mobile device
US20050097320A1 (en) * 2003-09-12 2005-05-05 Lior Golan System and method for risk based authentication
US20050114680A1 (en) * 2003-04-29 2005-05-26 Azaire Networks Inc. (A Delaware Corporation) Method and system for providing SIM-based roaming over existing WLAN public access infrastructure
US6922843B1 (en) * 1999-08-09 2005-07-26 United Video Properties, Inc. Interactive television program guide system with multiple account parental control
US20050177515A1 (en) * 2004-02-06 2005-08-11 Tatara Systems, Inc. Wi-Fi service delivery platform for retail service providers
US20050261970A1 (en) * 2004-05-21 2005-11-24 Wayport, Inc. Method for providing wireless services
US20050286421A1 (en) * 2004-06-24 2005-12-29 Thomas Janacek Location determination for mobile devices for location-based services
US20060021009A1 (en) * 2004-07-22 2006-01-26 Christopher Lunt Authorization and authentication based on an individual's social network
US20060031407A1 (en) * 2002-12-13 2006-02-09 Steve Dispensa System and method for remote network access
US7006453B1 (en) * 2000-03-14 2006-02-28 Lucent Technologies Inc. Location based routing for mobile ad-hoc networks
US7013149B2 (en) * 2002-04-11 2006-03-14 Mitsubishi Electric Research Laboratories, Inc. Environment aware services for mobile devices
US20060056317A1 (en) * 2004-09-16 2006-03-16 Michael Manning Method and apparatus for managing proxy and non-proxy requests in telecommunications network
US7096491B2 (en) * 2001-07-20 2006-08-22 Hewlett-Packard Development Company, L.P. Mobile code security architecture in an application service provider environment
US20060253447A1 (en) * 2002-03-08 2006-11-09 Ciphertrust, Inc. Systems and Methods For Message Threat Management
US7171460B2 (en) * 2001-08-07 2007-01-30 Tatara Systems, Inc. Method and apparatus for integrating billing and authentication functions in local area and wide area wireless data networks
US7324469B2 (en) * 2003-09-29 2008-01-29 System Services, Inc. Satellite distributed high speed internet access
US20080109331A1 (en) * 2004-05-12 2008-05-08 Togewa Holding Ag Method and System for Content-Based Billing in Ip Networks

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7698463B2 (en) * 2000-09-12 2010-04-13 Sri International System and method for disseminating topology and link-state information to routing nodes in a mobile ad hoc network
CA2488500A1 (en) * 2002-06-07 2003-12-18 Duke University Substituted porphyrins
US8046578B1 (en) * 2004-04-14 2011-10-25 Hewlett-Packard Development Comopany, L.P. System and method for providing HTML authentication using an access controller

Patent Citations (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6088738A (en) * 1996-07-02 2000-07-11 Fujitsu Limited Communication control method and apparatus to connect a terminal to a host computer storing a desired program
US5987611A (en) * 1996-12-31 1999-11-16 Zone Labs, Inc. System and methodology for managing internet access on a per application basis for client computers connected to the internet
US5805803A (en) * 1997-05-13 1998-09-08 Digital Equipment Corporation Secure web tunnel
US20020103760A1 (en) * 1998-01-16 2002-08-01 Ameritech Corporation Method and system for tracking computer system usage through a remote access security device
US6636894B1 (en) * 1998-12-08 2003-10-21 Nomadix, Inc. Systems and methods for redirecting users having transparent computer access to a network using a gateway device having redirection capability
US6442257B1 (en) * 1999-06-15 2002-08-27 Siemens Aktiengesellschaft Configuration for charging in a telephone network and method for operating such a configuration
US6922843B1 (en) * 1999-08-09 2005-07-26 United Video Properties, Inc. Interactive television program guide system with multiple account parental control
US6757518B2 (en) * 2000-03-11 2004-06-29 Hewlett-Packard Development Company, L.P. Position discovery using short range mobile devices
US7006453B1 (en) * 2000-03-14 2006-02-28 Lucent Technologies Inc. Location based routing for mobile ad-hoc networks
US6816460B1 (en) * 2000-03-14 2004-11-09 Lucent Technologies Inc. Location based routing for mobile ad-hoc networks
US20030028532A1 (en) * 2000-03-31 2003-02-06 Toshio Dougu Method of and apparatus for controlling access to the internet in a computer system and computer readable medium storing a computer program
US6684250B2 (en) * 2000-04-03 2004-01-27 Quova, Inc. Method and apparatus for estimating a geographic location of a networked entity
US6772214B1 (en) * 2000-04-27 2004-08-03 Novell, Inc. System and method for filtering of web-based content stored on a proxy cache server
US20040054598A1 (en) * 2001-01-04 2004-03-18 Jan Kall Method of invoking privacy
US20020167919A1 (en) * 2001-04-10 2002-11-14 David Marples Location aware services infrastructure
US20040139204A1 (en) * 2001-04-23 2004-07-15 Siegried Ergezinger Architecture for providing services in the internet
US20020164952A1 (en) * 2001-05-03 2002-11-07 Reefedge, Inc. Location-aware service proxies in a short-range wireless environment
US20020188562A1 (en) * 2001-06-07 2002-12-12 Yoichiro Igarashi Billing system, and device constituting same
US7096491B2 (en) * 2001-07-20 2006-08-22 Hewlett-Packard Development Company, L.P. Mobile code security architecture in an application service provider environment
US7171460B2 (en) * 2001-08-07 2007-01-30 Tatara Systems, Inc. Method and apparatus for integrating billing and authentication functions in local area and wide area wireless data networks
US20060253447A1 (en) * 2002-03-08 2006-11-09 Ciphertrust, Inc. Systems and Methods For Message Threat Management
US7013149B2 (en) * 2002-04-11 2006-03-14 Mitsubishi Electric Research Laboratories, Inc. Environment aware services for mobile devices
US20040196806A1 (en) * 2002-05-30 2004-10-07 Siegried Loeffler Method and device for access control to a wireless local access network
US20040059802A1 (en) * 2002-06-24 2004-03-25 Christian Jacquemot Modeling states and/or transitions in a computer system
US20060031407A1 (en) * 2002-12-13 2006-02-09 Steve Dispensa System and method for remote network access
US20050055578A1 (en) * 2003-02-28 2005-03-10 Michael Wright Administration of protection of data accessible by a mobile device
US20040210640A1 (en) * 2003-04-17 2004-10-21 Chadwick Michael Christopher Mail server probability spam filter
US20040214576A1 (en) * 2003-04-28 2004-10-28 Chantry Networks Inc. Wireless network communication system and method
US20050114680A1 (en) * 2003-04-29 2005-05-26 Azaire Networks Inc. (A Delaware Corporation) Method and system for providing SIM-based roaming over existing WLAN public access infrastructure
US20050026596A1 (en) * 2003-07-28 2005-02-03 Oren Markovitz Location-based AAA system and method in a wireless network
US20050097320A1 (en) * 2003-09-12 2005-05-05 Lior Golan System and method for risk based authentication
US7324469B2 (en) * 2003-09-29 2008-01-29 System Services, Inc. Satellite distributed high speed internet access
US20050177515A1 (en) * 2004-02-06 2005-08-11 Tatara Systems, Inc. Wi-Fi service delivery platform for retail service providers
US20080109331A1 (en) * 2004-05-12 2008-05-08 Togewa Holding Ag Method and System for Content-Based Billing in Ip Networks
US20050261970A1 (en) * 2004-05-21 2005-11-24 Wayport, Inc. Method for providing wireless services
US20050286421A1 (en) * 2004-06-24 2005-12-29 Thomas Janacek Location determination for mobile devices for location-based services
US20060021009A1 (en) * 2004-07-22 2006-01-26 Christopher Lunt Authorization and authentication based on an individual's social network
US20060056317A1 (en) * 2004-09-16 2006-03-16 Michael Manning Method and apparatus for managing proxy and non-proxy requests in telecommunications network
US20110314149A1 (en) * 2004-09-16 2011-12-22 Michael Manning Method and Apparatus for Managing Proxy and Non-Proxy Requests In A Telecommunications Network

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Terabeam Wireless" Pub Date: 2/23/04 Page 1 *
Joel Short "Wireless Hotspots and WISP Roaming" Pub. Date: 2002 Pages 1-6 *

Cited By (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8996603B2 (en) 2004-09-16 2015-03-31 Cisco Technology, Inc. Method and apparatus for user domain based white lists
US7979849B2 (en) 2004-10-15 2011-07-12 Cisco Technology, Inc. Automatic model-based testing
US20060085681A1 (en) * 2004-10-15 2006-04-20 Jeffrey Feldstein Automatic model-based testing
US8336092B2 (en) * 2005-02-18 2012-12-18 Duaxes Corporation Communication control device and communication control system
US20090178116A1 (en) * 2005-02-18 2009-07-09 Duaxes Corporation Communication control device and communication control system
US8006285B1 (en) 2005-06-13 2011-08-23 Oracle America, Inc. Dynamic defense of network attacks
US9015090B2 (en) * 2005-09-06 2015-04-21 Daniel Chien Evaluating a questionable network communication
US20130333038A1 (en) * 2005-09-06 2013-12-12 Daniel Chien Evaluating a questionable network communication
US9912677B2 (en) 2005-09-06 2018-03-06 Daniel Chien Evaluating a questionable network communication
US9674145B2 (en) * 2005-09-06 2017-06-06 Daniel Chien Evaluating a questionable network communication
US20150229609A1 (en) * 2005-09-06 2015-08-13 Daniel Chien Evaluating a questionable network communication
US8924459B2 (en) * 2005-10-21 2014-12-30 Cisco Technology, Inc. Support for WISPr attributes in a TAL/CAR PWLAN environment
US20070094401A1 (en) * 2005-10-21 2007-04-26 Francois Gagne Support for WISPr attributes in a TAL/CAR PWLAN environment
US7760722B1 (en) * 2005-10-21 2010-07-20 Oracle America, Inc. Router based defense against denial of service attacks using dynamic feedback from attacked host
US9877147B2 (en) * 2005-10-21 2018-01-23 Cisco Technology, Inc. Support for WISPr attributes in a TAL/CAR PWLAN environment
US20070214265A1 (en) * 2006-03-07 2007-09-13 Sbc Knowledge Ventures Lp Scalable captive portal redirect
US9432920B2 (en) 2006-09-06 2016-08-30 Devicescape Software, Inc. Systems and methods for network curation
US20110047603A1 (en) * 2006-09-06 2011-02-24 John Gordon Systems and Methods for Obtaining Network Credentials
US20110040870A1 (en) * 2006-09-06 2011-02-17 Simon Wynn Systems and Methods for Determining Location Over a Network
US20090024550A1 (en) * 2006-09-06 2009-01-22 Devicescape Software, Inc. Systems and Methods for Wireless Network Selection
US9326138B2 (en) 2006-09-06 2016-04-26 Devicescape Software, Inc. Systems and methods for determining location over a network
US9913303B2 (en) 2006-09-06 2018-03-06 Devicescape Software, Inc. Systems and methods for network curation
US8667596B2 (en) 2006-09-06 2014-03-04 Devicescape Software, Inc. Systems and methods for network curation
US8549588B2 (en) 2006-09-06 2013-10-01 Devicescape Software, Inc. Systems and methods for obtaining network access
US8743778B2 (en) 2006-09-06 2014-06-03 Devicescape Software, Inc. Systems and methods for obtaining network credentials
US20080060064A1 (en) * 2006-09-06 2008-03-06 Devicescape Software, Inc. Systems and methods for obtaining network access
US8554830B2 (en) 2006-09-06 2013-10-08 Devicescape Software, Inc. Systems and methods for wireless network selection
US20080140841A1 (en) * 2006-12-08 2008-06-12 Robert Ott Method and apparatus for detecting the IP address of a computer, and location information associated therewith
US20080209524A1 (en) * 2007-02-23 2008-08-28 Microsoft Corporation Caching public objects with private connections
US8091124B2 (en) 2007-02-23 2012-01-03 Microsoft Corporation Caching public objects with private connections
EP2061205A2 (en) * 2007-11-16 2009-05-20 Hewlett-Packard Development Company, L.P. Method and apparatus for accessing a network
US20090133109A1 (en) * 2007-11-16 2009-05-21 Hewlett-Packard Development Company, L.P. Method and apparatus for accessing a network
EP2061205A3 (en) * 2007-11-16 2009-06-17 Hewlett-Packard Development Company, L.P. Method and apparatus for accessing a network
US9143494B2 (en) * 2007-11-16 2015-09-22 Hewlett-Packard Development Company, L.P. Method and apparatus for accessing a network
US8353007B2 (en) 2008-10-13 2013-01-08 Devicescape Software, Inc. Systems and methods for identifying a network
US20100095359A1 (en) * 2008-10-13 2010-04-15 Devicescape Software, Inc. Systems and Methods for Identifying a Network
US20100263022A1 (en) * 2008-10-13 2010-10-14 Devicescape Software, Inc. Systems and Methods for Enhanced Smartclient Support
JP2012515956A (en) * 2009-01-16 2012-07-12 デバイススケープ・ソフトウェア・インコーポレーテッド System and method for enhanced smart client support
US8693654B2 (en) * 2009-02-23 2014-04-08 International Business Machines Corporation Location sensitive caller and callee based call prioritization
US20100215163A1 (en) * 2009-02-23 2010-08-26 International Business Machines Corporation System and method of location sensitive caller and callee based call prioritization
US20120039452A1 (en) * 2009-03-16 2012-02-16 Guenther Horn Communication Connection Establishment Control for Preventing Unsolicited Communication
US8169945B2 (en) 2010-06-17 2012-05-01 Google Inc. Maintaining network connectivity
US8228837B2 (en) 2010-06-17 2012-07-24 Google Inc. Maintaining network connectivity
US8700782B2 (en) * 2010-08-18 2014-04-15 Microsoft Corporation Directing modalities over different networks in multimodal communications
US20120047270A1 (en) * 2010-08-18 2012-02-23 Microsoft Corporation Directing modalities over different networks in multimodal communications
US9462071B2 (en) 2012-03-06 2016-10-04 Cisco Technology, Inc. Spoofing technique for transparent proxy caching
US9665881B1 (en) * 2012-05-04 2017-05-30 Amazon Technologies, Inc. Physical store online shopping control
US10084791B2 (en) 2013-08-14 2018-09-25 Daniel Chien Evaluating a questionable network communication
EP3086530A4 (en) * 2013-12-19 2016-12-07 Zte Corp Network resource sharing processing and sharing method, device and system
CN104735101A (en) * 2013-12-19 2015-06-24 中兴通讯股份有限公司 Network resource sharing processing method and device and network resource sharing method and system
US20160261499A1 (en) * 2015-03-03 2016-09-08 APPLIED RESEARCH WORKS Inc. Computerized System and Method for Providing Sponsored Internet Access

Also Published As

Publication number Publication date Type
US20060056317A1 (en) 2006-03-16 application
US8527629B2 (en) 2013-09-03 grant
US8127008B2 (en) 2012-02-28 grant
US20110314149A1 (en) 2011-12-22 application

Similar Documents

Publication Publication Date Title
US7120148B1 (en) System and method for providing source awareness in a wireless application protocol network environment
US7127524B1 (en) System and method for providing access to a network with selective network address translation
US5835727A (en) Method and apparatus for controlling access to services within a computer network
US6603758B1 (en) System for supporting multiple internet service providers on a single network
US8584199B1 (en) System and method to apply a packet routing policy to an application session
US6081900A (en) Secure intranet access
US7689716B2 (en) Systems and methods for providing dynamic network authorization, authentication and accounting
US7516198B1 (en) Arrangement for providing content-based quality of service for a service flow based on parsing XML tags detected from a server response to a client request
US7478427B2 (en) Method and apparatus for providing adaptive VPN to enable different security levels in virtual private networks (VPNs)
US7849495B1 (en) Method and apparatus for passing security configuration information between a client and a security policy server
US8200818B2 (en) System providing internet access management with router-based policy enforcement
US8266266B2 (en) Systems and methods for providing dynamic network authorization, authentication and accounting
US6718388B1 (en) Secured session sequencing proxy system and method therefor
US7463637B2 (en) Public and private network service management systems and methods
US20060080441A1 (en) Flexible automated connection to virtual private networks
US20120005745A1 (en) Vpn network client for mobile device having dynamically translated user home page
US7747720B2 (en) Arrangement for selecting a server to provide distributed services from among multiple servers based on a location of a client device
US20020075844A1 (en) Integrating public and private network resources for optimized broadband wireless access and method
US6892225B1 (en) Agent system for a secure remote access system
US20050228874A1 (en) Method and system for verifying and updating the configuration of an access device during authentication
US20040034797A1 (en) Domain-less service selection
US20040122956A1 (en) Wireless local area communication network system and method
US20060171402A1 (en) Method and system for providing broadband multimedia services
US20020029260A1 (en) Directory-enabled intelligent broadband service switch
US20040010719A1 (en) Method, a portal system, a portal server, a personalized access policy server, a firewall and computer software products for dynamically granting and denying network resources

Legal Events

Date Code Title Description
AS Assignment

Owner name: CISCO TECHNOLOGY, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MANNING, MICHAEL;BURSHAN, CHEN YEHEZKEL;SOWATSKEY, NATHAN JOHN;AND OTHERS;REEL/FRAME:016154/0510;SIGNING DATES FROM 20041205 TO 20050103