HK1144481A - System and method for extending sessions - Google Patents

Description

System and method for extending a session

Cross Reference to Related Applications

This application claims priority from U.S. patent application No.11/647,271 filed on 29.12.2006, which is incorporated herein by reference in its entirety.

Technical Field

The present invention relates to a method of minimizing the frequency of access to computer system resources, such as databases. More particularly, the invention relates to setting a fixed access period that is extendable under certain conditions.

Background

The security gateway system operates on a token system in which a token is issued to a user for authentication and access. In such systems, the information in the token needs to be updated with reference to the underlying database for each user transaction. This constant interaction with the database places a considerable burden on the system, which limits performance and real-time response.

Disclosure of Invention

Embodiments of the present invention are directed to allowing users to access computer system resources that rely on a security gateway in a manner that is substantially less interactive with a database than other methods. Such an embodiment is described in the context of a user-management system in which the user has a predetermined session duration (e.g., 8 hours, which may be a weekday default duration). During the session, the user may access a database or other computer system resource. In some circumstances, the user is allowed to continue to access computer system resources after an intended close of the session.

In a preferred embodiment, the security gateway authenticates the user and issues a token defining a default session period during which the user can access the database. The token also defines a time period, referred to herein as a "recycling window," that preferably occurs just prior to closing the default session. (the term "regeneration window" is used only as a label and does not define the characteristics of the window.) if a user accesses the database during the regeneration window, the security gateway extends the session by modifying the token. The conditions for allowing extension may be any of a variety of criteria. For example, if the default duration for a session is 8 hours, the security gateway may issue a token that defines the end time of the 8-hour session. The token may also define a regeneration window as the last 30 minutes of the default session. If the user actively accesses the database during the time period of the regeneration window, the gateway may modify the token to extend session 1 hours without additional access to the database. Reducing interactions with the database relieves the load on the database system and improves the response and throughput of the database.

The session may be extended recursively. For example, the first session extension may define a new session termination time (or other measure of session duration) and a new regeneration window within the extension period. If the user accesses the database during the regeneration window of the extended period, the session may be extended a second time. The second extension period may also contain another regeneration period, and the session may be further extended if the user accesses the computer system resource during the second regeneration window. The duration of the extension period and the regeneration period may be adjusted as needed for system operation. For example, it may be desirable to shorten the second and subsequent extension periods to prevent unlimited conversations or to limit employee work-over.

According to an embodiment of the present invention, a method of managing sessions is provided. The method includes opening a session, creating a token including a session opening time and a measure of the session duration, receiving the token within a first time prior to the measure of the session duration, adding a second time to the measure of the session duration in response to the receiving to define a new measure of the session duration, updating the token to reflect the new measure of the session duration as changed by the adding, and expiring the token after the new measure of the session duration.

The above embodiments may vary. For example, the receiving, adding, and updating may be recursive such that if a token is received within a first time before a new measure of session duration, the new session time is extended. The first time may be the same or different during or between any recursions of receiving, adding, and updating. The second time may be the same or different during or between any recursions of receiving, adding, and updating.

Transactions associated with tokens received prior to expiration may be processed. The session start time, session timeout (timeout) time, and first time in the token may be stored. The second time in the token may be stored. The second time may be less than or equal to half of a period of authorized use as defined by the session open time and/or the session duration metric. The first time may be less than or equal to half of the second time. Alternatively, the first time may be less than or equal to half of the second time.

According to another embodiment, a method of managing a session may comprise: the method includes requesting an opening of a session, receiving a token including a measurement of a session opening time and a session duration for a first time, transmitting a transaction request and the token within a first time prior to the measurement of the session duration, and receiving an updated measurement of the session duration associated with the token for a second time in response to the transmitting.

The above embodiments may have various features. For example, the sending and second receiving may be recursive such that if the token is sent within a first time before the updated measure of session duration, the updated session time is updated again. The first time may be the same or different during or between any recursions of the sending and second receiving. The second time may be the same or different during or between any recursions of the sending and second receiving.

Transactions associated with tokens transmitted during periods of authorized use defined by the session open time and/or the measure of session duration may be processed. The session start time, the session timeout time and the first time may be stored in the token. The second time may be stored in the token.

The second time may be less than or equal to half of the period of authorized use as defined by the session open time and/or the measure of session duration. The first time may be less than or equal to half of the second time. Alternatively, the first time may be less than or equal to half of the second time.

