US20210297492A1 - Maintaining a session across multiple web applications - Google Patents
Maintaining a session across multiple web applications Download PDFInfo
- Publication number
- US20210297492A1 US20210297492A1 US17/342,716 US202117342716A US2021297492A1 US 20210297492 A1 US20210297492 A1 US 20210297492A1 US 202117342716 A US202117342716 A US 202117342716A US 2021297492 A1 US2021297492 A1 US 2021297492A1
- Authority
- US
- United States
- Prior art keywords
- application
- web application
- session
- web
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/141—Setup of application sessions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
- H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
- H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
Definitions
- Cookies provide a mechanism for a browser to store such information as a user navigates from one page to another within a particular site.
- session cookies enable the browser to confirm that a session is still active and that the user has been successfully authenticated.
- Cookies are generally specific to particular web domains. For example, a cookie deposited by the domain “uspto.gov” could be used for activity within that domain but would not be useable for activity within the domain “patentfetcher.com.”
- multiple web applications form a suite of related applications. If the related applications are hosted from different domains, the applications may include hidden web elements that render web content from one or more other applications.
- Application A in Domain A may serve a webpage that includes an HTML (Hyper Text Markup Language) iframe element (inline frame).
- HTML Hyper Text Markup Language
- the iframe which appears within a webpage downloaded from Application A, renders content downloaded from Application B, which is hosted in Domain B.
- the iframe's content allows the browser to access a cookie from Domain B (e.g., using JavaScript or some other client-side script) and thus to access session information relating to the browser's session with Application B.
- a downloaded webpage from Application A can use Domain B's session cookie by virtue of the iframe element, thus avoiding any need to authenticate the same user to Application A.
- the user can seamlessly move from one web application in the suite to another without having to reauthenticate, even though the web applications are hosted from different domains.
- cookies can sometimes disable cookies or manage them in different ways, which may lead to a loss of functionality in systems that rely on cookies. Also, using cookies to store user session information can sometimes expose the session information to eavesdroppers, who may use the session information to gain access to protected resources.
- certain embodiments are directed to a method of maintaining user sessions across multiple web applications.
- the method includes receiving, by a first web application running on a first server, a cross-application request from a client application running on a client device.
- the cross-application request indicates a user action to access a second web application, which runs on a second server.
- the method further includes sending, by the first web application in response to receiving the cross-application request, a single-use password to the client application, which may send the single-use password to the second web application.
- the method further includes receiving, by the first web application, a session request from the second web application.
- the session request includes the single-use password as received by the second web application from the client application.
- the method still further includes sending, by the first web application, session data to the second web application.
- the session data (i) pertains to a session previously established between the client application and the first web application and (ii) enables the second web application to participate in the session with the client application.
- inventions are directed to a computerized apparatus constructed and arranged to perform a method of maintaining user sessions across multiple web applications, such as the method described above.
- Still other embodiments are directed to a computer program product.
- the computer program product stores instructions which, when executed by control circuitry, cause the control circuitry to perform a method of maintaining user sessions across multiple web applications, such as the method described above.
- FIG. 1 is a block diagram showing an example environment in which example embodiments of the invention can be performed.
- FIG. 2 is a simplified screenshot showing a web page that includes a user control for initiating a cross-application request in the environment of FIG. 1 .
- FIG. 3 is a block diagram of an example server of FIG. 1 .
- FIG. 4 is a sequence diagram showing an example sequence of events among certain elements of FIG. 1 for maintaining a session across multiple web applications.
- FIG. 5 is a flowchart showing an example method of maintaining a session across multiple web applications.
- An improved technique for maintaining a session across multiple web applications includes generating a single-use password by a first web application engaged in a session with a client application, passing the single-use password to the client application, and providing session data in response to a session request from a second web application, the second web application having received the single-use password from the client application. After validating the single-use password, the technique further includes the first web application providing the session data to the second web application, thus enabling the second web application to participate in the session previously established between the first web application and the client application.
- the need for cookies to maintain session information across web applications is avoided, as are the security risks and functional obstacles that the use of cookies entails.
- FIG. 1 shows an example environment 100 in which embodiments of the improved technique hereof can be practiced.
- a client device 110 runs a client application 112 , which is operable by a user 114 .
- the client application 112 is configured to access, over a network 120 , a first web application 132 on a first server 130 and a second web application 142 on a second server 140 .
- the client device 110 may be any computing device capable of running the client application 112 and communicating over the network 120 .
- Suitable examples of the client device 110 include a desktop computer, laptop computer, workstation, smart phone, smart tablet, personal data assistant (PDA), set top box, or game console, for example.
- the servers 130 and 140 may be implemented using any computing machines capable of running the web applications 132 and 142 . In a particular example, the servers 130 and 140 are implemented using server-grade computers and/or virtual machines running on such server-grade computers.
- the network 120 is preferably the Internet, but may also be a local area network (LAN), wide area network (WAN), a cellular data network, or any network or combination of networks.
- LAN local area network
- WAN wide area network
- cellular data network or any network or combination of networks.
- the user 114 operates the client application 112 on the device 110 .
- the client application 112 participates in a session 150 with the first web application 132 .
- the client application 112 is a web browser that renders web pages downloaded from the first web application 132 .
- the client application 112 may be any web-enabled application or app, which interacts with web application 132 and exchanges data therewith.
- the first server 130 stores session data 168 pertaining to the session 150 .
- Such session data 168 may include, for example, a user ID (identifier) of the user 114 , privileges of the user 114 to perform various activities, a token for accessing restricted information, and a session timeout interval.
- the server 130 binds together such session data 168 in a session data object, which is maintained as an addressable element in volatile or non-volatile storage within the server 130 .
- the user 114 operates a control, e.g., a link rendered on a downloaded webpage from the first user application 132 , to issue a cross-application request 160 , e.g., in an attempt to access the second web application 142 on the second server 140 .
- the first web application 132 receives the cross-application request 160 and provides, in response thereto, a single-use password (SUP) 162 .
- SUP 162 has a short expiration time, e.g., measured in seconds, after which the SUP 162 becomes invalid and cannot be used.
- the client application 112 receives the SUP 162 and forwards the SUP 162 in an access request 164 to the second web application 142 .
- the second web application 142 After receiving the SUP 162 in the access request 164 , the second web application 142 forms a session request 166 , which the second web application 142 sends to the first web application 132 with the SUP 162 .
- the first web application 132 receives the session request 166 , tests the SUP 162 against the value it sent to the client application 112 , and, assuming that the SUP 162 checks out as valid and that any other security requirements are met, replies to the session request 166 with a response that includes the session data 168 .
- the second web application 142 then uses the session data 168 to engage with the client application 112 in a session 150 a , which is a continuation of the session 150 .
- the web application 142 uses the session data 168 as its current session data with the client application 112 , such that there is no need to reauthenticate the user 114 or to establish a new session. Rather, the second web application 114 uses the results of the prior authentication, e.g., performed when the user 114 logged on to the first web application 132 .
- the second web application 142 may perform additional authentication tasks, but there would be no need to repeat the ones already performed by the first web application 132 .
- session information is maintained even as the user's activities shift from interactions with the first web application 132 to interactions with the second web application 142 .
- the session 150 between the client application 112 and the first server application 132 continues even after the session 150 a begins, such that the first server application 132 can still respond to requests from the client application 112 without having to start a new session or to reauthenticate.
- the session 150 terminates upon commencement of the session 150 a ; however, restoration of the session 150 can proceed using the same approach as described above, only with the roles of the first and second web applications reversed.
- the same session 150 / 150 a may be extended to a third web application (not shown), or to any number of additional web applications, e.g., in response to the user 114 initiating cross-application requests to access those web applications from pages rendered by the client application 112 .
- session activity by any web application participating in the session with the client application 112 can reset the session timeout, such that the session may continue indefinitely as long as the user 114 remains active.
- FIG. 2 shows an example screenshot 200 of the client application 112 , which in this case is a web browser.
- the client device 110 displays the web browser in an application window 210 , which includes a content window 212 showing a webpage downloaded from the first web application 132 .
- the webpage includes controls 220 and 222 , which enable the user 114 to interact with the first web application 132 within the session 150 ( FIG. 1 ).
- the user 114 may operate a cursor 224 to select the control 222 (e.g., a hamburger icon).
- the browser displays a list 226 of other web applications that are available from the current page. These include, in the current example, the second web application 142 (“App 2 ”), a third web application (“App 3 ”), a fourth web application (“App 4 ”), and a “Platform” application, e.g., an application that unifies the other applications in a common framework.
- the user 114 may use the cursor 224 to select one of the listed items, with the effect of the selection being to initiate a cross-application request. For instance, and continuing with the example of FIG. 1 , the user 114 may select “App 2 ” to initiate the cross-application request 160 .
- the user's selection of “App 2 ” from the list 226 initiates a script (e.g., a JavaScript event procedure) to send the cross-application request 160 to the first web application 132 and to wait for a response that contains the SUP 162 .
- a script e.g., a JavaScript event procedure
- the script may continue operation by issuing the access request 164 , which provides the SUP 162 to the second web application 142 , i.e., to the web application that corresponds to the user's selection from the list 226 .
- Other activities proceed as described in connection with FIG. 1 above.
- FIG. 3 shows an example of the first server 130 in additional detail.
- the server 130 includes one or more network interfaces 310 , a set of processors 320 , and memory 330 .
- the set of processors 320 include one or more processing chips and/or assemblies.
- the memory 330 includes both volatile memory, such as RAM (Random Access Memory), and non-volatile memory, such as one or more ROMs (Read-Only Memories), disk drives, solid state drives, and the like.
- the set of processors 320 and the memory 330 together form control circuitry, which is constructed and arranged to carry out various server-based methods and functions as described herein.
- the memory 330 includes a variety of software constructs realized in the form of executable instructions. When the executable instructions are run by the set of processors 320 , the set of processors 320 are caused to carry out the operations of the software constructs. Although certain software constructs are specifically shown and described, it is understood that the memory 330 typically includes many other software constructs, which are not shown, such as an operating system, various applications, processes, and daemons.
- the memory 330 is seen to “include,” i.e., realize by execution of software instructions, a web server 332 , a data store 334 , and the above-described web application 132 .
- the web server 332 uses HTTP (HyperText Transfer Protocol) to receive requests from clients (e.g., browsers or web-enabled applications or apps) and to respond to client requests by serving web pages and/or other content.
- the web application 132 provides the web pages and/or other content and performs back-end processing to support required functionality.
- the data store 334 provides data storage services for use by the web application 132 .
- the data store 334 includes an in-memory data structure store, such as Redis (open source), which may transiently store session data, including session data 168 , e.g., until the sessions expire.
- the data store 334 may also include persistent storage structures, such as one or more relational databases, noSQL databases, and the like.
- the server 130 is shown as a single computing machine, it may alternatively be implemented using multiple machines that operate in a coordinated fashion. Further, portions of the server 130 may be implemented using one or more virtual machines.
- FIG. 4 shows an example sequence of activities for maintaining a session across multiple web applications.
- the illustrated activities involve the client application 112 , the first web application 132 , and the second web application 142 .
- the sequence as shown is based on the same example as that described in connection with FIG. 1 .
- the illustrated operations begin at 410 , where the client application 112 submits a login request to the first web application 132 .
- the client application 112 may have previously downloaded a login page from the web server 332 .
- the login request issued by the client machine 112 may provide a user ID (e.g., of the user 114 ), a password, biometric information, and/or any other information required to authenticate the user 114 .
- the first web application 132 receives the login request and proceeds to authenticate the user 114 . Assuming that authentication succeeds, meaning that the identity of the user 114 is verified, the first web application 132 creates session data 168 for session 150 (see also FIG. 1 ).
- the session data 168 may include, for example, the user ID, privileges of the user to perform various activities, a token for use in accessing restricted information and/or functionality, and a session timeout interval.
- the session timeout interval defines an interval of time that the session 150 remains open when the user 114 is inactive. Example session timeout intervals are 20 minutes, one hour, etc., and may be reset to starting values as long as the user 114 remains active.
- the first web application 132 may also create a session key (SK) 168 a , e.g., a random or pseudo-random number that uniquely identifies the session data 168 .
- SK session key
- the first web application 132 stores the session data 168 in the Redis data store (part of 334 ) at a location defined by the session key 168 a.
- the first web application 132 sends the session key 168 a back to the client application 112 , e.g., in response to the login request issued at 410 .
- the client application 112 stores the session key 168 a in the client device 110 , such as in local memory, in cache, in a transient cookie, or on disk.
- Activities 410 - 416 establish session 150 .
- session 150 may proceed over time, with the client application 112 performing various actions and the first web application 132 providing responses in the usual manner, within the context of the session 150 .
- the user 114 may operate a user control in an attempt to access data or functionality provided by a different web application, such as the second web application 142 .
- a different web application such as the second web application 142 .
- the user 114 operates the hamburger icon 222 ( FIG. 2 ) and selects “App 2 ” from the displayed list 226 .
- the client application 112 sends a cross-application request 160 to the first web application 132 .
- the cross-application request 160 includes the session key 168 a , i.e., the same session key that the client application 112 received and stored at 416 .
- the cross-application request 160 is directed to the first web application 132 , where the session 150 is currently active, rather than to the second web application 142 , where the desired data or functionality that the user selected is actually provided.
- the first web application 132 having received the cross-application request 160 , responds by generating or otherwise providing a single-use password (SUP) 162 .
- SUP 162 is a crypto-random code having a short lifetime, such as ninety seconds or less, after which it becomes invalid.
- the first web application 132 may then bind the SUP 162 to the session key 168 a for the session 150 .
- the first web application 132 may create a new data object that associates the SUP with the session key 168 a.
- the first web application 132 provides the SUP 162 in a response to the cross-application request 160 .
- the client application 112 receives the SUP 162 and proceeds to generate an access request 164 .
- the client application 112 sends the access request 164 to the second web application 142 .
- the client application 112 runs a script that detects the user's selection of “App 2 ” from the list 226 , sends the cross-application request 160 ( 420 ) and waits for receipt of the SUP 162 .
- the client application 112 (e.g., acting via the script) responds to receipt of the SUP 162 by sending the access request 164 to the second web application 142 ( 430 ).
- the access request 164 includes the SUP 162 and may also identify the first web application 132 as the current session participant.
- the second web application 142 retrieves a service secret 434 .
- the service secret 434 is a value previously assigned to the second web application 142 , e.g., by the above-described platform server before the events depicted here, and identifies the second web application 142 as a trusted part of the platform.
- the second web application 142 sends a session request 166 to the first web application 132 .
- the session request 166 includes the SUP 162 and the service secret 434 .
- the first web application 132 receives the session request 166 and proceeds to test the session request 166 for authenticity. For example, the first web application 132 checks whether the SUP as received in the session request 166 matches the SUP 162 that it created (at 422 ). The first web application 132 may also test whether the service secret 434 matches an expected value.
- the first web application 132 responds to the session request 166 by providing the session data 168 and the session key 168 a .
- the first web application 132 accesses the data object that binds the SUP to the session key 168 a (from 422 ), and accesses the session data 168 using the session key 168 a .
- the first web application 132 destroys or otherwise invalidates the SUP 162 once it sends the response to the session request at 440 , even if the SUP 162 has not yet expired, to ensure that the SUP 162 is used only once.
- the second web application 142 receives the session data 168 and session key 168 a from the first web application 132 and proceeds to use the session data 168 and session key 168 a for maintaining the session 150 a with the client application 112 .
- the second web application 142 has access to its own in-memory data store, such as Redis, and stores session data 168 in the data store under the session key 168 a , e.g., in the same manner as described at 422 above by the first web application 132 .
- the second web application 142 may issue a service response, which may include content that the user requested when initiating the cross-application request 160 .
- the content may include a web page served by the second web application 142 .
- the content served to the client application 112 is limited based on authorization information contained in the session data 168 .
- the second web application 142 may filter out data or functionality that the session data 168 indicates the user 114 is not authorized to access.
- the session 150 a proceeds between the client application 112 and the second web application 142 .
- the client application 112 issues requests to the second web application 142
- the second web application 142 provides responses to the client application 112 .
- the second web application 142 may reset the session timeout, if necessary.
- later-received cross-application requests from the client application 112 may initiate an analogous sequence of events as described at 420 , 422 , 430 , 432 , 436 , 438 , 440 , 442 , and 444 , for maintaining the session with some other web application or again with the first web application 132 .
- FIG. 5 shows an example method 500 that may be carried out in connection with the environment 100 .
- the method 500 is typically performed, for example, by the software constructs described in connection with FIG. 3 , which reside in the memory 330 of the first server 130 and are run by the set of processors 320 .
- the various acts of the method 500 may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in orders different from that illustrated, which may include performing some acts simultaneously.
- a first web application 132 running on a first server 130 , receives a cross-application request 160 from a client application 112 running on a client device 110 .
- the cross-application request 160 indicates a user action to access a second web application 142 , which runs on a second server 140 .
- the client application 112 is a web browser or web-enabled application or app, which sends the cross-application request 160 in response to the user 114 operating a control.
- the user 114 has already been authenticated by this point, and a session 150 has been established between the client application 112 and the first web application 132 .
- the first web application 132 sends a single-use password 162 to the client application 112 in response to receiving the cross-application request 160 .
- the first web application generates the SUP 162 in response to receiving the cross-application request 160 .
- the SUP 162 has a short lifetime, after which it becomes invalid.
- the first web application 132 receives a session request 166 from the second web application 142 .
- the session request 166 includes the single-use password 162 as received by the second web application 142 from the client application 112 .
- the client application 112 upon receiving the SUP 162 from the first web application 132 , sends an access request 164 to the second web application 142 .
- the access request 164 provides the SUP 162 and identifies the first web application 132 as the application engaged in the current session 150 .
- the second web application 142 receives the access request 164 and responds by providing the session request 166 .
- the first web application 132 sends session data 168 to the second web application 142 in response to receiving the session request 166 .
- the session data 168 ( i ) pertains to the session 150 previously established between the client application 112 and the first web application 132 and (ii) enables the second web application 142 to participate in the session 150 with the client application 112 , e.g., as the session 150 a.
- the technique employs a single-use password 162 for passing session data 168 from a first web application 132 to a second web application 142 .
- the technique maintains a session across multiple web applications without requiring cookies, which are not always enabled or managed the same way by different client software.
- the technique also enhances security by avoiding transmission of sensitive information in cookies over the Internet.
- some embodiments may employ a separate platform server that acts to coordinate operations between and among the various web applications and to unify such web applications under a common framework.
- the platform server may perform various functions in the environment 100 , such as maintaining user accounts, maintaining lists of trusted web applications that are part of the platform, and issuing service secrets 434 ( FIG. 4 ).
- web applications 132 and 142 may be part of a common framework, this is not required.
- embodiments may be constructed in which web applications are unrelated except for the fact that they support the functionality described.
- otherwise unrelated applications may run software that supports cross-application requests, generates signal-use passwords, create and send session requests 166 , and provides session data 168 in response to session requests 166 from other applications.
- any web application can employ the techniques described herein provided that they are provided with software features that support the described functionality.
- the improvement or portions thereof may be embodied as a computer program product including one or more non-transient, computer-readable storage media, such as a magnetic disk, magnetic tape, compact disk, DVD, optical disk, flash drive, solid state drive, SD (Secure Digital) chip or device, Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), and/or the like (shown by way of example as medium 560 in FIG. 5 ).
- a computer-readable storage media such as a magnetic disk, magnetic tape, compact disk, DVD, optical disk, flash drive, solid state drive, SD (Secure Digital) chip or device, Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), and/or the like (shown by way of example as medium 560 in FIG. 5 ).
- ASIC Application Specific Integrated Circuit
- FPGA Field Programmable Gate Array
- Any number of computer-readable media may be used.
- the media may be encoded with instructions which, when executed on one or more computers or other processors, perform the
- the words “comprising,” “including,” “containing,” and “having” are intended to set forth certain items, steps, elements, or aspects of something in an open-ended fashion.
- the word “set” means one or more of something. This is the case regardless of whether the phrase “set of” is followed by a singular or plural object and regardless of whether it is conjugated with a singular or plural verb.
- ordinal expressions such as “first,” “second,” “third,” and so on, may be used as adjectives herein, such ordinal expressions are used for identification purposes and, unless specifically indicated, are not intended to imply any ordering or sequence.
- a “second” event may take place before or after a “first event,” or even if no first event ever occurs.
- an identification herein of a particular element, feature, or act as being a “first” such element, feature, or act should not be construed as requiring that there must also be a “second” or other such element, feature or act. Rather, the “first” item may be the only one.
Abstract
Description
- Web applications commonly employ cookies for holding session information. The cookies provide a mechanism for a browser to store such information as a user navigates from one page to another within a particular site. For example, session cookies enable the browser to confirm that a session is still active and that the user has been successfully authenticated. Cookies are generally specific to particular web domains. For example, a cookie deposited by the domain “uspto.gov” could be used for activity within that domain but would not be useable for activity within the domain “patentfetcher.com.”
- Sometimes, multiple web applications form a suite of related applications. If the related applications are hosted from different domains, the applications may include hidden web elements that render web content from one or more other applications. For example, Application A in Domain A may serve a webpage that includes an HTML (Hyper Text Markup Language) iframe element (inline frame). The iframe, which appears within a webpage downloaded from Application A, renders content downloaded from Application B, which is hosted in Domain B. The iframe's content allows the browser to access a cookie from Domain B (e.g., using JavaScript or some other client-side script) and thus to access session information relating to the browser's session with Application B. Thus, for example, if a user has already authenticated to Application B and the browser has stored a session cookie from Domain B, a downloaded webpage from Application A can use Domain B's session cookie by virtue of the iframe element, thus avoiding any need to authenticate the same user to Application A. In this manner, the user can seamlessly move from one web application in the suite to another without having to reauthenticate, even though the web applications are hosted from different domains.
- Unfortunately, browsers can sometimes disable cookies or manage them in different ways, which may lead to a loss of functionality in systems that rely on cookies. Also, using cookies to store user session information can sometimes expose the session information to eavesdroppers, who may use the session information to gain access to protected resources.
- In contrast with prior schemes, certain embodiments are directed to a method of maintaining user sessions across multiple web applications. The method includes receiving, by a first web application running on a first server, a cross-application request from a client application running on a client device. The cross-application request indicates a user action to access a second web application, which runs on a second server. The method further includes sending, by the first web application in response to receiving the cross-application request, a single-use password to the client application, which may send the single-use password to the second web application. The method further includes receiving, by the first web application, a session request from the second web application. The session request includes the single-use password as received by the second web application from the client application. In response to receiving the session request, the method still further includes sending, by the first web application, session data to the second web application. The session data (i) pertains to a session previously established between the client application and the first web application and (ii) enables the second web application to participate in the session with the client application.
- Other embodiments are directed to a computerized apparatus constructed and arranged to perform a method of maintaining user sessions across multiple web applications, such as the method described above. Still other embodiments are directed to a computer program product. The computer program product stores instructions which, when executed by control circuitry, cause the control circuitry to perform a method of maintaining user sessions across multiple web applications, such as the method described above.
- The foregoing summary is presented for illustrative purposes to assist the reader in readily grasping example features presented herein; however, this summary is not intended to set forth required elements or to limit embodiments hereof in any way.
- The foregoing and other features and advantages will be apparent from the following description of particular embodiments of the invention, as illustrated in the accompanying drawings, in which like reference characters refer to the same or similar parts throughout the different views.
-
FIG. 1 is a block diagram showing an example environment in which example embodiments of the invention can be performed. -
FIG. 2 is a simplified screenshot showing a web page that includes a user control for initiating a cross-application request in the environment ofFIG. 1 . -
FIG. 3 is a block diagram of an example server ofFIG. 1 . -
FIG. 4 is a sequence diagram showing an example sequence of events among certain elements ofFIG. 1 for maintaining a session across multiple web applications. -
FIG. 5 is a flowchart showing an example method of maintaining a session across multiple web applications. - Embodiments of the invention will now be described. Such embodiments are provided by way of example to illustrate certain features and principles of the invention but that the invention hereof is not limited to the particular embodiments described.
- An improved technique for maintaining a session across multiple web applications includes generating a single-use password by a first web application engaged in a session with a client application, passing the single-use password to the client application, and providing session data in response to a session request from a second web application, the second web application having received the single-use password from the client application. After validating the single-use password, the technique further includes the first web application providing the session data to the second web application, thus enabling the second web application to participate in the session previously established between the first web application and the client application. Advantageously, the need for cookies to maintain session information across web applications is avoided, as are the security risks and functional obstacles that the use of cookies entails.
-
FIG. 1 shows anexample environment 100 in which embodiments of the improved technique hereof can be practiced. Here, aclient device 110 runs aclient application 112, which is operable by auser 114. Theclient application 112 is configured to access, over anetwork 120, afirst web application 132 on afirst server 130 and asecond web application 142 on asecond server 140. - The
client device 110 may be any computing device capable of running theclient application 112 and communicating over thenetwork 120. Suitable examples of theclient device 110 include a desktop computer, laptop computer, workstation, smart phone, smart tablet, personal data assistant (PDA), set top box, or game console, for example. Theservers web applications servers network 120 is preferably the Internet, but may also be a local area network (LAN), wide area network (WAN), a cellular data network, or any network or combination of networks. - In example operation, the
user 114 operates theclient application 112 on thedevice 110. Theclient application 112 participates in asession 150 with thefirst web application 132. For example, theclient application 112 is a web browser that renders web pages downloaded from thefirst web application 132. Alternatively, theclient application 112 may be any web-enabled application or app, which interacts withweb application 132 and exchanges data therewith. Thefirst server 130stores session data 168 pertaining to thesession 150.Such session data 168 may include, for example, a user ID (identifier) of theuser 114, privileges of theuser 114 to perform various activities, a token for accessing restricted information, and a session timeout interval. In an example, theserver 130 binds togethersuch session data 168 in a session data object, which is maintained as an addressable element in volatile or non-volatile storage within theserver 130. - At some point during the
session 150, theuser 114 operates a control, e.g., a link rendered on a downloaded webpage from thefirst user application 132, to issue across-application request 160, e.g., in an attempt to access thesecond web application 142 on thesecond server 140. Thefirst web application 132 receives thecross-application request 160 and provides, in response thereto, a single-use password (SUP) 162. Preferably, the SUP 162 has a short expiration time, e.g., measured in seconds, after which theSUP 162 becomes invalid and cannot be used. Theclient application 112 receives theSUP 162 and forwards theSUP 162 in anaccess request 164 to thesecond web application 142. After receiving theSUP 162 in theaccess request 164, thesecond web application 142 forms asession request 166, which thesecond web application 142 sends to thefirst web application 132 with theSUP 162. Thefirst web application 132 receives thesession request 166, tests theSUP 162 against the value it sent to theclient application 112, and, assuming that theSUP 162 checks out as valid and that any other security requirements are met, replies to thesession request 166 with a response that includes thesession data 168. Thesecond web application 142 then uses thesession data 168 to engage with theclient application 112 in asession 150 a, which is a continuation of thesession 150. Thus, theweb application 142 uses thesession data 168 as its current session data with theclient application 112, such that there is no need to reauthenticate theuser 114 or to establish a new session. Rather, thesecond web application 114 uses the results of the prior authentication, e.g., performed when theuser 114 logged on to thefirst web application 132. - In the event that the
second web application 142 requires stronger authentication than does thefirst web application 132, thesecond web application 142 may perform additional authentication tasks, but there would be no need to repeat the ones already performed by thefirst web application 132. - In the manner described, session information is maintained even as the user's activities shift from interactions with the
first web application 132 to interactions with thesecond web application 142. In some examples, thesession 150 between theclient application 112 and thefirst server application 132 continues even after thesession 150 a begins, such that thefirst server application 132 can still respond to requests from theclient application 112 without having to start a new session or to reauthenticate. In other examples, thesession 150 terminates upon commencement of thesession 150 a; however, restoration of thesession 150 can proceed using the same approach as described above, only with the roles of the first and second web applications reversed. - Also, the
same session 150/150 a may be extended to a third web application (not shown), or to any number of additional web applications, e.g., in response to theuser 114 initiating cross-application requests to access those web applications from pages rendered by theclient application 112. In an example, session activity by any web application participating in the session with theclient application 112 can reset the session timeout, such that the session may continue indefinitely as long as theuser 114 remains active. -
FIG. 2 shows anexample screenshot 200 of theclient application 112, which in this case is a web browser. As shown, theclient device 110 displays the web browser in anapplication window 210, which includes acontent window 212 showing a webpage downloaded from thefirst web application 132. The webpage includescontrols user 114 to interact with thefirst web application 132 within the session 150 (FIG. 1 ). - At some point during the
session 150, theuser 114 may operate acursor 224 to select the control 222 (e.g., a hamburger icon). Upon selecting thecontrol 222, the browser displays alist 226 of other web applications that are available from the current page. These include, in the current example, the second web application 142 (“App 2”), a third web application (“App 3”), a fourth web application (“App 4”), and a “Platform” application, e.g., an application that unifies the other applications in a common framework. Theuser 114 may use thecursor 224 to select one of the listed items, with the effect of the selection being to initiate a cross-application request. For instance, and continuing with the example ofFIG. 1 , theuser 114 may select “App 2” to initiate thecross-application request 160. - In an example, the user's selection of “
App 2” from thelist 226 initiates a script (e.g., a JavaScript event procedure) to send thecross-application request 160 to thefirst web application 132 and to wait for a response that contains theSUP 162. When the response is received, the script may continue operation by issuing theaccess request 164, which provides theSUP 162 to thesecond web application 142, i.e., to the web application that corresponds to the user's selection from thelist 226. Other activities proceed as described in connection withFIG. 1 above. -
FIG. 3 shows an example of thefirst server 130 in additional detail. One should appreciate that the illustrated example also applies to thesecond server 140. Here, theserver 130 includes one ormore network interfaces 310, a set ofprocessors 320, andmemory 330. The set ofprocessors 320 include one or more processing chips and/or assemblies. Thememory 330 includes both volatile memory, such as RAM (Random Access Memory), and non-volatile memory, such as one or more ROMs (Read-Only Memories), disk drives, solid state drives, and the like. The set ofprocessors 320 and thememory 330 together form control circuitry, which is constructed and arranged to carry out various server-based methods and functions as described herein. Also, thememory 330 includes a variety of software constructs realized in the form of executable instructions. When the executable instructions are run by the set ofprocessors 320, the set ofprocessors 320 are caused to carry out the operations of the software constructs. Although certain software constructs are specifically shown and described, it is understood that thememory 330 typically includes many other software constructs, which are not shown, such as an operating system, various applications, processes, and daemons. - The
memory 330 is seen to “include,” i.e., realize by execution of software instructions, aweb server 332, adata store 334, and the above-describedweb application 132. Theweb server 332 uses HTTP (HyperText Transfer Protocol) to receive requests from clients (e.g., browsers or web-enabled applications or apps) and to respond to client requests by serving web pages and/or other content. Theweb application 132 provides the web pages and/or other content and performs back-end processing to support required functionality. Thedata store 334 provides data storage services for use by theweb application 132. In some examples, thedata store 334 includes an in-memory data structure store, such as Redis (open source), which may transiently store session data, includingsession data 168, e.g., until the sessions expire. Thedata store 334 may also include persistent storage structures, such as one or more relational databases, noSQL databases, and the like. Although theserver 130 is shown as a single computing machine, it may alternatively be implemented using multiple machines that operate in a coordinated fashion. Further, portions of theserver 130 may be implemented using one or more virtual machines. -
FIG. 4 shows an example sequence of activities for maintaining a session across multiple web applications. The illustrated activities involve theclient application 112, thefirst web application 132, and thesecond web application 142. The sequence as shown is based on the same example as that described in connection withFIG. 1 . - The illustrated operations begin at 410, where the
client application 112 submits a login request to thefirst web application 132. For example, theclient application 112 may have previously downloaded a login page from theweb server 332. The login request issued by theclient machine 112 may provide a user ID (e.g., of the user 114), a password, biometric information, and/or any other information required to authenticate theuser 114. - At 412, the
first web application 132 receives the login request and proceeds to authenticate theuser 114. Assuming that authentication succeeds, meaning that the identity of theuser 114 is verified, thefirst web application 132 createssession data 168 for session 150 (see alsoFIG. 1 ). Thesession data 168 may include, for example, the user ID, privileges of the user to perform various activities, a token for use in accessing restricted information and/or functionality, and a session timeout interval. The session timeout interval defines an interval of time that thesession 150 remains open when theuser 114 is inactive. Example session timeout intervals are 20 minutes, one hour, etc., and may be reset to starting values as long as theuser 114 remains active. At this time, thefirst web application 132 may also create a session key (SK) 168 a, e.g., a random or pseudo-random number that uniquely identifies thesession data 168. In a particular example, thefirst web application 132 stores thesession data 168 in the Redis data store (part of 334) at a location defined by the session key 168 a. - At 414, the
first web application 132 sends the session key 168 a back to theclient application 112, e.g., in response to the login request issued at 410. At 416, theclient application 112 stores the session key 168 a in theclient device 110, such as in local memory, in cache, in a transient cookie, or on disk. - Activities 410-416 establish
session 150. As shown generally byoperations 418,session 150 may proceed over time, with theclient application 112 performing various actions and thefirst web application 132 providing responses in the usual manner, within the context of thesession 150. - At some point during the
session 150, theuser 114 may operate a user control in an attempt to access data or functionality provided by a different web application, such as thesecond web application 142. For example, theuser 114 operates the hamburger icon 222 (FIG. 2 ) and selects “App2” from the displayedlist 226. - At 420, in response to the user operation, the
client application 112 sends across-application request 160 to thefirst web application 132. In an example, thecross-application request 160 includes the session key 168 a, i.e., the same session key that theclient application 112 received and stored at 416. One should appreciate that thecross-application request 160 is directed to thefirst web application 132, where thesession 150 is currently active, rather than to thesecond web application 142, where the desired data or functionality that the user selected is actually provided. - At 422, the
first web application 132, having received thecross-application request 160, responds by generating or otherwise providing a single-use password (SUP) 162. In an example, theSUP 162 is a crypto-random code having a short lifetime, such as ninety seconds or less, after which it becomes invalid. Thefirst web application 132 may then bind theSUP 162 to the session key 168 a for thesession 150. For example, thefirst web application 132 may create a new data object that associates the SUP with the session key 168 a. - At 424, the
first web application 132 provides theSUP 162 in a response to thecross-application request 160. Theclient application 112 receives theSUP 162 and proceeds to generate anaccess request 164. - At 430, the
client application 112 sends theaccess request 164 to thesecond web application 142. For example, and as described in connection withFIG. 2 , theclient application 112 runs a script that detects the user's selection of “App2” from thelist 226, sends the cross-application request 160 (420) and waits for receipt of theSUP 162. The client application 112 (e.g., acting via the script) responds to receipt of theSUP 162 by sending theaccess request 164 to the second web application 142 (430). Theaccess request 164 includes theSUP 162 and may also identify thefirst web application 132 as the current session participant. - At 432, upon receiving the
access request 164, thesecond web application 142 retrieves aservice secret 434. Theservice secret 434 is a value previously assigned to thesecond web application 142, e.g., by the above-described platform server before the events depicted here, and identifies thesecond web application 142 as a trusted part of the platform. - At 436, the
second web application 142 sends asession request 166 to thefirst web application 132. Thesession request 166 includes theSUP 162 and theservice secret 434. - At 438, the
first web application 132 receives thesession request 166 and proceeds to test thesession request 166 for authenticity. For example, thefirst web application 132 checks whether the SUP as received in thesession request 166 matches theSUP 162 that it created (at 422). Thefirst web application 132 may also test whether the service secret 434 matches an expected value. - At 440, assuming the testing at 438 produces a valid result, the
first web application 132 responds to thesession request 166 by providing thesession data 168 and the session key 168 a. For example, thefirst web application 132 accesses the data object that binds the SUP to the session key 168 a (from 422), and accesses thesession data 168 using the session key 168 a. In an example, thefirst web application 132 destroys or otherwise invalidates theSUP 162 once it sends the response to the session request at 440, even if theSUP 162 has not yet expired, to ensure that theSUP 162 is used only once. - At 442, the
second web application 142 receives thesession data 168 and session key 168 a from thefirst web application 132 and proceeds to use thesession data 168 and session key 168 a for maintaining thesession 150 a with theclient application 112. For example, thesecond web application 142 has access to its own in-memory data store, such as Redis, andstores session data 168 in the data store under the session key 168 a, e.g., in the same manner as described at 422 above by thefirst web application 132. - At 444, the
second web application 142 may issue a service response, which may include content that the user requested when initiating thecross-application request 160. For example, the content may include a web page served by thesecond web application 142. In some examples, the content served to theclient application 112 is limited based on authorization information contained in thesession data 168. For example, thesecond web application 142 may filter out data or functionality that thesession data 168 indicates theuser 114 is not authorized to access. - At 450, the
session 150 a proceeds between theclient application 112 and thesecond web application 142. For example, theclient application 112 issues requests to thesecond web application 142, and thesecond web application 142 provides responses to theclient application 112. Thesecond web application 142 may reset the session timeout, if necessary. Also, later-received cross-application requests from theclient application 112 may initiate an analogous sequence of events as described at 420, 422, 430, 432, 436, 438, 440, 442, and 444, for maintaining the session with some other web application or again with thefirst web application 132. -
FIG. 5 shows anexample method 500 that may be carried out in connection with theenvironment 100. Themethod 500 is typically performed, for example, by the software constructs described in connection withFIG. 3 , which reside in thememory 330 of thefirst server 130 and are run by the set ofprocessors 320. The various acts of themethod 500 may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in orders different from that illustrated, which may include performing some acts simultaneously. - At 510, a
first web application 132, running on afirst server 130, receives across-application request 160 from aclient application 112 running on aclient device 110. Thecross-application request 160 indicates a user action to access asecond web application 142, which runs on asecond server 140. For example, theclient application 112 is a web browser or web-enabled application or app, which sends thecross-application request 160 in response to theuser 114 operating a control. In an example, theuser 114 has already been authenticated by this point, and asession 150 has been established between theclient application 112 and thefirst web application 132. - At 520, the
first web application 132 sends a single-use password 162 to theclient application 112 in response to receiving thecross-application request 160. For example, the first web application generates theSUP 162 in response to receiving thecross-application request 160. TheSUP 162 has a short lifetime, after which it becomes invalid. - At 530, the
first web application 132 receives asession request 166 from thesecond web application 142. Thesession request 166 includes the single-use password 162 as received by thesecond web application 142 from theclient application 112. For example, theclient application 112, upon receiving theSUP 162 from thefirst web application 132, sends anaccess request 164 to thesecond web application 142. Theaccess request 164 provides theSUP 162 and identifies thefirst web application 132 as the application engaged in thecurrent session 150. Thesecond web application 142 receives theaccess request 164 and responds by providing thesession request 166. - At 540, the
first web application 132 sendssession data 168 to thesecond web application 142 in response to receiving thesession request 166. The session data 168 (i) pertains to thesession 150 previously established between theclient application 112 and thefirst web application 132 and (ii) enables thesecond web application 142 to participate in thesession 150 with theclient application 112, e.g., as thesession 150 a. - An improved technique has been described for maintaining a session across multiple web applications. The technique employs a single-
use password 162 for passingsession data 168 from afirst web application 132 to asecond web application 142. The technique maintains a session across multiple web applications without requiring cookies, which are not always enabled or managed the same way by different client software. The technique also enhances security by avoiding transmission of sensitive information in cookies over the Internet. - Having described certain embodiments, numerous alternative embodiments or variations can be made. For example, some embodiments may employ a separate platform server that acts to coordinate operations between and among the various web applications and to unify such web applications under a common framework. The platform server may perform various functions in the
environment 100, such as maintaining user accounts, maintaining lists of trusted web applications that are part of the platform, and issuing service secrets 434 (FIG. 4 ). - Although
web applications session requests 166, and providessession data 168 in response tosession requests 166 from other applications. Thus, any web application can employ the techniques described herein provided that they are provided with software features that support the described functionality. - Further, although the techniques disclosed herein may be used in place of cookies for maintaining sessions across web applications, such techniques do not preclude the use of cookies for other purposes.
- Also, although techniques have been described for maintaining sessions across web applications hosted from different domains, such techniques may also be used for web applications within a single domain. The techniques described herein may thus be regarded as domain-agnostic, without any requirement that web applications be in different domains.
- Further, although features are shown and described with reference to particular embodiments hereof, such features may be included and hereby are included in any of the disclosed embodiments and their variants. Thus, it is understood that features disclosed in connection with any embodiment are included as variants of any other embodiment.
- Further still, the improvement or portions thereof may be embodied as a computer program product including one or more non-transient, computer-readable storage media, such as a magnetic disk, magnetic tape, compact disk, DVD, optical disk, flash drive, solid state drive, SD (Secure Digital) chip or device, Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), and/or the like (shown by way of example as medium 560 in
FIG. 5 ). Any number of computer-readable media may be used. The media may be encoded with instructions which, when executed on one or more computers or other processors, perform the process or processes described herein. Such media may be considered articles of manufacture or machines, and may be transportable from one machine to another. - As used throughout this document, the words “comprising,” “including,” “containing,” and “having” are intended to set forth certain items, steps, elements, or aspects of something in an open-ended fashion. Also, as used herein and unless a specific statement is made to the contrary, the word “set” means one or more of something. This is the case regardless of whether the phrase “set of” is followed by a singular or plural object and regardless of whether it is conjugated with a singular or plural verb. Further, although ordinal expressions, such as “first,” “second,” “third,” and so on, may be used as adjectives herein, such ordinal expressions are used for identification purposes and, unless specifically indicated, are not intended to imply any ordering or sequence. Thus, for example, a “second” event may take place before or after a “first event,” or even if no first event ever occurs. In addition, an identification herein of a particular element, feature, or act as being a “first” such element, feature, or act should not be construed as requiring that there must also be a “second” or other such element, feature or act. Rather, the “first” item may be the only one. Although certain embodiments are disclosed herein, it is understood that these are provided by way of example only and that the invention is not limited to these particular embodiments.
- Those skilled in the art will therefore understand that various changes in form and detail may be made to the embodiments disclosed herein without departing from the scope of the invention.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/342,716 US20210297492A1 (en) | 2017-03-29 | 2021-06-09 | Maintaining a session across multiple web applications |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/472,872 US11050832B2 (en) | 2017-03-29 | 2017-03-29 | Maintaining a session across multiple web applications |
US17/342,716 US20210297492A1 (en) | 2017-03-29 | 2021-06-09 | Maintaining a session across multiple web applications |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/472,872 Continuation US11050832B2 (en) | 2017-03-29 | 2017-03-29 | Maintaining a session across multiple web applications |
Publications (1)
Publication Number | Publication Date |
---|---|
US20210297492A1 true US20210297492A1 (en) | 2021-09-23 |
Family
ID=62092227
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/472,872 Active 2037-12-18 US11050832B2 (en) | 2017-03-29 | 2017-03-29 | Maintaining a session across multiple web applications |
US17/342,716 Abandoned US20210297492A1 (en) | 2017-03-29 | 2021-06-09 | Maintaining a session across multiple web applications |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/472,872 Active 2037-12-18 US11050832B2 (en) | 2017-03-29 | 2017-03-29 | Maintaining a session across multiple web applications |
Country Status (2)
Country | Link |
---|---|
US (2) | US11050832B2 (en) |
WO (1) | WO2018183322A1 (en) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10826998B2 (en) * | 2018-07-19 | 2020-11-03 | Adobe Inc. | Protocol to initiate session with partner site |
CN111107041B (en) * | 2018-10-26 | 2022-04-29 | 海尔智家股份有限公司 | Method and device for preventing intelligent household appliance from being maliciously controlled |
CN109617953B (en) * | 2018-11-28 | 2021-08-31 | 亚信科技(南京)有限公司 | Session processing method and system |
US11303649B2 (en) * | 2019-05-30 | 2022-04-12 | International Business Machines Corporation | Maintaining electronic communications session continuity during session inactivity |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030217159A1 (en) * | 2002-03-18 | 2003-11-20 | Merck & Co., Inc. | Apparatus and method for sharing session information |
US20130007194A1 (en) * | 2011-06-30 | 2013-01-03 | Doleh Yaser K | Transferring session data between network applications |
Family Cites Families (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7188181B1 (en) * | 1999-06-30 | 2007-03-06 | Sun Microsystems, Inc. | Universal session sharing |
US7987501B2 (en) | 2001-12-04 | 2011-07-26 | Jpmorgan Chase Bank, N.A. | System and method for single session sign-on |
KR20050067132A (en) | 2002-07-12 | 2005-06-30 | 죤슨 앤드 죤슨 게엠베하 | Dry products comprising an applicator and a wax phase |
US20050120223A1 (en) * | 2003-12-01 | 2005-06-02 | Gary Kiwimagi | Secure authenticated network connections |
CN101032142B (en) | 2003-12-29 | 2011-05-18 | 艾利森电话股份有限公司 | Means and methods for signal sign-on access to service network through access network |
GB0621684D0 (en) * | 2006-10-31 | 2006-12-06 | British Telecomm | Secure access |
US8966594B2 (en) | 2008-02-04 | 2015-02-24 | Red Hat, Inc. | Proxy authentication |
US8213423B1 (en) * | 2008-04-24 | 2012-07-03 | Sprint Communications Company L.P. | Unique session ID sharing |
US8763102B2 (en) | 2008-09-19 | 2014-06-24 | Hewlett-Packard Development Company, L.P. | Single sign on infrastructure |
US20140032733A1 (en) | 2011-10-11 | 2014-01-30 | Citrix Systems, Inc. | Policy-Based Application Management |
US8869240B2 (en) * | 2011-11-28 | 2014-10-21 | Xerox Corporation | Soft method for local secure connection to a device |
US8769651B2 (en) * | 2012-09-19 | 2014-07-01 | Secureauth Corporation | Mobile multifactor single-sign-on authentication |
US20140108558A1 (en) | 2012-10-12 | 2014-04-17 | Citrix Systems, Inc. | Application Management Framework for Secure Data Sharing in an Orchestration Framework for Connected Devices |
US9355223B2 (en) | 2013-03-29 | 2016-05-31 | Citrix Systems, Inc. | Providing a managed browser |
EP3169079B1 (en) * | 2014-07-11 | 2019-01-09 | HP Printing Korea Co., Ltd. | Cloud server, control device, output device, and method for pairing cloud system comprising same with device |
-
2017
- 2017-03-29 US US15/472,872 patent/US11050832B2/en active Active
-
2018
- 2018-03-27 WO PCT/US2018/024561 patent/WO2018183322A1/en active Application Filing
-
2021
- 2021-06-09 US US17/342,716 patent/US20210297492A1/en not_active Abandoned
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030217159A1 (en) * | 2002-03-18 | 2003-11-20 | Merck & Co., Inc. | Apparatus and method for sharing session information |
US20130007194A1 (en) * | 2011-06-30 | 2013-01-03 | Doleh Yaser K | Transferring session data between network applications |
Also Published As
Publication number | Publication date |
---|---|
WO2018183322A1 (en) | 2018-10-04 |
US20180288162A1 (en) | 2018-10-04 |
WO2018183322A9 (en) | 2018-11-22 |
US11050832B2 (en) | 2021-06-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20210297492A1 (en) | Maintaining a session across multiple web applications | |
KR102148590B1 (en) | Website login method and device | |
US10708053B2 (en) | Coordinating access authorization across multiple systems at different mutual trust levels | |
US9098689B2 (en) | Efficiently throttling user authentication | |
CN112136303B (en) | Secure delegation of refresh tokens for time-consuming operations | |
CN111783067B (en) | Automatic login method and device between multiple network stations | |
US8244907B2 (en) | Browser-based logoff from distributed and federated environments | |
CN107172054B (en) | Authority authentication method, device and system based on CAS | |
KR101929598B1 (en) | Sharing user id between operating system and application | |
US7356694B2 (en) | Security session authentication system and method | |
US10225260B2 (en) | Enhanced authentication security | |
US9654462B2 (en) | Late binding authentication | |
US20070226783A1 (en) | User-administered single sign-on with automatic password management for web server authentication | |
US9003540B1 (en) | Mitigating forgery for active content | |
EP3709592A1 (en) | Detecting web application vulnerabilities | |
US20210209200A1 (en) | Systems and methods for improved authentication | |
CN113746811A (en) | Login method, device, equipment and readable storage medium | |
CA2844888A1 (en) | System and method of extending a host website | |
US20160366172A1 (en) | Prevention of cross site request forgery attacks | |
CN107294920A (en) | It is a kind of reversely to trust login method and device | |
US20210092113A1 (en) | Dynamic Connection Across Systems in Real-Time | |
Rozga et al. | Building an Integrated Bot Experience | |
WO2011070442A2 (en) | Method and system for anonymous user identification in a website |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: CITRIX SYSTEMS, INC., FLORIDA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FIGUEROA, JAVIER ALEJANDRO;HAAGSMA, GERALD DUANE;SIGNING DATES FROM 20170328 TO 20170329;REEL/FRAME:057203/0574 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
AS | Assignment |
Owner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, DELAWARE Free format text: SECURITY INTEREST;ASSIGNOR:CITRIX SYSTEMS, INC.;REEL/FRAME:062079/0001 Effective date: 20220930 |
|
AS | Assignment |
Owner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT, DELAWARE Free format text: PATENT SECURITY AGREEMENT;ASSIGNORS:TIBCO SOFTWARE INC.;CITRIX SYSTEMS, INC.;REEL/FRAME:062113/0470 Effective date: 20220930 Owner name: GOLDMAN SACHS BANK USA, AS COLLATERAL AGENT, NEW YORK Free format text: SECOND LIEN PATENT SECURITY AGREEMENT;ASSIGNORS:TIBCO SOFTWARE INC.;CITRIX SYSTEMS, INC.;REEL/FRAME:062113/0001 Effective date: 20220930 Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH CAROLINA Free format text: PATENT SECURITY AGREEMENT;ASSIGNORS:TIBCO SOFTWARE INC.;CITRIX SYSTEMS, INC.;REEL/FRAME:062112/0262 Effective date: 20220930 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
AS | Assignment |
Owner name: CLOUD SOFTWARE GROUP, INC. (F/K/A TIBCO SOFTWARE INC.), FLORIDA Free format text: RELEASE AND REASSIGNMENT OF SECURITY INTEREST IN PATENT (REEL/FRAME 062113/0001);ASSIGNOR:GOLDMAN SACHS BANK USA, AS COLLATERAL AGENT;REEL/FRAME:063339/0525 Effective date: 20230410 Owner name: CITRIX SYSTEMS, INC., FLORIDA Free format text: RELEASE AND REASSIGNMENT OF SECURITY INTEREST IN PATENT (REEL/FRAME 062113/0001);ASSIGNOR:GOLDMAN SACHS BANK USA, AS COLLATERAL AGENT;REEL/FRAME:063339/0525 Effective date: 20230410 Owner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, AS NOTES COLLATERAL AGENT, DELAWARE Free format text: PATENT SECURITY AGREEMENT;ASSIGNORS:CLOUD SOFTWARE GROUP, INC. (F/K/A TIBCO SOFTWARE INC.);CITRIX SYSTEMS, INC.;REEL/FRAME:063340/0164 Effective date: 20230410 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |