`Kunzelman et al.
`
`US006041357A
`[11] Patent Number:
`[45] Date of Patent:
`
`6,041,357
`Mar. 21, 2000
`
`[54] COMMON SESSION TOKEN SYSTEM AND
`PROTOCOL
`
`[75] Inventors: Kevin Kunzelman, San Francisco;
`Sterling Hutto, Sausalito, both of Calif.
`
`[73] Assignee: Electric Classi?ed, Inc., San Francisco,
`Calif.
`
`[21] Appl. No.: 08/796,260
`[22]
`Filed:
`Feb. 6, 1997
`
`[51] Int. Cl.7 ............................. .. H04L 9/00; G06F 13/14
`[52] US. Cl. ............................ .. 709/228; 380/49; 380/25;
`395/187.01
`[58] Field of Search ............................. .. 395/186, 187.01,
`395/188.01, 200.48, 200.59, 200.33, 200.57;
`380/49, 25
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`6/1993 Gasser et al. ........................... .. 380/30
`5,224,163
`7/1996 Carlson et al. ..
`395/186
`5,542,046
`5,689,638 11/1997 Sadovsky ....... ..
`395/18801
`5,706,349
`1/1998 Aditham et a1.
`.. 380/257.01
`5,708,780
`1/1998 Levergood et al. .
`.. 395/200.59
`
`5,740,242
`5,774,670
`
`4/1998 Minor et al. . . . . . . . . .
`. . . . . . . .. 380/49
`6/1998 Montulli .......................... .. 395/200.57
`
`OTHER PUBLICATIONS
`
`Yoshida, H.; “The Age of Customized Web Site”, Web
`Developer (Winter 1996) Tech Spotlight, located at http://
`W3.COM/CGI—BIN/W3 CPM/PWS/W3 .
`.
`. JhbIdXBWi
`F92—XXfDgM—wZ8WXcC1mT666J, pp. 1—5.
`“IETF Hypertext Transfer Protocol (HTTP) Working
`Group” located at http://www.ecs.uci.edu/pub/ietf/http/, pp.
`1—5.
`
`A. Hutchinson, et al., “An Extension of the HTTP Authen
`tication Scheme to Support Server Groups”, located at
`http://www.ics.uci.edu/pub/ietf/ht
`ft—trommler—http—eXt—groups—00.tXt, pp. 1—10.
`PM. Hallam—Baker, et al., “Session Identi?cation URI”,
`located
`at
`http://www.es.net/pub/internet—drafts/
`draft—ietf—http—session—id—00.tXt, pp. 1—10.
`D.M. Kristol, et al., “Proposed HTTP State Management
`System”, located at http://www.research.att.com/~dmk/
`cookie—2.9.tXt, pp. 1—17.
`
`Primary Examiner—Pinchus M. Laufer
`Attorney, Agent, or Firm—Philip H. Albert; Townsend and
`Townsend Crew
`
`[57]
`
`ABSTRACT
`
`An improved session control method and apparatus includes
`a client which establishes a session with a ?rst server such
`that the ?rst server can identify the client. When the client
`wishes to migrate from the ?rst server to a second server, the
`client requests a session token from the ?rst server. The
`session token is a data element generated by the ?rst server
`which is unique over the client-server network being navi
`gated and identi?es the particular session with the ?rst
`server. The session token is preferably a dif?cult to forge
`data element, such as a data element digitally signed using
`the private key of the ?rst server. The session token is passed
`from the client to the second server to initiate migration to
`the second server. If session data is too bulky to be passed
`as part of the session token, the second server may use data
`from the session token to formulate a request to the ?rst
`server for additional data needed to handle the state of the
`session. To minimize the transmission of data, the second
`server might maintain a version of the bulk session data and
`only request an update to the version of the data indicated in
`the session token.
`
`13 Claims, 3 Drawing Sheets
`
`10
`"x
`
`Servenside
`Migration Program
`
`22
`
`Server-side
`Migration Program
`
`22
`
`Client-side
`Migration Program
`
`1
`
`EX 1016
`IPR of Pat. No. 6,892,304
`
`
`
`U.S. Patent
`
`Mar. 21,2000
`
`Sheet 1 of3
`
`6,041,357
`
`10
`"I
`
`Server-side
`Migration Program
`
`22
`
`Server-side
`Migration Program
`
`22
`
`‘E?
`Ill
`g5
`E
`iii]
`iilili?iii]
`
`16
`
`g 148
`El
`E5
`:1
`iiili ii
`nnnuiiun
`
`SERVER A
`
`\
`
`,
`
`SERVER B
`
`\\
`‘\
`
`\
`
`‘\
`
`\
`\
`\
`i
`
`+
`
`18C
`
`ll
`,’
`A205
`
`I
`
`I
`I
`I
`I
`
`+
`
`Client-side
`Migration Program
`
`CLIENT
`
`FIG. 1
`
`2
`
`
`
`U.S. Patent
`
`Mar. 21,2000
`
`Sheet 2 of3
`
`6,041,357
`
`CLIENT
`
`SERVER A
`
`SERVER B
`
`81
`I
`/ CLIENT-SERVER
`REQUEST
`4 INTERACTION ‘
`SERVICE
`‘
`I
`'
`I
`
`SERVICE
`REQUESTS
`
`'
`f
`I
`:
`l
`l
`
`l
`
`I
`l
`I
`I
`I
`I
`'
`I
`I
`I
`I
`I
`I
`
`I
`I
`I
`
`l
`
`I
`I
`
`P2
`MIGR
`URL‘
`
`I
`194
`;
`SESSION
`TOKEN
`
`I
`
`|
`
`>
`
`53
`/
`PROCESSES
`MIGRATION
`REQUEST AND
`RESPOND
`
`I
`l
`
`I
`
`l
`l
`I
`l
`l
`l
`l
`l
`I
`l
`l
`
`i I
`I
`I
`I
`
`S8
`,J
`
`RECEIVE
`
`l
`I
`l
`
`106
`H
`‘I1
`
`104-
`
`32
`H
`V
`CLIENT SELECTS
`A MIGRATION
`OPTION
`
`84
`/
`RECEIVE AND _
`PASS SESSION
`TOKEN TO B
`
`ERROR
`
`‘
`
`S12
`,1
`CONTINUE
`SESSION WITH A
`NEvv SERVER
`813
`v
`/
`REQUEST
`SERVICE
`
`‘
`
`85
`,
`
`PROCESS
`I
`' SESSION TOKEN
`
`OF-BAND DATA
`
`REQUEST
`FROMA
`
`§9
`
`PARSE
`RESPONSE
`
`v:
`ACCEP
`MIGRATION
`EQUEST'?
`Y
`S11
`,1
`PROCESS
`REQUEST&
`OPEN A SESSION
`814
`v
`/
`SERWCE
`REQUESTS
`
`‘
`'
`
`A
`
`REQUEST
`ANDREPLY
`I
`
`I
`I
`I
`I
`I
`I
`:
`I
`;
`I
`
`I
`
`I
`I
`I
`108
`IU _
`I
`'
`I
`I
`110
`\iI DENYMESSAGE N
`I
`I
`I
`112
`I
`m ACCEPT MESSAGE
`I
`I
`;
`;
`;
`I
`I
`I
`I
`I CLIENT-SERVERINTERACTION I
`I
`I
`
`I
`
`I
`
`FIG. 2
`
`I
`
`I
`
`3
`
`
`
`U.S. Patent
`
`Mar. 21,2000
`
`Sheet 3 of3
`
`6,041,357
`
`104 SESSION ID (300)
`
`SESSION INFORMATION (302)
`
`I
`SETg/ER :
`
`SESSION ‘D DIGITAL
`SEFFg/RIER SIGNATURE
`
`CREATE
`TIME
`
`EXP'RAT‘ON
`
`SE
`U R
`ID
`
`E MAIL
`—
`ADDR
`
`PHONE
`NUMBER
`
`POSTAL
`ADDR
`
`'
`
`NODE
`
`W
`PLAIN TEXT
`
`V
`CIPHER TEXT
`
`FIG. 3
`
`400
`/
`
`104
`/
`
`RDEECHIELSST
`
`SESSION TOKEN
`
`[106
`
`FIG. 4
`
`4
`
`
`
`1
`COMMON SESSION TOKEN SYSTEM AND
`PROTOCOL
`
`6,041,357
`
`2
`the ?rst server, the second server Will interrupt the naviga
`tion process to require authoriZation information from the
`client. The usefulness of hypertext documents is greatly
`diminished if a user must enter a neW login name and
`passWord each time a link is taken.
`Session control for a single document is knoWn. A URL
`for a document available in a sessionless environment might
`be a character string of the form:
`http://server.host.domain/directory/subdir/?le
`With “http:/ ” indicating the protocol, “server.host.domain”
`uniquely identifying the server, and “directory/subdir/?le”
`identifying the document to be served. Where the document
`is not to be accessible to other than an authoriZed client, the
`URL might be of a form similar to the sessionless URL:
`http://server.host.domain/dir...?le?userfred+passWord
`In the session-speci?c URL, the user’s name and pass
`Word are included in the URL. While this is useful for
`making a reference to a single document for a speci?c user,
`it is not useful for passing sensitive session information
`because, the user name and passWord being in plaintext, it is
`too easily tampered With.
`Thus, What is needed is a method and apparatus for
`maintaining a seamless and secure migration of a session
`betWeen a client and a ?rst server to a session betWeen the
`client and a second server, Where the ?rst and second servers
`are independently controlled.
`
`SUMMARY OF THE INVENTION
`An improved session control method and apparatus is
`provided by virtue of the present invention. In one embodi
`ment of the present invention, a client establishes a session
`With a ?rst server such that the ?rst server can identify the
`client. When the client Wishes to migrate from the ?rst server
`to a second server, the client requests a session token from
`the ?rst server. The session token is a data element generated
`by the ?rst server Which is unique over the client-server
`netWork being navigated and identi?es the particular session
`With the ?rst server. The session token is preferably a
`dif?cult to forge data element, such as a data element
`digitally signed using the private key of the ?rst server and
`possibly encrypted. The session token might also be
`encrypted, using public key encryption or other methods, to
`prevent the session token from being easily readable.
`The session token is passed from the client to the second
`server to initiate migration to the second server. In some
`embodiments, session data is too bulky to be passed as part
`of the session token. In such cases, the second server uses
`the session token to formulate a request to the ?rst server for
`the data needed to handle the state of the session and the ?rst
`server provides the data to the second server. To minimiZe
`the transmission of data, the second server might maintain a
`version of the bulk session data and only request an update
`to the version of the data indicated in the session token.
`In the preferred embodiment, the token is passed in a URL
`(Uniform Resource Locator). HoWever, it also might be
`passed as an HTTP “cookie”.
`A further understanding of the nature and advantages of
`the inventions herein may be realiZed by reference to the
`remaining portions of the speci?cation and the attached
`draWings.
`
`BACKGROUND OF THE INVENTION
`
`The present invention relates to the ?eld of client-server
`protocols. More speci?cally, one embodiment of the inven
`tion provides for seamless migration of a session from one
`independent cooperating server node to another.
`The global Internet has emerged as a model of a distrib
`uted netWork of netWorks. One application for Which the
`Internet is increasingly used is to interconnect hypertext
`transfer protocol (HTTP) servers to clients. The hypertext
`transfer protocol is used to serve documents containing
`hypertext references to client “browsers” on client systems
`connected to the Internet. The documents served by an
`HTTP server Will often have hypertext references embedded
`in the document Which refer to documents on the HTTP
`server or documents on a completely different server. With
`such an arrangement, millions of documents have been
`linked to form the World Wide Web, Which is an allusion to
`the fact that these hypertext links might look like a spider
`Web if a diagram of the documents and the links Were draWn.
`Hypertext, as such, Was used in other contexts, such as
`help documentation, but those uses generally connected to a
`central document repository or even a single ?le With
`references to locations internal to the ?le. What made the
`World Wide Web more interesting and complex is the fact
`that a link in a ?rst document stored on a ?rst server might
`refer to a document on a second server Where the author of
`the ?rst document and the system operator of the ?rst server
`had no editorial or system control over the second document
`or the second server.
`This independence of servers did not inhibit the naviga
`tion of a client from server to server, since the reference for
`the link to be folloWed Was fully contained in the document
`Where the reference Was made. These self-contained refer
`ences to information are referred to as “uniform resource
`locators” (URLs) because the reference Was all that Was
`needed to locate the “linked-to” document. Since the URL is
`a static data element, it is the same for every client, so the
`linked-to server could not identify Who the client Was.
`Several solutions to this shortcoming have been in common
`use.
`The most common solution is to eliminate the need to
`knoW Who the client is. If the identity of the client is not
`needed, an HTTP server Will serve documents to any client
`Which requests a page. Of course, this solution is only
`practical Where the author of the linked-to document does
`not Want to place any restrictions on Who may vieW the page.
`If the author of the linked-to page Wants to place restrictions,
`the client Will have to enter into a “session” With the server
`Where the client is ?rst authenticated prior to the server
`alloWing access to the server.
`One consequence of such an architecture is that, Without
`some session control, the clients and servers must operate in
`a “stateless” manner, i.e., not tracking client identity, or any
`other variables, from request to request. Session control,
`When used, is usually done by a server requesting a login
`name and a passWord from the client prior to serving
`documents. Where all the documents are stored on a single
`server or a centrally controlled cluster of servers, session
`control only need occur When the client ?rst visits the server.
`If a link from one document references a document on the
`same server, the session can be seamlessly continued from
`the perspective of the client. HoWever, if the link is to a
`document on a second server not commonly controlled With
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 is a block diagram of a client-server netWork With
`Which the present invention is used.
`FIG. 2 is a ?oWchart of a session migration process
`according to the present invention.
`
`65
`
`5
`
`
`
`3
`FIG. 3 is a schematic of a session token.
`FIG. 4 is a schematic of a request for out-of-band data.
`
`DESCRIPTION OF THE PREFERRED
`EMBODIMENTS
`
`FIG. 1 illustrates an overall structure of a client-server
`network 10 With Which the present invention is used. Net
`Work 10 is shoWn comprising a client 12, tWo servers 14A,
`14B, the Internet 16, server connections 18A, 18B to Inter
`net 16 and a client connection 18C to Internet 16. As should
`be apparent, more than tWo servers might be coupled by a
`netWork to one or more clients, and the netWork need not be
`the global Internet, but can be any other netWork of coop
`erating independent servers. One alternative platform for the
`present invention is an intranet rather than Internet, Where
`the intranet is an internal netWork Within an organiZation
`using Internet protocols to communicate internal data.
`Depending on the siZe of the organiZation, the intranet might
`comprise several cooperating, but independent servers.
`In operation, server 14A interacts With client 12 via
`Internet 16 by sending and receiving data packets directed
`at, and received from, client 12. Client 12 also sends packets
`to and receives packets from server 14A via Internet 16.
`Thus, at a netWork level higher than the transport level, there
`exists a logical channel 20A connecting client 12 to server
`14A. The equivalent can be said about server 14B, Which
`connects to client 12 via a logical channel 20B.
`Server 14A and 14B are cooperative servers in that they
`both understand that client 12 might migrate from one server
`to another and facilitate that process. Unlike a centraliZed
`access control system, hoWever, servers 14A and 14B are
`separately controlled.
`An example of session migration Will noW be described
`With reference to a migration of client from a server A to a
`server B, Which might be client 12, server 14A (source
`server node) and server 14B (target server node). The
`session migration process begins When client 12 takes an
`action Which is to result in a session migration. The session
`migration moves the client’s interaction from channel 20A
`to channel 20B in a Way that is transparent to the client’s
`user, but that also maintains any necessary state, including
`state variables Which indicate a level of authoriZation for the
`client’s use of the session.
`One instance Where migration is useful is Where an
`operator of a Web server Wants to out source the operation
`of a particular aspect of their Web site. For example, a
`neWspaper might operate a site Which provides neWs, fea
`tures and classi?eds, but Will out source the management of
`the classi?eds to another operator, such as Electric
`Classi?eds, Inc., of San Francisco, Calif. (the assignee of the
`present application). A migration occurs When a user selects
`a classi?eds “button” or selection on a Web page operated by
`the neWspaper. The URL associated With the button can
`either be a direct reference to the target server or a reference
`Which causes redirection. In the former case, the page
`containing the button is presented to the user With the
`underlying HTML anchor including a session token for use
`in migration. This is possible Where the source server can
`anticipate that a migration may occur. In the latter case, the
`server need not anticipate the migration and the anchor for
`the button Will be a URL directed at the source server. The
`source server responds to the URL With a redirection URL.
`The redirection URL Would be the equivalent to the embed
`ded URL With a session token in the former case.
`A session migration using a redirection URL is illustrated
`in the ?oWchart of FIG. 2. FIG. 2 shoWs a number of steps
`
`10
`
`15
`
`35
`
`45
`
`55
`
`65
`
`6,041,357
`
`4
`identi?ed as S1, S2, S3, etc. Which are performed in ascend
`ing numerical order unless otherWise indicated. Before the
`migration process begins, the client is in a session With
`server A (step S1). The client sends requests to server A and
`server A services those requests. HoW server A services
`those requests depends on What the request is and the current
`state of the session. For example, for some requests, server
`AWill only respond to the request if the state of the session
`With the client indicates that the client is logged in as an
`authoriZed user. The state might also include variables Which
`modify the interaction With the client, such as the client’s
`user’s demographics. If the demographics indicate the geo
`graphic location of the user or the users age, gender, etc., the
`server might modify advertisements presented to the client
`accordingly. If the demographics indicate that the user is a
`sophisticated user, the server might send less help text in
`exchange for quicker transmission times. When such state
`variables are used, it should be apparent from this descrip
`tion that the server to Which the client is migrating needs to
`have the same state variables so as to present a consistent
`style across the migration. State variables might also indi
`cate What actions the client has already done, to alloW for
`activity tracking and caching. Activity tracking is useful for
`Web broWser clients, so that the navigation of the client can
`be tracked. Caching is useful for many types of clients and
`might be used to avoid sending data the server knoWs the
`client already has.
`In step S2, the client makes a selection Which server A
`determines Will be migrated. In the case of embedded
`migration (not shoWn), server AWould have anticipated the
`possible migration and included the migration information
`in an HTML anchor on the page. Server Aoptionally veri?es
`if the client is permitted to migrate and then serverAreturns
`(step S3) a session token 104 to the client as part of a URL.
`By including the session token as part of the URL, a standard
`broWser (i.e., one Which is not aWare of migration
`capabilities) can be used. The structure of a session token is
`shoWn in Table 1 and illustrated in FIG. 3.
`
`TABLE 1. SESSION TOKEN ELEMENTS
`
`. Server Node Identi?er
`. Unique Session Identi?er for the Server Node
`. Time of session creation
`. Expiration (Time-to-live) of session
`User ID
`E-mail address
`. Telephone number
`. Postal address
`. Digital Signature
`The server node identi?er can be almost any type of
`identi?er, including numerical values or ASCII strings. The
`server node identi?er might be an identi?er speci?c to
`cooperating servers or could be a unique code already in use
`by the server such as its four-byte IP address or six-byte IP6
`address. The only requirement is that no tWo cooperating
`server nodes share the same identi?er. The session is
`uniquely identi?ed by the ?rst tWo elements in the session
`token, since the second element is unique Within the source
`server node. By dividing the session identi?er into tWo
`pieces, We alloW for the decentraliZed generation of session
`identi?ers. Some of the session token elements, such as the
`e-mail address, telephone number and postal address, might
`be optional elements.
`As shoWn in FIG. 3, a session token such as session token
`104 is divided into a plaintext portion 300 containing the
`session ID and a ciphertext portion containing the encrypted
`session information 302 to alloW for more secure transport
`
`6
`
`
`
`6,041,357
`
`5
`of session token information. With public key encryption,
`the information can be made secure by digitally signing it,
`to prevent forgery, or by encrypting it, to prevent forgery and
`to prevent others from reading the session data. In Table 1,
`the encrypted session information is the third through eighth
`elements, Which are not required to uniquely identify the
`session. Therefore, these ?elds can be sent encrypted yet be
`decrypted at the target server node using an encryption
`method and key speci?c to the session. If the encryption
`method and key is the same for all session tokens from a
`particular source server node, the second element can also be
`encrypted. Encryption of the session speci?c information is
`preferred, so that unauthoriZed parties cannot vieW the
`information. In some embodiments, the information in the
`session token is not readable by the client even When the
`client is in possession of the session token. Of course, the
`user might be able to vieW his or her oWn session informa
`tion through the use of a dummy server. A dummy server
`accepts the user’s migration like any other server, but then
`does nothing more than display the session information.
`Table 1 shoWs but one example of a format for a session
`token. After reading this description, the person of ordinary
`skill Will understand that other formats are possible, so long
`as the format have certain properties. For example, session
`tokens must be unique so as to uniquely identify a session
`and must be such that they can be generated in a distributed
`environment, i.e., Without a centraliZed session token gen
`erator. They should be difficult for unauthoriZed parties to
`modify or forge. They must also be able to pass information
`about the session, or at least refer to information about the
`session, Which may then later be transferred out-of-band.
`While the system may operate Without digital signatures, the
`use of digitally signed session tokens is preferred. Adigitally
`signed session token is signed using the source server node’s
`private key so that the digital signature can be veri?ed using
`the source server node’s public key. Using a digital signature
`alloWs the authenticity of the token to veri?ed.
`Once the client receives the session token from server A,
`the client sends session token 104 to the target server node,
`server B (step S4). Server B processes session token 104
`(S5), performing the necessary veri?cation and decrypting
`of the session token. In some cases, the session token makes
`reference to “out-of-band” data, i.e., data Which is not
`contained Within the session token but Which is state infor
`mation needed for migration. Out-of-band data is used to
`keep session tokens from being too large, or for tighter
`access control. For example, the user’s postal address might
`be speci?ed as a pointer to a speci?c record of a database
`controlled by server A. Server B checks to determine if
`out-of-band data is needed (S6). If out-of-band data is
`needed, server B forms a request 106 for the data using
`session token 104 and sends request 106 to server A (S7).
`Session token 104 is part of the request so that server A can
`verify that server B is making an authoriZed request. FIG. 4
`shoWs the structure of request 106, Which is an envelope
`containing request details 400 and the session token 104. In
`some embodiments, not all the session information is passed
`to the source server node.
`When server A receives request 106, it supplies the
`out-of-band data to server B (S8) in a response 108. Server
`B parses and stores response 108 (S9) and proceeds to step
`S10. If out-of-band data is not needed, server B proceeds
`directly from step S6 to step S10. At step S10, server B
`decides Whether to accept the server migration request
`represented by session token 104. If server B decides not to
`honor the migration because the identi?ed client is not
`authoriZed to use server B, server B does not support that
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`6
`particular migration, or any other reasons, server B sends an
`error message 110 back to the client. OtherWise, server B
`processes the information in session token 104 and out-of
`band data 108, if used, and sends an acceptance message 112
`to the client (S11). Acceptance message 112 can either be a
`server to client message or a server to user message such as
`a Welcome message. In the former case, the transition might
`be a transparent transition. The client responds (S12) by
`transitioning to the neW session and requesting services from
`server B (S13) Which server B services using the migrated
`state information (S14).
`Versioning
`To minimiZe the retransmission of data that a target server
`node already has, the target server node may choose to cache
`out-of-band data obtained from a source server node. Of
`course, in a distributed netWork, cache consistency can be a
`problem. Cache inconsistencies might occur When session
`information changes and a client is not connected to the
`target server node caching the data. It is important for those
`changes to Work their Way around to other server nodes.
`A method for doing this is to encode a version identi?er
`Within the session token such that Whenever any out-of-band
`type session information changes, the source server node
`Will change the version identi?er. Then, Whenever a neW
`session token is generated by the source server node, the
`neW version identi?er Will be passed on to a target server
`node. If the version identi?er Within the token indicates that
`other information neWer than the data that the target server
`node previously has used, the target server should request
`neW out-of-band session information from the source server
`node.
`Different granularities of version numbers may be used
`for out-of-band session information. For example, a single
`version number may represent the state of all out-of-band
`data items, or multiple version numbers may represent
`certain subsets of the out-of-band data. The granularity does
`not affect the cache updating per se. Instead, the granularity
`of versioning merely determines hoW much data must be
`re-transferred in the case of the change of session informa
`tion.
`One application for the present invention is Within the
`World Wide Web, Where session tokens are encoded Within
`URLs. When a session is to be migrated from a source server
`node to a target server node, a neW URL Will be generated
`for a session token. A client application Will then make a
`request to the target server node using this URL. The target
`server node Will then decode this session token, verify its
`authenticity (using public key cryptography) and obtain any
`necessary out-of-band session information before continu
`ing With the request. Preferably, the session token is limited
`in siZe so that most broWsers and HTTP handlers can
`correctly process the session token as a URL. A limit many
`broWsers have for URLs is 1 kilobyte. If the session infor
`mation is greater than the limit, some of the session infor
`mation is sent as out-of-band data.
`In the preferred embodiment, the encoded session token
`Will be in a modi?ed Base-64, Which is a standard encoding
`for MIME email documents (Multipurpose Internet Mail
`Extensions). A Base-64 data stream is a stream of 6-bit
`numbers represented by an alphabet of 64 alphanumeric
`characters (usually the uppercase letters A—Z, the loWercase
`letters a—Z, the digits 0—9, and the characters ‘+’ and ‘/’. For
`our purposes, We use a modi?ed Base-64 Wherein ‘—’ and
`‘i’ are used in place of ‘+’ and ‘/’ so as to generate HTTP
`compliant URL’s.
`
`7
`
`
`
`6,041,357
`
`7
`Before it is encoded into modi?ed Base-64 for transmis
`sion using HTTP, the session token has the format shoWn in
`Table 2.
`
`TABLE 2
`
`Web Session Token Format
`
`Bytes
`
`Description
`
`Token Format ID
`Session Identi?er
`Length (N) of data to folloW
`Session Data
`CRC Checksum (32 bit)
`
`The Token Format ID should be Zero. This ?eld is
`reserved as a Way to specify neW token formats should there
`be a need to change them in the future. The session identi?er
`is a 64-bit ID comprising 16 bits (2 bytes) for a server node
`ID and 48 bits (6 bytes) for a unique session ID for the server
`node. This assumes a cooperating netWork of 2316 servers or
`feWer each assigned a unique server node ID. The N bytes
`of session data is encrypted With target server node’s public
`key and digitally signed With source server node’s private
`key. Encryption is done using a public key cryptosystem
`supplied by RSA Data Security, of Palo Alto, Calif., or
`similar cryptosystem.
`Before the session data is encrypted and signed, it has the
`folloWing format, Which is very similar to the RFC 822
`electronic mail header format:
`
`In this format, a key and its associated value are separated
`by a colon (and optional Whitespace) and key/value pairs are
`separated by neWline characters. An example of session data
`is as folloWs:
`Version-Date: Fri Dec 30 10:14:46 PST 1994
`User-ID: Fred
`Email-Address: fred@fred.org
`Telephone: @123.Fred.Telephone
`Postal-Address: @123.Fred.Address
`The “Telephone:” key value, “@123.Fred.Telephone”, is
`an indirect reference to session information Which indicates
`that Fred’s telephone number is actually held at server node
`123 and should be queried from that server node, using the
`data identi?er “Fred.Telephone”. To implement the out-of
`band transferal of session information, a simple transfer
`protocol for making queries over a secure out-of-band
`channel is used. The secure out-of-band channel (depending
`upon the circumstances) may be implemented as a private,
`dedicated physical link (such as a dedicated, private T1 line),
`or may be implemented as a secure link over a public
`netWork using an encrypted tunnel (such as With SSL,
`Secure Sockets Layer).
`A querying server node Wishing to obtain session infor
`mation from a source server node Would simply open a
`connection With the source server node, identify itself (the
`querying server node), get authenticated and then make a set
`of queries to obtain session data. The folloWing is an
`example of the process Where a querying server node
`(identi?ed as server node 456 in this example) connects to
`a source server node (identi?ed as server node 123) to
`request out-of-band data:
`
`10
`
`15
`
`35
`
`45
`
`55
`
`65
`
`Ser
`
`Output
`
`123
`
`456
`
`123 Connected to server 123, please identify and
`authenticate self
`Server:
`456
`Signature REOp5XtI5XtIpWx1tBY6maOWRXuyNZ
`Server 45 6 authenticated,
`please make your requests.
`456 Fred.Telephone, Fred.Address
`123 Fred.Telephone:
`(345) 555-1212
`Fred.Address:
`12345 Main Street
`AnytoWn, USA 98765-1234
`
`456 QUIT
`123 Goodbye, server 456.
`
`In addition to the above-described applications, other
`applications can be found for the present invention. One use
`of transparent session migration is a child ?lter. If a child is
`logged into a service, that child may see different informa
`tion than if an adult Were logged into the same service. As
`the child migrates from server to server, an indication that
`the user is a child Will be included in the session information
`so that the target server node can adjust its content accord
`ingly.
`The above detailed description explains hoW to make and
`use a session migration method and apparatus according to
`the present invention. The above description is illustrative
`and not restrictive. Many variations of the invention Will
`become apparent to those of skill in the art upon revieW of
`this disclosure. The scope of the invention should, therefore,
`be determined not With reference to the above description,
`but instead should be determined With reference to the
`appended claims along With their full scope of equivalents.
`What is claimed is:
`1. In a client-server netWork having multiple independent
`servers, a method of session migration from a session
`betWeen a client and a ?rst server to a session betWeen the
`client and a second server;
`establishing a current session betWeen the client and the
`?rst server after the ?rst server has veri?ed that th e
`client is an authoriZed client of the ?rst server;
`sending a migration request from the client to the ?rst
`server;
`in response to the migration request generating a session
`token;
`sending a session token from the ?rst server to the client,
`Wherein the session token uniquely identi?es the cur
`rent session betWeen the client and the ?rst server;
`sending the session token from the client to the second
`server as a request to the second server for migration;
`verifying, at the second server and from the session token,
`the identity of the client and the ?rst server;
`requesting, from the ?rst server, data about the session,
`Wherein the request is sent from the second server;
`responding from the ?rst server to t