According to another embodiment, a method of managing a session may comprise: opening a session, creating a token that includes a timestamp of when the session was opened and a session timeout time, receiving the token within a window before the session timeout time expires, adding an additional time duration to the token in response to the above use, updating the token to reflect the additional time duration, and expiring the token after a new measure of the session duration. The period of time may satisfy the following equation:

where "sto" is the period of authorized use defined by the timestamp and/or session timeout time, "etd" is the extended time duration, and "rcw" is the window period.

The above embodiments may have various additional features. For example, in association with provisioning, updating, and expiring, the server may coordinate with the database. This coordination may be limited to provisioning, updating, and expiring.

Other exemplary embodiments and advantages of the present invention may become apparent by consideration of the present disclosure and accompanying drawings.

Drawings

The present invention is further described in the detailed description which follows, by way of non-limiting examples of certain embodiments of the present invention, with reference to the noted plurality of drawings, in which like reference numerals represent like elements throughout the several views of the drawings, and wherein:

FIG. 1 is a flow chart illustrating the timing steps of an embodiment of the present invention;

fig. 2 is an embodiment of the above method shown at the level of architecture and handshake;

FIG. 3 is a timeline of session and token usage for opening of a session, transactions within a period of authorized usage prior to a regeneration window, transactions within an authorization window, and session timeout extension;

FIG. 4 shows a non-limiting example of token content; and

fig. 5 illustrates an embodiment that provides a method for "adjusting" the amount of time evaluated as session timeout, regeneration window, and session extension.

Detailed Description

Specific details are set forth herein by way of example only and for purposes of illustrative discussion of the embodiments of the invention and are presented in order to provide the most useful and readily understood description of the principles and conceptual aspects of the invention. Therefore, no attempt is made to show structural details of the invention in more detail than is necessary for a fundamental understanding of the invention. The description taken with the drawings making apparent to those skilled in the art how the several forms of the invention may be embodied in practice.

The following embodiments are described in connection with a "security gateway" system. A security gateway is a client/server framework that provides security features to TOP products (and possibly more than TOP if needed). The security gateway is based on PC (physical device) identification. However, the invention is not so limited and the method may be applied to any user management, database management, or other computer system.

Referring now to fig. 1, in response to an authorized user receiving a request, a session is opened at S110 and an opening time (open time) is recorded in a database. At S112, a session timeout (session timeout) is defined, which preferably corresponds to the maximum duration of the session. The session timeout may be set to the elapsed time after the session is opened (e.g., 8 hours after the session is opened) or the absolute time (e.g., 5:00PM EST). The time between the session opening and the session timeout establishes a period of authorized use.

At step S114, a token is created with an appropriate reference (such as a timestamp) to identify the time of the session opening and session timeout. Any further system transactions will preferably rely on the token rather than the database. Without some form of extension, the token will expire after the session timeout.

In step S116, the system receives the transaction request and associated token. In step S118, the system determines whether the token is valid, e.g., whether the token indicates that the transaction is within a period of authorized use. If not, the system returns a message that the session has timed out and rejects the corresponding transaction in step S120.

If the token is valid at step S118, the system determines if the transaction is within a predetermined time (also referred to as a "regeneration window") before the session timeout. If not, the transaction is processed normally in step S126. If the transaction is within the recycle window, the system coordinates with the database such that the session timeout time is extended to include an extension of time to allow the session to remain open at step S122. At step S124, the new session timeout is stored in the token and the token is sent back to the requestor. Control then passes to step S126 for processing the transaction.

In the above embodiment, the database is accessed for only two reasons: (1) open a session and (2) receive a token within a regeneration window. The system does not need to coordinate the transactions with the database. This represents a substantial reduction in database interaction and a corresponding improvement in system performance.

Referring now to fig. 2, an embodiment of the above method is shown at the fabric and handshake level. The system is shown in simplified form as a user PC 210, a server 212 and a database 214. However, the architecture is not so limited, as the system may have many centralized or distributed terminals, servers, databases, or components that perform the disclosed functions.

The user requests to open a session by entering the appropriate credentials at PC 210. The PC 210 communicates this information 216 to the server 212. The server 212 logs in the new session in the database 214 and sends a token 218 back to the user's PC 210. Token 218 includes timestamps for session opening and session timeout. In the example of fig. 2, the session is opened at 9:01 AM and the session timeout is 2 hours, so that token 218 will expire at 11:01 AM.

During the open session, the user PC 210 initiates a transaction through the server 212. The transaction includes a token 218. Since token 218 is valid for the period of authorized use, server 212 will process the transaction as usual. While the token may be modified to reflect data related to the transaction, preferably the transaction does not affect the state of token 218. The example in FIG. 2 shows that this transaction occurs at 9:20 AM.

Later during the open session, the user PC 210 initiates a transaction through the server 212 within the regeneration window. Since the token 218 is valid for the period of authorized use, the server 212 will process the transaction as usual. However, the server 212 changes the token 218 to extend the session timeout (e.g., by adding a specific time period (+1 hour)) or to change the target end time of the session time (e.g., change 5:00PM to 6:00 PM). Such token changes may include updates to the original token, issuance of new tokens, and/or revocation of the original token. Such token changes should occur at the server. The server 212 coordinates with the database 214 as appropriate to update the new timeout for the token 218.

The extended amount of the period of authorized use is the amount of increase to the session timeout. The example of fig. 2 shows that the transaction occurred at 11:00AM (1 minute before the session timeout) and the session timeout was extended from 2 hours to 3 hours. The user may continue to process additional transactions for an extended session period.

In the above embodiment, the database is accessed for only two reasons: (1) opening a new session and (2) receiving the token within the regeneration window 218. Server 212 need not access database 214 and/or coordinate with database 214 for individual transactions. This represents a substantial reduction in database interaction and a corresponding improvement in system performance.

This method of session extension may be recursive. The system may provide another extension if a transaction is requested within the regeneration window associated with a new session timeout. The regeneration window, the extension period, and the environment supporting the extension may all be the same, respectively, such that the session may be extended indefinitely in theory. Alternatively, these parameters may be changed for subsequent transactions to make it more difficult to extend the session. By way of non-limiting example, the first regeneration window may be 15 minutes, the next 10 minutes, and then 5 minutes.

At some point the token will expire. The requested transaction will cause a "timeout" response after the session timeout and the transaction will be rejected. The example of fig. 2 shows that the timeout is 1:00AM one hour after the session timeout.

The token is stateless because it does not store a newly created token in the server memory or database file except for the user system. Conversely, when the token is used in a subsequent transaction, the token is algorithmically verified. The token can even be verified by a server that did not create the token itself. In such stateless transactions, all transactions are linked together by tokens, without the server having to keep track of the tokens created.

Referring now to fig. 3, a timeline of extended session and token usage for opening of a session, transactions within a period of authorized usage prior to a regeneration window, transactions within an authorization window, and session timeouts is shown.

Fig. 4 shows a non-limiting example of token content. The tokens are shown as tokens before regeneration 410 and tokens after regeneration 412.

Referring now to FIG. 5, another embodiment of the present invention provides a method for "adjusting" the amount of time evaluated for session timeout, regeneration window, and session extension. A long timeout value will reduce database access that occurs for regeneration only after a long first period. The small timeout value avoids long locking (locking) problems on the client side where sessions are not used but are statically causing more frequent regenerations. It is preferable to define a balance between long default timeout values and small timeout values by trading off technical and operational aspects (stability by reducing the number of database accesses) against client perspective (with as few constraints as possible by using the most flexible system).

The value of the regeneration window and the length of the extension will also define the amount of database access. A long recycling window will steadily extend more sessions than a small recycling window and will therefore trigger more database accesses. Extended session timeouts bring the same advantages and disadvantages as the default timeout values, e.g., small extra time durations avoid long-lock sessions, but statically cause more frequent recursive regenerations.

By way of non-limiting example, the acceptable compromise considered above is achieved according to the following formula:

wherein:

sto is the period of authorized use;

etd is the amount of time added to sto at the time of regeneration, an

Rcw is a regeneration window period.

If the embodiment utilizes a recursive approach, the above formula can only be applied once and the same value used for each successive session, or the values can be recalculated for each recursion.

It should be noted that the foregoing examples have been provided merely for the purpose of explanation and are in no way to be construed as limiting of the present invention. While the invention has been described with reference to certain embodiments, it is understood that the words which have been used herein are words of description and illustration, rather than words of limitation. Various changes may be made, within the purview of the claims, as presently stated and as amended, without departing from the scope and spirit of the present invention in its aspects. Although the invention has been described herein with reference to particular means, materials and embodiments, the invention is not intended to be limited to the particulars disclosed herein; rather, the invention extends to all functionally equivalent structures, methods and uses, such as are within the scope of the appended claims.

