Method and apparatus for providing efficient authorization services in a web cache

[0001] The invention relates to user authentication and access authorization across multiple Web sites. More specifically, the invention relates to a distribution of authorization services among Web servers in a way that permits efficient Single-Sign-On operations.

[0002] Many organizations make information available in electronic form on websites. Such electronic distribution permits users to obtain the information whenever they need it, from wherever they happen to be. Users commonly access the resources with a software program known as a Web browser, or simply “browser.” The browser acts as the client in a client-server interaction; the server's role is usually performed by a second software program known as a Web server. The browser and Web server communicate according to a protocol known as the Hypertext Transfer Protocol (“HTTP”), which is described in Internet Engineering Task Force (“IETF”) Request For Comments (“RFC”) number 1945. Subsequent RFCs describe extensions and modifications to the protocol.

[0003] HTTP is a “connectionless” protocol. That is, despite its use of the connection-oriented Transmission Control Protocol (“TCP”), there is no inherent mechanism to permit the server to determine whether two requests came from the same client. A client establishes a connection and transmits a request for a document or other resource, which it identifies with a string known as a “Uniform Resource Locator” or “URL.” The server responds by transmitting the requested data (or an error or other indicator) to the client; after this request-response sequence, the TCP connection is closed. (Certain extensions to HTTP permit several transactions to occur over a single TCP connection for improved efficiency, but each request is essentially independent, and the protocol permits each transaction to occur separately.)

[0004] RFCs 2109 and 2965 describe HTTP State Management Mechanisms where a server can issue a parcel of data known as a “cookie” to a client. When the client makes subsequent requests to that server, it sends the cookie with the request, and the server can use the data in the cookie to correlate the present request with earlier requests by the same client. A client will only send the cookie to the server that set it (or, in some circumstances, to a server in the same domain).

[0005] HTTP also provides mechanisms for protecting certain materials on a Web server against public access. These mechanisms permit the operator of a Web site to restrict access to certain documents or other information. To obtain copies of restricted materials, a browser must present credentials that are acceptable to the server. Often, the credentials are a username and password that were entered by the browser's user. Each request to the Web server (or for a subset of the information on the server) is accompanied by the credentials. Like RFC-2109 cookies, user credentials are only transmitted to one server (the server that originally requested the credentials).

[0006] The request-correlation and state management made possible by HTTP cookies and the user authentication capabilities of the protocol are rudimentary, but adequate for many purposes. However, some organizations maintain many servers for performance, redundancy, or other reasons. These servers often operate under different domain names. In one typical network topology, client requests are directed to a hub, or “caching,” server, and then forwarded to one or another “origin” servers where the requested data actually reside. In another common topology, requests from a number of clients (for example, all of the users at a university or corporation) are sent to a proxy server, which forwards the requests to the servers where the requested data reside. Both of these topologies can interfere with HTTP state management and authentication and cause undesirable effects such as repeated demands for credentials from a user whose identity has already been sufficiently proven to at least one of the servers. Methods of coordinating Web server operations to relieve these undesirable effects may be useful in many situations.

[0007] A Hypertext Transfer Protocol (“HTTP”) request is received from a client and examined to determine whether it has a valid, unexpired cookie. If the request has no cookie, an invalid cookie, or an expired cookie, an HTTP response to cause the client to request a login form is transmitted to the client.

[0013] Embodiments of the invention use cookies to carry information about a client's authorization to use resources from a group of servers. Data in the cookies help prevent unauthorized users from accessing the resources.

[0014] FIG. 1 shows a network map including a Web cache and Web servers implementing portions of an embodiment of the invention. Clients 110 and 120 connect to a first network 130, which may be the Internet or other similar distributed network. Web cache 140 is also connected to network 130, and can communicate with clients 110 and 120. Web cache 140 and servers 160 and 170 are connected to a second network 150, which may also be the Internet, a privately-administered intranet, or a combination of public and private data networks. Servers 160 and 170 may also have direct connections to first network 130, so that clients 110 and 120 can communicate directly with them. Server 180 may have only a connection to first network 130, but may still participate in an embodiment of the invention as detailed below.

[0015] Servers 160, 170, and 180 may contain canonical versions of data offered to users. For this reason, the servers may be called “origin” servers. The servers' domain names, as assigned for the purposes of this example, are shown near the icons: server 160 is named www1.origin-1.com; server 170 is www2.origin-1.com; and server 180 is www.origin-2.com. Servers 160 and 170 are in the same domain (“origin-1.com”), while server 180 is in a different domain (“origin-2.com”).

[0016] Web cache 140 may serve as the “front end” for servers 160 and 170, accepting requests from clients 110 and 120 and responding with cached data to reduce the load on servers 160 and 170, or forwarding the requests to one or the other of the servers based on a load balancing or redundancy policy. However, in addition to these caching, request-directing, and load-balancing functions, a Web cache according to an embodiment of the invention can provide authentication services as shown in FIG. 2.

[0017] A request by client 110 for a privileged resource from server 160 may proceed as follows: client 110 sends an HTTP request for the resource to server 160 (210). A software agent embodying the invention on server 160 receives the request and examines it to determine if the client sent no cookie, sent an invalid cookie, or sent an expired cookie (215). (The contents of the cookie, and the meanings of “invalid” and “expired,” are discussed below.)

[0018] If there is no cookie or an invalid or expired cookie, the software agent returns an HTTP “Redirect” response (220) to cause the client to request a login form over a network connection from Web cache 140, which implements another portion of an embodiment of the invention. The Redirect response may contain information about the originally-requested URL.

[0019] Client 110 transmits a second HTTP request to Web cache 140 (225), according to the “Redirect” response it received from server 160. In some embodiments, the second HTTP request may be transmitted over a secure network connection according to the Secure Sockets Layer (“SSL”) protocol, various versions of which are described in U.S. Pat. No. 5,657,390 issued to Elgamal et al. and IETF RFC 2246, among other references. A request over an SSL connection is indicated by the prefix “https” at the start of the requested URL. SSL transmission may be desirable to prevent interception of sensitive username and password information.

[0020] The second HTTP request is examined to determine whether the client has sent a cookie, and whether the cookie (if any) is invalid or expired (230). If there is no cookie, or the cookie is invalid or expired, the Web cache transmits the login form (235) specified by the first HTTP “Redirect” response (220) and requested by the client (225). The login form may contain text and Hypertext Markup Language (“HTML”) FORM fields to request client's username and password.

[0021] A user at client 110 may enter his username and password (or similar authentication information) and direct the client to transmit the login information to the Web cache (240). This transmission is the client's third HTTP request in this example sequence, and its second request to the Web cache. This request may also be sent over an SSL connection.

[0022] Web cache 140 will authenticate the login information (245), for example by comparing it to locally-stored information or by interacting with a separate authentication server (not shown). If the authentication is successful, Web cache 140 will return an HTTP “Redirect” response (250) to cause the client to repeat its first HTTP request (210) to obtain the originally-requested resource from server 160. However, the repeated request will vary from the original in this particular: the repeated request will include a valid cookie, provided by the Web cache, to indicate to server 160 that the user has been authenticated.

[0023] The Web cache's “Redirect” response will also set a cookie that the client will transmit to the Web cache if it has occasion to interact with the Web cache again in the future. This cookie may be different than the cookie provided to permit the client to obtain protected resources from server 160. These two types of cookies will be referred to as “master” and “agent” cookies as follows: a “master” cookie is one containing information for the Web cache, that the client will transmit to the Web cache when it requests resources located there. An “agent” cookie is one containing information for an origin server; the client will transmit the appropriate agent cookie to an origin server when it requests a resource located on the origin server.

