GB2498566A

GB2498566A - Authenticating a user at a proxy using cookies

Info

Publication number: GB2498566A
Application number: GB1200991.6A
Authority: GB
Inventors: Bradley Kite
Original assignee: DOLPHIN SPEED NETWORKS Ltd
Current assignee: DOLPHIN SPEED NETWORKS Ltd
Priority date: 2012-01-20
Filing date: 2012-01-20
Publication date: 2013-07-24
Also published as: GB201200991D0

Abstract

In an Internet Service Provider 2 via which a user at a terminal (102) outside its Local Area Network 1 may access remote resources 3 via an access node proxy server (200), users are identified by a terminal IP address embedded in their requests 1, which are analysed 2 to determine whether they contain preconfigured path information ( first information ) and a cookie ( second information ). If the user requires authentication 3, a response is returned 4, and the user requests authentication from entity (210) using a location header 5, which authenticates the user 6 and saves the cookie for future reauthentication, returning an authentication code 7 to present to the proxy 8. The proxy again checks 9 for first and second information and indicates the resource 10. The users browser sets a cookie 11 received from the proxy and sends a fresh request 12, whereupon the proxy check authentication 13, obtains the resource 14 and returns it to the user 15. The authentication entity may alternatively reside in the first LAN (110).

Description

METHOD OF AUTHENTICATING A USER

The present invention relates to establishing the identity of a user, preferably for ihe purpose of controlling access to a resource. More specifically, the invention relates to a method of S establishing the identity of a user, to an apparatus configured to perform the method, and to a computer program product for causing an apparatus to perfonn the method.

Many schools, universities, businesses and households now have several computers, or workstations, for use by their pupils, staff employees, or residents. These workstations are often connected together in a local network and allow the users thereof to access resources outside of the local network, such as via an Internet Service Provider and an external network, such as the Internet. It is often desirable, particularly in businesses, schools and households, to he able to identF' the users that are accessing certain resources, such as streaming media and/or material intended only for adult consumption, stored at external locations. In some cases, it is desirable to allow some users to access certain material and to prevent other users from accessing that certain material. Various systems and methods have been provided to control users' access to resources, and some of these known methods and systems provide a personalised service. That is, they are configurable to control access to resources on a user-by-user basis.

Current Hypertext Transfer Protocol (HTTP) proxy systems are capable of directly integrating with only a single Active Directory domain. Usually workstations of a single organisation are part of that organisation's single Active Directory domain. 1-lowever, some user authentication systems, such as Kerberos and NTLM (NT LAN Manager), are unable to work in cases where it is desired to provide personalised services (i.e. services on a user-by-user basis) to organisations, when the workstations of the organisation are for some reason in different respective domains. In order to use Kerberos or NTLM, it is necessary to deploy a software application or a hardware device at the organisation, i.e. within the organisation's local network, which application/device integrates with the organisation's Active Directory.

The applicationldevice can be considered to "join" the domain. That is, the applieationldevice becomes a part of the domain so that the applieation!device can authenticate users in the domain against the active directory services. In such arrangements, control of access to resources outside of the organisation's network is performed by the applieatiouldevice within the organisation's network, such that all traffic, including requests, from the users' clients is analysed by the software/hardware, and requests for certain resources are denied by the sofflvare/hardware. Such an arrangement is costly to the organisation and inconvenicnt to set up.

In other cases, a user may he asked to login to a workstation. It is known to run software at the workstation, which software knows an identifier (e.g. an IP address) of the workstation and receives an identifier (e.g. a usernarne) of the user following such login. The software then provides to a service-provider, such as an Internet Service Provider (ISP), an indication of the username that is associated with the IP address of the workstation, such that the service provider may map the identity of the user to the identity of the workstation. When tile service provider's network subsequently sees traffic sent from the IP address of the workstation, the service provider will recoise that the traffic is from the specific user and is able to permit or deny requests from the specific user for access to resources. Accordingly, the service provider is able to control on a user-by-user basis what resources users are permitted to access.

While this latter arrangement can be more convenient and less costly than the previously described arrangement for controlling the resources users can access, such an arrangement has inherent limitations because it requires that the user's workstation be part of the organisation's domain, When a user intends to use their personal, home workstation at the organisation, which personal workstation is not part of the domain, the workstation will not have the necessary login software installed for execution by the user to login. Also, some users will have devices such as mobile phones and Personal Digital Assistants (PDAs), which are unable to run the required login script even though the user has a domain account.

Moreover, frequently a Network Address Translation NA'l') device, such as a hardware or software firewall (termed a "restrictive entity" herein) or a proxy, is disposed en route between the service provider's network and the workstation or a local network to which the workstation is connected. NAT devices assign a public address to a workstation (or group of workstations) inside a local, private network, often to limit the number of public IP addresses that an organisation must use, for one or both of economy and security purposes. In such eases, when a workstation inside the private network makes a request for a resource that is stored on the Internet (i.e. on the public side of the NAT device), the NAT device, instead of simply forwarding to the service provider the request \vitil the private IP address of the workstation, intercepts the request and modifies or replaces the request with one that includes a public IP address of the NAT device instead of the local IP address of the workstation.

When a NAT device is used in this way, all requests sent from workstations inside the private, local network to the service provider have the same public I P address. Accordingly, the service provider is unable to differentiate users to idcnti' which user is requesting a rcsource, and thus is unable to control on a user-by-user basis the resources users are permitted to access.

By associating a first local network, e.g. for pupils of a school, with a first NAT device that has a first public IP address, and in parallel associating a second local network, e.g. for staff of the school, with a second NAT device that has a second, different public IP address, it is possible for the service provider to identify whether a request has emanated from a pupil or a member of staff by determining the public IP address included in the header of the request.