Claims (33)

1. A method of managing sessions, comprising:

opening a session;

creating a token comprising a measure of session opening time and session duration;

receiving the token within a first time prior to the measure of the session duration;

adding a second time to the measure of session duration in response to the use to define a new measure of session duration;

updating the token to reflect a new metric for the duration of the session as changed by the adding; and

expiring the token after a new measure of the session duration.

2. The method of claim 1, wherein

The first time period is a regeneration window occurring immediately prior to the measurement of the session duration; and

the measure of the session duration is a relative time period measured from the open time of the session or an absolute time measured against the same time reference as the open time.

3. The method of claim 1, wherein the receiving, adding, and updating are recursive such that if the token is received within the first time before a new measure of the session duration, the new session time is extended.

4. The method of claim 3, wherein the first time is the same during any recursions of the receiving, adding, and updating.

5. The method of claim 3, wherein the first time may be different between any recursions of the receiving, adding, and updating.

6. The method of claim 3, wherein the second time is the same during any recursions of the receiving, adding, and updating.

7. The method of claim 3, wherein the second time may be different between any recursions of the receiving, adding, and updating.

8. The method of claim 1, further comprising processing a transaction associated with a token received prior to the expiration.

9. The method of claim 1, further comprising storing in the token at least a start time of the session, a measure of the session duration, and the first time.

10. The method of claim 9, further comprising storing at least the second time in the token.

11. The method of claim 1, wherein the second time is less than or equal to half of a period of authorized use, as defined by a measure of the session open time and/or the session duration.

12. The method of claim 1, wherein the first time is less than or equal to half of the second time.

13. The method of claim 11, wherein the first time is less than or equal to half of the second time.

14. A method of managing sessions, comprising:

requesting to open a session;

a first receiving token, the token comprising a measure of a session opening time and a session duration;

sending a transaction request and the token a first time prior to the measure of the session duration; and

in response to the sending, second receiving an updated measure of the session duration associated with the token.

15. The method of claim 14, wherein the transmitting and second receiving are recursive such that if the token is transmitted within the first time before an updated measure of the session duration, the updated session time is updated again.

16. The method of claim 15, wherein the first time is the same during any recursions of the transmitting and second receiving.

17. The method of claim 15, wherein the first time may be different between any recursions of the transmitting and second receiving.

18. The method of claim 15, wherein the second time is the same during any recursion of the transmitting and second receiving.

19. The method of claim 15, wherein the second time may be different between any recursions of the transmitting and second receiving.

20. The method of claim 14, further comprising processing transactions associated with tokens sent during a period of authorized use defined by a session opening time and/or a measure of the session duration.

21. The method of claim 14, further comprising storing in the token at least a start time of the session, a timeout time of the session, and the first time.

22. The method of claim 21, further comprising storing at least the second time in the token.

23. The method of claim 14, wherein the second time is less than or equal to half of a period of authorized use as defined by a session open time and/or a measure of the session duration.

24. The method of claim 14, wherein the first time is less than or equal to half of the second time.

25. The method of claim 23, wherein the first time is less than or equal to half of the second time.

26. A method of managing sessions, comprising:

opening a session;

creating a token comprising a timestamp of when the session was opened and a session timeout time;

receiving the token within a window prior to expiration of the session timeout time;

adding an additional time duration to the token in response to the use;

updating the token to reflect the additional time duration; and

expiring the token after the new metric of the session duration.

27. The method of claim 26, wherein:

wherein:

sto is a period of authorized use defined by the timestamp and/or the session timeout time;

etd is the extended time duration; and

rcw are periods of the window.

28. The method of claim 26, wherein:

in association with the provisioning, the server coordinating with a database to store session data; and

in association with the update, the server coordinates with the database to store updated token data.

29. The method of claim 27, wherein the server does not coordinate with the database in response to a user-server interaction other than (a) the associating with the opening and (b) the associating with the updating.

30. The method of claim 27, wherein a server does not coordinate with a database for user-server transactions between the opening and the updating.

31. The method of claim 1, wherein:

in association with the provisioning, the server coordinating with a database to store session data; and

in association with the update, the server coordinates with the database to store updated token data.

32. The method of claim 29, wherein the server does not coordinate with the database in response to a user-server interaction other than (a) the associating with the opening and (b) the associating with the updating.

33. The method of claim 1, wherein a server does not coordinate with a database for user-server transactions between the opening and the updating.