[0024] To complete the interaction depicted in FIG. 2, client 110 transmits an HTTP request to server 160 (255), the request containing an appropriate agent cookie provided by the Web cache as part of “Redirect” response 250. Server 160 validates the agent cookie (260) and provides the requested resource (265). Subsequent HTTP requests from client 110 to server 160 for other resources will also contain the agent cookie, and may often be honored by server 160 immediately, without the intervening requests from the client to the Web cache (i.e. 225-250). Circumstances under which the agent cookie may not be accepted will be discussed below.

[0025] FIG. 3 shows a series of requests and responses between client 110, server 180, and Web cache 140. These interactions take place after the sequence described with reference to FIG. 2, so client 110 has a master cookie for Web cache 140 and an agent cookie for server 110.

[0026] First, the client requests a privileged resource from server 180 (310). Since the server's domain, www.origin-2.com, is different from the domains of both server 110 (www1.origin-1.com) and the Web cache (login.netcache.com), no cookie accompanies the request. Server 180 examines the request (315) and determines that it lacks a valid cookie, so it responds with an HTTP “Redirect” response (320) to cause the client to request a login page from Web cache 140. The response also contains the original URL that the client requested.

[0027] Client 110 requests the login page specified in the “Redirect” request from Web cache 140 by transmitting a second HTTP request (325). However, since the client previously received a master cookie from the Web cache (see FIG. 2, 250), request 325 is transmitted with the master cookie.

[0028] Web cache 140 receives request 325 from client 110, validates the master cookie received with the HTTP request (330), and transmits an HTTP “Redirect” response immediately, instead of transmitting the requested login page. The Web cache is able to omit the login page processing because the validated master cookie contains authentication and other information to permit the Web cache to determine that the client should be allowed to access the privileged resource it requested from server 180. Therefore, an embodiment of the invention may be able to prevent repetitive requests to the user to enter his username and password or other login information before being allowed to access privileged resources, even if the resources reside on origin servers in different domains. Request 325 and “Redirect” response 330 may occur over an SSL connection.

[0029] The HTTP “Redirect” response from the Web cache will cause client 110 to repeat its original request 310 to server 180, but the repeated request (340) will include an agent cookie generated by the Web cache to inform server 180 that client 110 has been authenticated and is to be allowed to access the requested resource. Finally, server 180 will validate the agent cookie(345) and return the requested data (350).

[0030] The client-server interactions described with reference to FIGS. 2 and 3 made frequent use of cookies. As mentioned earlier, cookies are parcels of data that a Web server can send to a browser, and that the browser will return to the Web server with subsequent requests. Cookie contents are opaque to the client; that is, the client need not do anything with the data except send it to the Web server. As mentioned earlier, and described in greater detail in RFCs 2109 and 2965, cookies are associated with the domain of the Web server, so a server in one domain cannot set a cookie to be sent to a server in a different domain. However, in the interactions described above, the Web cache provides agent cookies to the client for use with origin servers that may not be in the same domain as the Web cache. Since true cookies according to the RFCs (“HTTP cookies”) cannot be used in this way, embodiments of the invention employ an alternate method of sending cookie-like data parcels between client and server in cross-domain situations.

[0031] When a client requests a resource from a server, it identifies the resource with a Uniform Resource Locator, or URL. URLs to identify resources accessed over the HTTP (and HTTPS) protocols are structured as follows:

[0032] http[s]://host[:port][/path][?search-part]

[0033] where host is the name of the Web server, port is an integer, path is a string to identify the resource at the Web server, and search-part is an arbitrary string. Square brackets indicate optional elements; for example, “http[s]” indicates that the first portion of a URL can be either “http” or “https”. URLs are described in greater detail in RFC 1708.

[0034] Since the search-part portion of a URL permits an arbitrary string to be included in a URL, embodiments of the invention use search-part to transmit cookie-like data from a server in one domain to a server in another domain. A data parcel transmitted in this way is called a “URL cookie.”

[0035] Embodiments of the invention may use URL cookies at several points in the transactions described above. For example, when client 110 requests a protected resource from server 160 (2xx), the server responds with a Redirect message, but includes the originally-requested URL as a URL cookie. This information is transmitted to the Web cache 140 with the request for the login page (e.g. 225, 325), and permits the Web cache to redirect the client to the original URL after a successful authentication.

[0036] As another example, when client 110 requests a protected resource from server 180 (310) (after having authenticated itself to Web cache 140, obtaining a true RFC-compliant master cookie from the Web cache, and transmitting the master cookie to the Web cache upon the redirect from server 180 (325)), the Web cache's redirect (335) includes an agent cookie for server 180 as a URL cookie.

[0037] Embodiments of the invention may place a number of different pieces of information in an agent or master cookie, regardless of whether the cookie is transmitted as a true HTTP cookie, or as part of the requested URL (a URL cookie). Some embodiments may also encrypt the cookie data and/or sign the data using a public-key or other digital signature algorithm. Encrypting and/or signing cookie data can help prevent tampering and misuse of cookie data, and can permit a software component of an embodiment of the invention on one server to confirm the authenticity of cookie data ostensibly prepared by another component of an embodiment of the invention located on a separate but cooperating server.

[0038] A master cookie may contain some or all of these elements: a magic number, a source Internet Protocol (“IP”) address of the client to which the master cookie was issued, a timestamp, an expiration time, a generation number, and a username or other login information.

[0039] A magic number is a constant that may or may not encode information such as the absence or presence of other elements in the cookie. A magic number may be used to verify that a decryption or signature-verification operation completed successfully—if an encrypted cookie has been tampered with, then the decrypted cookie is very unlikely to contain a correct magic number.

[0040] A source IP address may be used to detect “replay” attacks, where an eavesdropper steals a copy of a legitimate user's master cookie and attempts to use it to access protected resources. If the eavesdropper's requests come from a different source IP address, the Web cache can detect the attack and refuse to provide an agent cookie that would permit the eavesdropper to access the protected resource.

[0041] A timestamp may be the time at which the cookie was created, while an expiration time may be a time at which the cookie is to expire. Either value may permit the Web cache to detect other “replay” attacks, where the eavesdropper obtains both a legitimate user's master cookie and access to the user's IP address. The timestamp or expiration time can place a temporal limit on the eavesdropper's ability to access protected resources with a stolen master cookie.

[0042] A generation number may be a monotonically increasing integer that provides yet more resistance to “replay” attacks: the Web cache may set a new master cookie with an incremented generation number each time the client uses the master cookie to obtain an agent cookie to access a protected resource on an origin server. If a client presents a master cookie with a generation number that is not equal to the expected generation number, the Web cache may suspect some sort of tampering or foul play and require that the user authenticate himself again.

[0043] A master cookie may contain the user's username, password, and/or other login information. This information is safe if the master cookie is encrypted with a secure algorithm. The username, password, or other information may be convenient or necessary for some interactions undertaken by the Web cache on behalf of the client.

[0044] A master cookie may also contain other information to permit the Web cache to provide additional services to the client.

[0045] Validating a master cookie may consist of some or all of the following operations: decrypting the cookie; validating a signature of the cookie; checking a magic number of the cookie; comparing a source IP address contained in the cookie with a source IP address of the client from which the cookie was received; ensuring that the time stamp indicates a time that is less than a predetermined length of time before the current time; and ensuring that the generation number is equal to the current (expected) generation.

[0046] Agent cookies are prepared by the Web cache and transmitted as URL cookies to a client that has successfully authenticated itself to the cache. An agent cookie may contain similar data to a master cookie, but may be encrypted so that only the origin server to which it applies is able to decrypt it. Agent cookies may also be signed by the Web cache with a public-key or other digital signature algorithm so that an origin server can verify that the agent cookie came from Web cache.

[0047] An agent cookie may contain an extra field that contains a generation number specific to the agent. Each time the agent receives an agent cookie, it verifies that the agent-specific generation number of the cookie is equal to the current (expected) generation number. If the generation number is verified, the agent sets a new agent cookie containing a new, incremented agent-specific generation number.

[0048] Validation of agent and master cookie generation numbers may accept generation numbers that are a up to a small, predetermined number of generations before the current expected generation number. Such “old” generations may be encountered when a client issues several requests simultaneously. For example, if a client attempted to obtain two image files to display in connection with an HTML document, the HTTP requests of those image files might include the same agent cookie (and therefore the same agent-specific generation number). The origin server might transmit the response to the first request, including an updated agent cookie with an incremented generation number, before processing the second request. When the origin server processes the second request, it will find that the agent cookie contains an earlier agent generation number. However, the validation may accept the generation if it is less than a configurable number of generations before the expected generation. Generation numbers greater than an expected generation are probably indicative of an illicit access attempt.

[0049] An agent cookie may have a timestamp or expiration time that specifies a different period of cookie validity than the lifetime of a master cookie. For example, while a master cookie might be valid for eight (8) hours, an agent cookie might only be valid for five (5) seconds. Thus, when a client requests a protected resource, it might obtain an agent cookie from the Web cache and use that cookie to request the protected resource and several associated resources (for example, a page of HTML text and images to be displayed on the page), where all the requests are made within a few seconds. If the client requested another protected resource after the agent cookie expired, it would again be redirected to the Web cache to obtain a new agent cookie. The short lifetime of an agent cookie provides frequent opportunities for the Web cache to interact with the client and to detect tampering and malicious access attempts, but does not require that the Web cache participate in every single client request, which might unacceptably degrade performance.

[0050] In the foregoing figures and discussion, portions of embodiments of the invention have been described as residing on physically separate computer servers. However, it should be apparent to those of ordinary skill in the relevant arts that Web server and Web cache functionality can coexist on a single server, or even within a single program. A server that can host all or a part of an embodiment of the invention might resemble the system shown in FIG. 4. There, processor 410 communicates with system memory 420 and peripheral devices such as network interface 430 and storage interface 440 (through which data residing on hard disk 450 can be accessed). The processor, memory, and devices communicate via system bus 460. Hard disk 450 may contain machine instructions 470 to cause the system to perform operations as described above. In addition to user authentication and host cookie and agent cookie generation and validation, the system might perform a proxy HTTP request, obtaining a resource requested by the client from an origin server and returning the resource to the client, but also caching the data locally so that further requests for the same data can be serviced without disturbing the origin server.

[0051] Other embodiments of the invention may take the form of executable instructions such as machine op-codes or interpretable byte-codes such as Java byte-codes, in a form suitable for loading into a Web server to supplement the Web server's functionality. Such loadable instructions may permit the augmented Web server to perform operations including receiving a HTTP request from a client; examining the request to determine whether it includes a cookie, and validating the cookie if one is present; transmitting an HTTP “Redirect” response if the request includes no cookie or an invalid cookie; and transmitting an HTTP response containing the requested resource if the request included a valid cookie. Responses containing the requested resource may also include HTTP header fields to cause the client to set an updated agent cookie.

[0052] An embodiment of the invention may be a machine-readable medium having stored thereon instructions which cause a processor to perform operations as described above. In other embodiments, the operations might be performed by specific hardware components that contain hardwired logic. Those operations might alternatively be performed by any combination of programmed computer components and custom hardware components.

[0053] A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), including but not limited to Compact Disc Read-Only Memory (CD-ROMs), Read-Only Memory (ROMs), Random Access Memory (RAM), Erasable Programmable Read-Only Memory (EPROM), and a transmission over the Internet.

[0054] The applications of the present invention have been described largely by reference to specific examples and in terms of particular allocations of functionality to certain hardware and/or software components. However, those of skill in the art will recognize that efficient user authorization in a Web cache can also be produced by software and hardware that distribute the functions of embodiments of this invention differently than herein described. Such variations and implementations are understood to be apprehended according to the following claims.