Although the service provider may thus allow members of staff to access different or additional resources to pupils, the service provider is unable to control on a user-by-user basis what resources users are permitted to access. While it would in theory be possible to provide a separate, respective NAT device for each individual workstation, in order tEat the service provider can map a user identity to the public address of the NAT device associated with the user's workstation, it is readily apparent that such an arrangement is costly, overly complicated, and not an efficient use of resources.

Accordingly, there is a need for a more convenient, simpler and/or efficient access control method and apparatus by which users' access to resources is controllable on a user-by-user basis. There is also a need for such access control that is compatible with the provision of a restrictive entity between a local network of users and an external network, via which external network the users wish to access resources, There is also a need for an access control method and apparatus that overcomes or obviates the problems described above.

The present invention aims to provide an improved method of authenticating a user and an nnproved apparatus for authenticating a user, preferably which permit users' access to resources to he controlled on a user-by-user basis.

Accordingly, in a first aspect, the present invention provides a method of identifying a user who is attempting to access a resource, comprising: receiving, via or at an access node of a network, a request from a client for access to a resource; determining whether a user associated with tile client is authenticated; and initiating authentication of the user when it is determined that the user is not authenticated.

Preferably the method comprises analysing the request. Preferably, the method comprises determining whether the request comprises first information indicating that the user is authenticated. The first information may be unique to the user. The first information may comprise an identifier of the user. The first information may he comprised in a path identifying the resource requested. The method may comprise determining that the user is not authenticated when the request is free of the first information.

The initiating may comprise sending a response to the client. Preferably, the response comprises an indication of an authentication entity.

The method may he a method of operating a network element to control access to the resource, wherein the client and the network element communicate according to a request/response styk protocol, such as the Hypertext Transfer Protocol (}-ITTP). Preferably the response is of a format which, according to the protocol, would cause the client to issue a new request after the client receives the response. Preferably the response comprises a redirect.

The method may comprise determining that the user is authenticated when the request comprises the first information.

The method may comprise receiving, from the client, a second request for access to the resource. The method may comprise analysing the second request. Preferably the method comprises determining whether the second request comprises the first information. The method may comprise determining that the user is authenticated when the second request comprises the first information.

The method may comprise sending a second response to the client when it is determined that the second request is free of second information indicating that the user is authenticated, which second information is independent of the first information, and when the second request comprises the first information.

The method may comprise (letenmmng whether the second request comprises second information indicating that the user is authenticated. The second information preferably is independent of the first information. The method may comprise sending a second response to the cflent when it is determined that the second request is free of the second information. The second response may comprise a request or an instruction for the client to store the second information.

Preferably, the method comprises processing the second request when it is determined that the second request comprises second information indicating that the user is authenticated.

The second information preferably is independent of the first information. The second information may comprise a cookie.

The method may comprise processing the second request when it is determined that the second request comprises the first information.

The processing may comprise sending a response to the client, which response comprises a copy of content of the resource.

The initiating may comprise determining an authentication entity to be used in authenticating the user. The method may comprise determining an authentication entity on the basis of an indication of a source of the request. The method may comprise determining an authentication entity on the basis of the resource requested. The method may comprise determining an authentication entity on the basis of other information comprised in the request. The initiating may comprise sending a request to an authentication entity.

The method may be a method of operating a network entity, which comprises an authentication entity. lihe initiating may comprise the authentication entity initiating the authentication of the user.

The first information may be independent of any indication of the identity of client. The first information may be independent of any indication of a source of the request. The first information may be independent of any indication of a source of the second request.

S

The second information may be independent of any indication of the identity of the client.

The second information may be independent of any indication of a source of the request. The second information may be independent of any indication of a source of the second request.

S The method may he a method of operating a network element to control access to the resource, optionally wherein the network element, comprises, or is comprised in, a server of an Internet Service Provider (ISP).

In a second aspect, the present invention provides a computer program product for causing an apparatus to perform the method of the first aspect of the present invention, which method may include any of the optional features discussed above.

In a third aspect, the present invention provides an apparatus comprising at least one processor and at least one memory including computer program code for one or more programs, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform the method of the first aspect of the present invention, which method may include any of the optional features discussed above, In a fourth aspect, the present invention provides a network element for identifying a user who is attempting to access a resource, the network element comprising: a receiver configured to receive, via or at an access node of a network, a request from a client for access to a resource; a determiner configured to detemñne whether a user associated with the client is authenticated; and an initiator configured to initiate authentication of the user when it is determined that the user is not authenticated. That is, in some embodiments of the present invention, the network element is the access node.

The network may be a non-cellular network, optionally comprising the Internet. Ilie network may be that of an Internet Service Provider (ISP).

The apparatus of the third aspect, and/or the network clement of the fourth aspect, may comprise, or be comprised in, a computer, such as a server, of an Internet Service Provider (ISP).

The resource may be located in a network that is a non-cellular network, such as the Internet.

Embodiments of the present invention will now be described by way of example only with reference to the accompanying drawings, in which: Figure 1 is a schematic diagram illustrating a system comprising a first embodiment of the present invention; Figure 2 is flow diagram illustrating a method according to the first embodiment of the present invention; Figure 3 is a schematic diagram illustrating a system comprising a second embodiment of the present invention; and Figure 4 is flow diagram illustrating a method according to the second embodiment of the present invention.

While the following example embodiments are described in the context of the Hypertext Transfer Protocol (HTTP), in which messages are formatted and sent according to the FITTP protocol, and in the context of the Internet Protocol (IP), in which elements or devices are identified using an TP address, the present invention is not limited to systems and methods that operate according to the HTTP and IP protocols. That is, in other embodiments of the present invention, messages may be formatted and sent according to non-HTTP request/response style protocols and/or elements may he identified using non-TP addresses.

The concept of request/response (or request/reply) protocols will be understood by the skilled person. It is sufficient to say that such a protocol is a method of communicating between computers in which a first computer requests some data and the second computer responds to the request. The response can trigger a new request.

A first embodiment of the present invention will now be described, with reference to Figures 1 and 2. Figure 1 is a schematic illustration of a system comprising a first network 1, a second network 2 to which the first network I is connected via one of a wired and/or wireless connection 6, and a third network 3 to which the second network 2 is connected.

WIii Ic in the ii lustrated example the lirst network I is connected lo the third network 3 only via thc sccond network 2, optionally in othcr cmbodimcnts thc first nctwork I may have a connection to the third network 3 that is not via the second network 2, such as a direct connection between the first arid third networks 1, 3. While in the illustrated example the second network 2 is distinct from the third network 3, in other embodiments the second and third networks 2, 3 may he the same network, Elements and entities in the second network 2 are outside of the first network 1. Likewise, in this example, elements and entities in the third network 3 are outside of the first network 1.

The first network 1 is connected to the second network 2 via an access node (or "service node" or "edge switch"), which access node may be the illustrated network element 200 or, alternatively, may be a different entity (not shown) of the second network 2. the access node is an element that is located at the perimeter of the second network 2 and via which the first network I is connected to the second network 2. In any event, the access node is located outside of the first network 1, is disposed between the client 100 and the network element 200, and communications between the first and second networks 1, 2 pass through the access node.

In this example, the third network 3 is a non-cellular network, which comprises the Internet.

Preferably one or both of the second and third networks 2, 3 are non-cellular networks, The Internet 3 comprises many interconnected elements. Each of these elements is inter-coupled with the rest of the Internet 3, and is configured to communicate data with other such elements over the Tnternet 3 by transmitting and receiving data in the form of Tnternet Protocol (IP) packets. Each element also has an associated TP address usable in the Internet 3 to locate the element. It will be appreciated that many elements make up the Internet and this is represented schematically in Figure 1 by a communications cloud 3, which will include many end-user tenninals, servers and gateways, as well as routers of Tntemet Service Providers (ISP5) and Internet backbone routers.

Ilie first network I may he a local network within a school, university, company or household, preferably where this organisation does not have its own user directory. The first network I compnses at least one workstation or terminal 102, such as a desktop computer, laptop, notebook, or netbook, which is operable by a user, The end-user terminal 102 is F installed with software in the form of a client 100, which preferably compriscs a web browscr 100. When exeeLtted, [lie client 100 allows [lie end-user tenninal 102 to establish bidirectional communication channcls with other network elements via the second network 2 and the Internet 3, in order that the user of the terminal 102 may access a service or resource, such as a webpagc, located outside of the first network 1 via the second and/or third networks 2, 3.

The second network 2 is that of an Internet Service Provider (ISP), and comprises a plurality of interconnected elements. The elements shown explicitly in Figure 1 are a network element (server) 200, and an authentication entity 210 and a database 220, which are each connected to the scrver 200, The server 200 enables the client 100 to communicate with elements in or via the Tnternet 3. That is, via the scrver 200, the client 100 may access a service or resource in or via the Tnternet 3. As mentioned above, the second network 2 and the third network 3 may be the same network. The second network 2 is distinct and independent of the first network I. Figure 2 is flow diagram illustrating a method according to the first embodiment of the present invention. Whcn the user of the teiminal 102 wishes to gain access to a resource, in this case a wehpage, stored outside of the first network I, and preferably in or beyond the Tnternet 3, a request message requesting access to the resource is generated at the browser and is then sent (as indicated by reference numeral 1) from the browser 100 to (or transparently via) the server 200 of the ISP to which the browser 100 is cormected. The server 200 is considered to intercept the message when acting as a transparent proxy.

Alternatively, when the server 200 is acting as an explicit proxy, the message is addressed so as to be for the attention of the server 200. In this embodiment, the request message has the following structure: GET http://www.dolphinspeednetworks.com/ H1TP/1.1 Host: www.dolphinspeednetworks.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; enGB; rv:1.9.2) Gecko/ZOlOOllSFirefox/3.6 Accept: text/htmI,application/xhtmlIxmI,appIication/xml;q=0.9,*/*;q=0.8 Accept-Language: en-gb,en;q=0.5 Accept-Encoding: gzip1deflate Accept-Charset: lSO88591,utf8;q=0.7,*;q=0.7 Keep-Alive: 115 That is, iii this embodiment, the request message is according to the IITTP protocol. The first linc, known as the requcst line', of the message contains the Hill' method, the Ilniforni Resource Locator (URL) of the resource requested, and the version (1.1) of HTTP that is being used. As the skit lcd person will readily understand, the 1-llTP method specifies the operation that the browser 100 has requested, in this case the GET method, which requests a representation of the identified resource; the URL specifies the location of the resource requested and acts as an indication of the resource requested, and the rest of the mcssagc consists of a set of name/value pairs, known as headers', which clients usc to control how requests arc processed by servers. Accordingly, no further discussion of this request message will be given, other than to emphasise that the message is free of any indication that the user, i.e. the person using the browser 100 from which the message is received, is authenticated, the message is free of any indication of the identity of the user of the browser 100 and free of any authentication cookie, In some embodiments the request passes through the access node en route from the client 100 to the server 200. In other embodiments, the access node is at the server 200, and thus the request may be considered to be received at the access node.

the server 200 receives the message and determines 2 whether the user is authenticated and, thus, is permitted to access the resource. In this embodiment, the server 200 determines 2 whether the message includes any indication that the user is authenticated, In this embodiment, the server 200 first determines whether the request message comprises predetermined "second information", which in this embodiment is a cookie (sec discussion below). In the absence of the second information, the server 200 then determines whether the request message comprises prcdctcmiincd "fir st information", which in this embodiment is a prc-configurcd path, in the request line, as also discussed below, Since the message excludes the cookie and the preconfigured path, i.e. both the first and second information (i.e. i'espective first and second indicators of whether the user of the client 100 is authenticated), referred to below, the server 200 accordingly determines that the user is not authenticated, i.e. unauthenticated, l'his determination could he made based on analysis of the message by the server 200 itself or, alternatively, based on a result of analysis of the message by an cntity different from the server 200, which result is received by the server 200.

In sonic embodiments, the request can be saved (either iii memory or on disk) by the server 200, and a unique code (or session id) assigned to the saved request so that tile request can he retrieved later. If the request contains any further information (for example, a request body along with a header), then this information can also be saved.

As a result of a determination that the user is not authenticated (i.e. unauthenticated), the server 200 determines 3 that the user is to be authenticated. The server 200 initiates authentication of the user by determining an authentication entity 210 that is to be used in authenticating the user of the browser 100. This determination could be made by the server 200 selecting the authentication entity 210 from a list of different authentication entities, for example based on the resource requested, and/or based on an indication, such as a source IP address, of' the source of the received request message, and/or based on other information within the request message, such as an indication, e.g. a destination port, of the intended destination of the message. That is, in some embodiments, the server 200 maps the source IP address or information in the request message to a plurality of identifiers of authentication entities held in a list or in a database 220 in the second network 2 to which the server 200 has access. In other embodiments, the server 200 may always select the same authentication entity 210, particularly if only one authentication entity 210 exists, It is to be noted that the source ll address, or other indication of the source, of the received message is the indication of source as seen by the server 200. This may not necessarily be the actual source IP address of the client 100. For example, as discussed above, there may be one or more intervening elements, such as a proxy server or a NAT device (e.g. a firewall), between the client 100 and the server 200, in which case the indication of the source, such as the source IP address, may be an indication of the intervening element and not an indication of the client 100, That is, the source lP address of the received request message may be a public IP address or identifier of' the intervening proxy element or NAT device, and not an IP address or identifier specifically assigned to the user's workstation at which the client 100 is running.

In some embodiments, the server 200 may be configured to allow unauthenticated access to some resources. One or more control lists may be provided, which control list(s) indicate which resources require a user to he authenticated in order to access the resource, and which resources may he accessed without the user being authenticated. In these scenarios, a determination as to whether or not authentication is required will be macic, for example based on the indication of the resource requested and/or on Ue basis of the indication of the source of the received request message and/or on the basis of other information, such as other information in the received request message. In some eases, a default stance will be taken requiring that all requests require a user requesting access to a resource to be authenticated.

Such control list(s) may be accessible by the server 200 itself; in order for the server 200 to determine whether authentication is required or not, or the server 200 may conmiunicate with another entity that has access to such control list(s) and that other entity informs the server whether authentication is required or not, In this embodiment, the authentication entity 210 determined by the server 200 is located in the second network 2 and is accessible by the browser 1 00 via the server 200. having determined the authentication entity 210, the server 200 then sends 4 to the browser 100 a message comprising an indication of the authentication entity 210. In this embodiment, the message has the following structure: HTTP/1.0 302 Object Moved Location: http://authentication-agent,corr/authent/a uth,asp?authhost=www,dolphinspeednetworks.com&sessionid= 69a526966b22f6b0a7a20538ba912dc6 That is, in this embodiment, the message is an I-ITTP response with status code 302, i.e. a redirect message. Tn this embodiment, the indication of the authentication entity 210 takes the form of the URL of the authentication entity 210 being provided in the value of a header of the response that has the name Location. The message also includes an indication of the resource requested, in this case by way of the value of the "auth_host" parameter in the value of the Location header being the domain name of the resource requested. Other meta data about the request can be included, such as the session ID assigned to the original request (reference numeral 1) This sort of response or redirect message is traditionally used under the ITTTP protocol to indicate to a client that a requested resource has been moved, and that the client should issue a new request with the value of the Locat ion header of the response included in the request line of the request, In other embodiments of the present invention, the IITIP protocol may not be employed. In any case, the response or redirect message is a message that has a format suitable to cause the client 100 to issue a new request for the desired resource, which new request indicates a new location of the desired resource, which new location is delermined on the basis of the content of the response message.

Accordingly, the browser 100, after receiving the response message from the server 200, generates and sends S a new request message, this time with the value of the Location header of the response message included in the request line of the new request message. That is, the new request message inc'udes an indication of the resource requested and an indication of the authentication entity 210. As such, the new request message is directed to the authentication entity 210. In this embodiment, the message has the following structure: GET http:// authentication-agent.com/a uthent/auth.asp?auth_host=www.do Iphinspeed rtetworks.com&sessio nid= 69a526956b22f6b0a7a20538ba912dc6 HTTP/1.1 Host: authentication-agent.com User-Agent: Mozilla/S.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2) Gecko/ZOlOOllSFirefox/3.6 Accept: text/htnll,applicatiort/xhtml+xml,application/xmI;q=0.9,*/*;q=0.8 Accept-Language: en-gb,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,;q=0.7 Keep-Alive: 115 In the present embodiment, the new request message is sent via the server 200, which is configured to forward the request to the authentication entity 210 without performing steps 2 and 3. In alternative embodiments, the new request message may be sent from the browser 100 to the authentication entity 210 on a route that avoids the server 200.

After receiving the new request message, the authentication entity 210 authenticates 6 the user of the browser 100. This authentication can be according to any suitable method, such as Kerberos, NTLM HTTP authentication, Digest I-ITTP authentication, Basic I-ITTP authentication, or an I-ITML fonn which prompts for the usei's credentials which, when submitted, are able to be validated against entries in a database of username and password combinations.

As the skilled person will readily understand, in Basic HTTP authentication, the browser 100 (client) sends the user name and password of the user as unencrypted base64 encoded text to the server 200, It is recommended that this method should only be used with Hypertext Transfer Protocol Secure (HTTPS), since the password could easily be captured by a third party and reused over HTTP. In Digest I-ITTP authentication, the browser 100 (client) instead sends a hashed Rum ol Lhe password to (lie server 200, such that the password cannot be captured over HTTP. NTLM HTTP authentication uses a secure challenge/response mechanism that prevents password capture or replay attacks over HTTP. The Kerberos protocol is also known to the person skilled in the art, allowing user credentials to be validated by means of cryptographic "tickets".

In some embodiments, the authentication involves the user being presented with a webpage, such as a webpage comprising a form, via which the user is able to supply their credentials to the authentication entity 210. In such a scenario, in some embodiments, the authentication entity 210 uses a cookie to save the user's credentials to speed up re-authentication of the user in the thture, should the user need to re-authenticate. The credentials could be a usernarne and password, or other information. In some embodiments, the webpage comprising the form may present a set of avatar icons to the user of the client 100 for the user to select, which avoids the user needing to remember a usernarne and a password. For example, the user may be asked to select a particular combination or sequence of icons, so that the combination or sequence acts as secret information known only by the user and the authentication entity.

It will be appreciated that, in preferred embodiments, the specific authentication method by which authentication is carried out to permit the browser 100 to access the requested resource will be determined by or at the authentication entity 210. Any authentication method may be used in embodiments of the present invention, and the discussion herein of specific authentication methods is not to be considered limiting, unless otherwise stated in the claims.

Possible methods for authenticating the user will he known and understood by the skilled person, so no further discussion of the specifies of how the authentication is performed will be given.

In any ease, through the process of authentication, the authentication entity 210 determines an identity of the user of the browser 100, preferably ultimately by receiving the identity of the user from the browser, directly or indirectly. The authentication entity 21 0 then sends 7 to the browser 1 00 a response message comprising first information, e.g. a code, which the browser is later to present to the server 200 to indicate that the user has been authenticated.

the first inFormation, or code, is an indication that the user of the browser 100 has been authenticated. The first information can be any information and preferably is generated at the authentication entity 210. [n this embodiment, the first information comprises an indication of the identity of the user. That is, the first information is an identifier of the user. The first information need not comprise a known existing identity of the user, but the first information preferably should he unique to the user. In this embodiment, the response message has the following structure: HHP/1.1 302 object moved Date: Mon, 14 Mar 2011 20:42:14 GMT Location: http://www.dolphinspeednetworks.com/authent/setauth?user=the. authentjcated.user.identity&ses sio nid=69a52 6966b22f6b0a7a205 3 8ba 912dc6 Set-Cookie: ASPSESSIONIDQSTACBAR=0DHHGODDEFI<MECLPBNBMIELB; path=/ Cache-control: private That is, in this embodiment, the message is another HTTP response with status code 302, i.e. a redirect message. In this embodiment, the first infoi'mation, or code, comprises the pre-configured path (/authent!setauth...) included in the value of the Location header of the response. The message also includes an indication of the resource requested, in this example by way of the URL of the requested resource also being provided in the value of the Location header. That is, the value of the Location header comprises the URL of the requested resource and the first information tagged on the end of the URL of the requested resource, which in this example includes the parameter "user" that has a value that indicates the user's identity.

In this embodiment, the response message also includes a header with the name "Set-Cookie" which instructs the client 100 to store a cookie. Whether or not such a header is included in the message may depend upon the method of authentication used by the authentication entity 210. If a forms-based webpage is used as discussed above, then the line may be included to speed up re-authentication of the user in the future, should the user need to re-authenticate.

Alternatively, if an authentication method such as Kerberos, Digcst, Rasic or NTLM is used, then the header with the name "Set-Cookie" may he omitted, As discussed above, the response or redirect message is a message that has a format suitable to cause the client 1 00 to issue a new request for the desired resource, which new request indicates a new location of the desired resource, which new location is determined on the basis of the content of the response message. F Accordingly, after the browser 100 receives the response message from the authentication entity 210, the browser 100 generates and sends S a further request message to the server 200 with [lie value of [Fe LocaL ion header of the response message included in the request line of the further request message, Since the value of the Location header of the response message included the first mfonnation, or code, the further request message will also comprise the first information, or code. As such, the frirther request message comprises an indication that the user of the browser 100 has been authenticated, which in this example is the first information received from the authentication entity 210. In this embodiment, the further request message has the following structure:

GET

http://www.dolphinspeednetworks.com/authent/seta uth?user=the.authenticate d.use r.identity&ses sionid=69a526966b22f6b0a7a20538ba912dc6 HTTP/1.1 Host: www.dolphinspeednetworks.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6 Accept: text/html,application/xhtmkxml,application/xmI;q=0.9,*/*;q=0.8 Accept-Language: en-gb,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO88591,utf8;q=0.7,*;q=0.7 I(eep-Alive: 115 In this embodiment, the first information is included in the request line of the request message. The request message also includes an indication of the resource requested, in this example by way of the URL of the requested resource also being provided in the request line of the request message. That is, the request line of the request message comprises die URL of the requested resource and the first information, i.e. the pre-configured path (/authent/setauth...), tagged on to the end of the URL of the requested resource.

After the server 200 receives the further request message, the device determines 9 whether the user is authenticated, in this example by determining whether the further request message includes any indication that the user of the browser 100 is authenticated. In this embodiment, the server 200 determines whether the further request message comprises predetermined "second information" (see discussion below), for example a cookie. In the absence of the second information, the server 200 then determines whether the further request message comprises the predetermined "first information", i.e. in this example the pre-configured path in the request line in this embodiincit. LSince the further request message comprises the first nilorniation in the request line, the server 200 determines that the message includes the first information and that thc user is authcnticatcd.

On the basis of the determination that the message comprises the first information, the server 200 sends 10 to the browser 100 a thither response message comprising an indication of the resource requested. This indication can either be based on additional metadata passed in 8, either directly (due to it being supplied as an additional parameter) or via a lookup from a saved session (in which case the session ID will be supplied as an additional parameter). In this embodiment, the message has the following structure: HTTP/1.O 302 Object Moved Location: http://www.dolphinspeednetworks.com/ Set-Cookie: authent user=the.authenticated.user.identity; domain=.dolphinspeednetworks.com; pa th =/ In this embodiment, the message is a further HTTP response with status code 302, i.e. a further redirect, In this embodiment, the indication of the resource requested takes the form of the URI, of the resource being included in the value of the Location header of the response, in order to cause the browser 100 to issue a new request for access to the resource.

The further response message also comprises a header with the name Set -Cookie and a value indicating the name and value of a cookie to be stored by or at the user's terminal 102, It will be understood that a cookie is a piece of data that is issued by a server (e.g. the server 200), e.g. in an I-ITTP response, and stored for future use by a client, e.g. an HTTP client (e.g. the browser 100). The header with the name Set-Cookie in a response message is a request or instruction to the recipient, i.e. the client, to store a cookie with a designated name and value. Whenever the client is about to make a request, such as an HTTP request, it consults its local cookie store to sec if any unexpired cookies match the path and domain it is about to use. Any matching cookie values are submitted back to the server using the Cookie header, as shown below. This mechanism allows the server subsequently to identify individual users.

After receiving the further response message, the browser 100 sets 11 a cookie in its cookie store, based on the value of the Cookie header in the received further response message.

In other embodiments, a cookie as such may not he stored, However, the browser 100 may still cause information received in the further response message to be stored locally to the browser 100 and user, and submitted back to the server as, or as part of, "second information". in subsequent request(s) to allow the server subsequently to identify the user.

The browser 100 then again acts according to tile I-ITTP protocol and generates and sends 12 S a fresh request message, this time with the value of the Location header of the previous "firther response message" included in the request line of the fresh request message. The fresh request message comprises a second indication that the user is authenticated in the form of second information, which in this embodiment is an authentication cookie that also acts as an indication of the identity, or identifier, of the user. The second information is, or is based on, information sent by the server 200 to the browser 1 00 in the further response message.

The second information need not comprise a known existing identity of the user, but the second information preferably should be unique to the user. In this embodiment, the message has the following structure: GET http://www.dolphinspeednetworks.com/HlTP/l.l Host: www.dolphinspeednetworks.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-gb,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,t;q=0.7 Keep-Alive: 115 Proxy-Connection: keep-alive Cookie: authent_user=the.authenticated.user.identity After the fresh request message is received by the server 200, the server 200 determines 1 3 whether the fresh request message comprises any indication that the user is authenticated. As discussed above, the server 200 determines whether the fresh request message comprises the predetermined second information. Since the fresh request message includes the second information in the form of an authentication cookie, the server 200 determines that the user is authenticated and that the authentication cookie has been set, and accordingly processes the fresh request message by obtaining 14 the requested resource and sending 15 a response message to the browser 100, which response message comprises the contents of the requested resource.

It is worth noting that, although preferred, steps 10 to 12 are optional. In a variation to the described first embodiment, the setting and use of a cookie could be omitted, Having F

IX

received tile further request message at 8, tile server 200 could then fetch the contents of the requested resource at 9. However, in this variation, every individual further request from the client 100 received at the server 200 would need to he individually authenticated, which slows down the process of accessing the resource for the user. !hc setting and usc of a cookie as the second information in steps 10 to 12 avoids the need to individually authenticate each request, and thus streamlines the process.

As another variation to the described first embodiment, after step 2 and in place of steps 3 to 5, the server 200 could open a connection to the authentication entity 210 and issue a request thereto on behalf of the browser 100. however, this can limit the ability of the authentication entity 210 somewhat. For example, Kerheros/NTLM (or other "transparent" forms of authentication) are unlikely to work without modification. This variation also could complicate setting of cookies, since the browser 100 would believe it is communicating with the source of the requested resource, i.e. "dolphinspeednetworlcs.com" in the described embodiment, but gets a response from the authentication entity 210, i.e. "my-local-authentication-agent" in the described embodiment.

in a still further variation to the described first embodiment, the authentication entity 210 runs at the server 200. In such a variation, in place of steps 3 to 5, the server 200 could cause or instruct the authentication entity 210 to commence authentication of the user without requiring the user's client 100 to send a new request message to the authentication entity 210.

it will be appreciated that the first information and the second infoniiation are respective first and second indicators of whether the user of the client 100 is authenticated. The first information is an indicator of a first predetermined format, and the second information is an indicator of a second predetermined format, The first and second predetermined fonnats are preferably different, such that the server 200 may determine whether a received request comprises the first indicator or the second indicator, Both the first information and the second infoniiation used in this embodiment of the invention are independent of the IP address, or other identifier, of the client 100 or the workstation 102 at which the client 100 is running. The first information and the second information are also independent of the source IP address included in the request messages generated and sent by the client 100 and received by the server 200. Rather, the first information is indicative of the user of' the client 100, and is prelerably unique to the user, and is generated away from the client and workstation 100, 102, e.g. at the authentication entity 210, and assigned to the user of the client 100 by an entity outside of the user's local network 1. Accordingly, since authentication of the user is carried out using information representative of the user, irrespective of the hardware and software they use to send requests for access to resources, the present invention is able to control on a user-by-user basis what resources users are permitted to access. Moreover, the preseni invention operatcs suceessftully even when a proxy or a NAT device is located between the user's client 100 and the server 200.

A second embodiment of the present invention will now be described, with reference lo Figures 3 and 4. Figure 3 is a schematic illustration of a system similar lo that illustrated in Figure 1. Like elements are indicated with like reference numerals, and further discussion of those like elements will be omitted for conciseness. It will be appreciated that a difference between the system of the second embodiment and the system of the first embodiment is that, in the second embodiment, the first network 1 comprises an authentication entity 110 to which the browser 100 has access.

Figure 4 is flow diagram illustrating a method according to the second embodiment of the present invention. When the user of the terminal 102 wishes to gain access to a resource, in this case a webpage, outside of the first network 1, for example in or beyond the Internet 3, a request message requesting access to the resource is generated at the browser 100 and is then sent 21 from the browser 100 to (either directly, as in with a proxy, or indirectly i.e. routed via, as described above for the first embodiment) the server 200 of the ISP to which the browser 100 is connected. The format of the request message in this embodiment is the same as that sent at 1 in the first embodiment. Indeed, steps 21 and 22 are the same as respective steps 1 and 2 of the first embodiment, and so will not be described in detail again.

The access node discussed above is again present. In some embodiments the request passes through the access node en route from the client 100 to the server 200. In other embodiments, the access node is at the server 200, and thus the request may be considered to be received at the access node.

having determined 22 that the message received from the browser 100 excludes preclcterniiricd "second information", e.g. a cookie, and predetermined "first information", e.g. a pie-configured path, (i.e. respective first and second indicators of whether the user of the client 100 is authenticated), the server concludes that the request message excludes any indication that the user of the browser 100 is authenticated, ihe server 200 determines 23 an authentication entity 110 that is to be used in authenticating the user of the browser 100. In this second embodiment, the authentication entity 110 determined by the server 200 is located in the first network 1 and is accessible by the browser 100 without passing messages via the server 200. As for the first embodiment, this determination could comprise the server 200 selecting the authentication entity 110 from a list of different authentication entities, for example based on an indication, such as a source IP address, of the source of thc received request message or other information within the request message, such as an indication, e.g. a destination port, of the intended destination of the message. That is, in some embodiments, the server 200 maps the source IP address or other information in the request message to a plurality of identifiers of authentication entities held in a list or in a database 220 in the second network 2 to which the server 200 has access. In other embodiments, the server 200 may always select the same authentication entity 11 0, particularly if only one authentication entity 110 exists.

As mentioned above, it is to be noted that the source IP address, or other indication of the source, of the received message is the indication of source as seen by the server 200, and may not be the actual source IP address of the client 100. Also, in some embodiments, the server may be configured to allow unauthenticated access to some resources, One or more control lists may be provided and used, as discussed above.

In some embodiments, the authentication entity that the server 200 determines is to be used in authenticating the user could be selected from a plurality of authentication entities, which may be located in a plurality of networks, such as one or both of the first and second networks 1, 2.

Having determined the authentication entity 110, the server 200 then sends 24 to the browser a response message comprising an indication of the authentication entity 110. Again, in contrast to the first embodiment, in this second embodiment the indication comprises an indication of an authentication entity 110 located in the first network I. The format of the response message sent at 24 may be the same as that sent at 4 in the iirst emhodii-nenL i.e. a redirect message, hut with a difference that the URL of the authentication entity 110 in the first network 1 is provided in the value of the header of the response that has the name Location. This message may also optionally contain additional meta-data about the request, such a session ID if the original request was saved, After receiving the response message from the server 200, the browser 100 generates and sends 25 a new request message to the authentication entity 110. In this embodiment, the message has the same structure as the message sent at 5 in the first embodiment, with the value of the LocaL Lon header of the response message received at 24 included in the request line of the new request message. As such, the new request massage includes an indication of the resource requested and an indication of the authentication entity 110. The new request message may he sent via the server 200 or alternatively on a path that excludes the server 200.

After receiving this new request message, the authentication entity 110 authenticates 26 the user of the browser 100. TIus authentication can be according to any suitable method, such as one of methods described above for the first embodiment. That is, the process may be substantially as described above for authentication 6. It will he appreciated that, in preferred embodiments, the specific authentication method by which authentication is carried out to permit the browser 1 00 to access the requested resource will be determined by or at the authentication entity 11 0. Any authentication method can be used. Possible methods for authenticating the user will be known and understood by the skilled person, so no further discussion of the specifics of how the authentication is performed will be given.

Following the authentication, the authentication entity 11 0 then sends 27 to the browser 1 00 a response message comprising first information, e.g. a code, which the browser 100 is later to present to the server 200 to indicate that the user of the browser 100 has been authenticated.

The first information, or code, is an indication that the user of the browser 100 has been authenticated, the first information can comprise any information. In some embodiments, the first information comprises an indication of the identity of the user. 11w first information need not comprise a known existing identity of the user, but preferably the first infoimation is unique to the user. In addition to the first information, any additional mcta-data relating to the authentication process may (optionally) be supplied, such as any saved session ID. In this enthodinient, the message has the same structure as the message sent at 7 in the first embodiment, ElI though the header "Set-Cookie" could be omitted in some embodiments, as also discussed above.

After the browser 100 receives the response message from the authentication entity 110, the browser generates and sends 28 a further request message to the server 200, which further request message comprises an indication that the user of the browser 100 has been authenticated, which in this example is the first information, or code, received from the authentication entity 110. In this embodiment, the message has the same structure as the message sent at 8 in the first embodiment Steps 29 to 35 of the second embodiment are the same as steps 9 to 15 of the first embodiment, and so further explanation thereof will not be given. Steps0 to 32 could be omitted in the same manner that steps 10 to 12 of the first embodiment are optional. Also, in is place of steps 23 to 25, the server 200 could open a connection to the authentication entity arid issue a request thereto on behalf of the browser 100. However, such an arrangement has limitations, as discussed above in relation to corresponding optional steps 3 to 5.

As discussed above for the first embodiment, the first information and the second information are respective first and second indicators of whether the user of the client 1 00 is authenticated. The first information is an indicator of a first predetermined format, and the second information is an indicator of a second predetermined format. The first and second predetermined formats are preferably different, such that the server 200 may determine whether a received request comprises the first indicator or the second indicator The first infonnation and the second information used in the second embodiment of the invention are independent of the IP address, or other identity, of the client 100 or the workstation 102 at which the client 100 is running. The first information and the second information are also independent of the source IP address included in the request messages generated and sent by the client 100 and received by the server 200, Rather, the first information is indicative of the user of the client 100, and is preferably unique to the user, and is generated away from the client and workstation 100, 102, e.g. at the authentication entity 110, and assigned to the user of the client 100 by an entity outside of the user's local network. Accordingly, since authentication of the user is carried out using information representative of the user, irrespective of the hardware and software they use to send requests for acccss to resources, (lie present invention is able to control on a user-by-user basis what resources users are permitted to access. Moreover, embodiments of the invention operate successfully when a proxy or a NAT device is located between the user's client 100 and a specially configured clement or entity located outside of the fu'st network I, such as the server 200.

It will also be appreciated that there is no requirement in the method and system of the present invention to deploy at the user's organisation, i.e. in the first network 1, a software application or a hardware device for detecting whether users are authenticated and/or for controlling user's access to resources, Rather, the present invention utilises a specially configured element or entity located outside of the first network 1, e.g. in the service provider's network 2. As such, the present invention can be considered to provide a "cloud-based" authentication and access control system and method, which is deployed outside of the user's organisation.

The client 100 running on the workstation 102 in the first network 1 operates according to the standard I1TTP protocol in the above examples, Similarly, in other embodiments that do not operate according to the Jill? protocol, the client 100 running on the workstation 102 in the first network 1 operates according to the employed message protocol, without requiring specific adaptation or supplementation of hardware or sofiware in the user's organisation to operate the method of the present invention. Since implementation of the present invention needs only the deployment or adaptation of an entity outside of the user's organisation, the present invention can be implemented cost-efficiently, without inconveniencing the user's organisation, and without requiring management at the client end.

Still further, even when a user intends to use a workstation that is not part of their organisation's domain, or when a user intends to use a workstation that is unable to run a login script to log in to the first network 1, embodiments of the present invention are able to prompt the user for credentials for any workstation that is not domain-integrated, while still allowing for other domain-integrated workstations to authenticate transparently.

Other modifications and embodiments of the present invention will he apparent to those skilled in the art. For example, in the first embodiment, the resource that the user desired to access is a particular wcbpagc. 1-Jowever, in other embodiments, the rcsourcc may bc of a different form, such as an image, a file such as a music or video file, or any other content or information.

In other embodiments, the network element 200 is not locatcd in a service provider network 2, For example, the network elcincnt 200 may be located in a further network (such as thc third network 3, or Internet) accessed by the client 100 via a service provider network 2. In some embodiments, the service provider network 2 is omitted and the server 200 is located at any other point outside of the first network 1.

Also, while discussion has been made herein of the workstation 102 being located in a first network I of an organisation, the present invention is also applicable to scenarios in which the workstation 102 is not part of a network 1, but in any ease is able to connect to the server over a wired or wireless connection.

The first information may be deteimined (i.e. selected, or generated) on the basis of the identity of the user and/or on the basis of an identity of the workstation 102 or the first network I and/or on the basis of an indication, such as a source lP address, of the source of the new request message or other information within the new request message received at the anthentication entity 110, 210. Accordingly, the first infomution may provide an indication of the position of the user in a hierarchy of pennission levels. For example, for some users the first information could indicate that the user has a first level of permission and is not permitted to access resources of a first class, such as adult content, or resources of a second class, such as streaming media, while for other users the first information could indicate that the user has a second level of permission and is not peimitted to access resources of the first class hut is permitted to access resources of the second class. Accordingly, when the server later receives the first information in the new request message 8, 28, the server 200 may detenninc wheQer or not the user of the workstation 102 is permitted to access the requested resource on the basis of a consideration of the class of the resource and a consideration of permission level assigned to the user, as indicated by the first information, The scope of the invention is not limited by the above-described embodiments.