JP6533871B2 - System and method for controlling sign-on to web applications - Google Patents

Description

CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of priority from US Provisional Patent Application No. 62 / 252,295, filed November 6, 2015. The entire disclosure of that application is incorporated herein by reference.

  Deployment of web applications allows a large number of users to access resources controlled by one or more web applications and / or web applications. For example, a large enterprise may deploy enterprise software applications ("web applications") on one or more servers within its corporate network or other Internet accessible computers, with all employees and / or clients via the web. Access to the application. The web accessibility of such applications provides employees and / or clients with the ability to access the application anytime, anywhere from where the client device has network connectivity.

  Also, web applications can be accessed using different types of information processing devices. The same user may access a web application using different information processing devices. For example, a user may attempt to access a web application using his smartphone while simultaneously accessing the web application via a desktop computer. The web application may be accessed by the same user using two different browsers (eg, Google's Chrome, Microsoft's Internet Explorer).

  Thus, deployment of web applications provides a number of benefits with respect to accessibility and availability. The ability of the same user to simultaneously access a web application using multiple devices, browsers and / or other client applications improves the nature of the user's interaction with the web application, such as efficiency and convenience. be able to.

  However, the increased convenience of web applications provided by the development of software and network technologies can lead to the misuse of access privileges if it is not properly controlled. For example, in the case of a web application in which the provider charges a license fee or access fee for each user, one user may avoid paying the entire fee by using the authority of another user to access the web application. Therefore, it is possible to potentially steal some income from the provider. Such misuse of access rights can also adversely affect system capacity available to users paying fees and / or can adversely impact system performance experienced by users .

Thus, techniques for improving the accessibility of such applications and improving the protection of application provider resources in situations where more enterprise software applications with increasing commercial value are being deployed as web applications. Is required.
Copyright notice

  A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright holder does not oppose copying by any person in this patent document or in the manner that it appears in the Patent and Trademark Office of this patent disclosure, but reserves all copyright in any case otherwise.

  The disclosed technology relates to controlling access to web applications and resources controlled by such applications. The disclosed technology provides single sign-on capability. There, a user who is already signed on to a web application from a client application will not be required to sign on again if he / she needs to access the web application from the same or another client application I will. The single sign-on capability can improve the user experience associated with web applications by reducing the number of times the user has to perform the sign-on process. The disclosed technology provides the server with multiple login prevention capabilities. Multiple login prevention can be used to detect potentially suspicious sign-on scenarios and deactivate one or more active sessions if suspicious sign-on is detected.

  This summary is provided to introduce a selection of simplified concepts that are further described below in the Detailed Description of the Invention. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter, but rather This summary is intended to provide an overview of the subject matter described in this document. Accordingly, the features described above are merely exemplary, and other features, aspects, and advantages of the subject matter described herein will become apparent from the detailed description, figures, and claims set forth below. Should be understood.

1 illustrates a computing environment having one or more client devices and one or more server devices executing a web application, according to an example embodiment.

FIG. 6 illustrates some of the data tables that may be maintained by one or more of the servers of FIG. 1 in accordance with an exemplary embodiment.

FIG. 6 shows a flow diagram illustrating interactions between a client device and a server device when single sign-on operation is performed according to an exemplary embodiment.

FIG. 6 shows a flow diagram illustrating the interaction between the client device and the server device when multiple logins prevention operation is performed according to an exemplary embodiment.

FIG. 5 (FIGS. 5A and 5B) shows a flow diagram illustrating interactions between a client device and a server device when a user signs in, according to an example embodiment. FIG. 5 (FIGS. 5A and 5B) shows a flow diagram illustrating interactions between a client device and a server device when a user signs in, according to an example embodiment.

FIG. 6 shows a flow diagram illustrating the interaction between the client device and the server device when single sign on operation is followed by multiple login protection according to an exemplary embodiment.

8 illustrates a process that a native application uses to sign on to a web application at launch time, according to an example embodiment.

Fig. 6 shows a flowchart of an exchange of data requests for a client according to an exemplary embodiment.

8 illustrates a sign-on window being presented superimposed over a native application on a client device according to an example embodiment.

1 schematically illustrates a computing environment in which client devices and / or servers may be implemented in accordance with an illustrative embodiment.

  The techniques described herein relate, inter alia, to controlling user access to one or more web applications. Certain exemplary embodiments provide single sign-on (SSO) capabilities, which, once performed in the login process, require less authentication for later access to other aspects of the same application or related applications. Provide the user with the convenience of being able to do so without the need to perform further sign on actions. Certain example embodiments may include multiple login prevention (MLP) capabilities, which help protect the revenue stream generated by the web application, and of the server running the web application. It can help to protect the processing capacity. Using MLP capabilities, for example, detects when the same identifier / credential (eg, user ID or credentials of a specific user) is used to access a web application from multiple endpoints simultaneously, It can operate to cancel one or more sessions to reduce misuse of access to the application. The SSO and / or MLP capabilities provided by an embodiment improve efficiency, access speed, and user convenience in any type of web application, but frequently and conveniently access multiple applications. It may be further beneficial in web applications with a single page application (SPA) framework that provides users with the ability to

  FIG. 1 illustrates a non-limiting computing environment 100 including one or more servers 102 (also referred to herein as a “server infrastructure”) and one or more clients 104, according to an embodiment. The one or more servers 102 communicate with the client 104 and one or more external servers so that the user of the client 104 can access the web application 112 running on the one or more servers 102. The server 102 may also be in communication with the document management system 108. Communication between server 102, client 104, external server 106, and document management system 108 may be via the Internet or any other communication network.

  The server 102 may be implemented on one or more physical server computers communicably connected to each other via a network. One or more physical server computers may be geographically co-located or distributed. The server 102 may include a database management system 110, one or more server-side web applications 112 (e.g., 112 a and 112 b), and a core service application 114.

  Each web application 112 may be designed and operated according to a three-tier model consisting of a web server, an application server and a database. As with conventional systems, the web server of each web application 112 communicates with external entities via HTTP and other protocols such as JSON, HTML, XML, JavaScript, Cascading Style Sheets (CSS), etc. Including ability. The application server of each web application 112 provides the processing logic of the application, and the database of each web application 112 provides data storage and data retrieval.

  Web application 112 interacts with core service application 114 to manage user authentication, interacts with clients 104 (eg, 104 a and 104 b) to receive input from client 104 and send to client 104, on client 104. It may interact with the database management system 110 and / or the external server 106 to obtain the information to be provided to the requesting client application being executed at. In some embodiments, some or all of the information provided to the requesting client may be generated by the web application itself and / or other web applications locally executed by the same one or more servers 102. .

  Core service application 114 may be designed and operated according to the three-tier model described above, and may provide one or more services commonly used by web application 112. Exemplary services that may be provided by the core service application 114 include user authentication, session management, and the like.

  In one embodiment, core service application 114 may also provide session management for external server 106. For example, in a use case where two or more web applications 112 obtain data from a particular external server 106, the core service application 114 can set up a session between the server 102 and the external server 106 between the client 104 and the server 102. May provide the ability to manage according to other corresponding sessions between Each external server may maintain a copy 119 of a portion of the session table maintained at server 102.

  The web application 112 receives the request from the client 104, processes the information from the database 110 and / or the external server 106 and / or obtains the information, as a result from the processing and / or the obtained data It operates to respond to the client 104. Web application 112 may use core services 114 to manage users and user sessions.

  A web application may comprise one or more client-side components and one or more server-side components. The client-side component of the web application may be operative to provide user interface handling by providing (eg, displaying) information on the user interface device, accepting user input, and the like. The server-side component may provide authentication, service measurement, generation or acquisition of information to be provided to the user according to the received user input.

  Embodiments are not limited to a particular type of web application. Web applications that can be used in embodiments may include single page application (SPA) models or any non-SPA models or those designed according to a combination thereof.

  SPA is a web application that operates within a single web page. In SPA, the content of a single web page is sent by the web server to the web browser, and the page is loaded / rendered, as described above for conventional web applications. Then, if the user wishes to view different content in the application, the user clicks on the hyperlink or enters on the page. However, instead of directing to different pages as in non-SPA web applications, the same page continues to be loaded and its content is dynamically updated. This dynamic update can be achieved in different ways. It may also include, for example, the web browser doing a background HTTP fetch of new content, updating the document object model (DOM) of the page (via JavaScript code), and / or other techniques. Good.

  Angular JS® is a web application framework used to generate SPAs. In a web browser, the Angular JS JavaScript library is loaded and interprets HTML templates embedded with Angular JS JavaScript and other Angular JS coding constructs. As a result, the resulting page operates as defined in the template. Also, other frameworks (eg, Backbone. Js, Ember. Js, and React) may be used for SPA applications.

  In some non-SPA web application models, the web application includes different web pages. The following set of interactions is made to render a particular web page within the application. The client device's web browser requests the web server (using hypertext transfer protocol (HTTP) messages) a specific web page, and in response, the web server (using HTTP) the page's code to the web browser And the code includes, for example, HTML, JavaScript, and Cascading Style Sheet (CSS) code, and the web browser then loads the code and renders the page, so that the user looks at the page Allow interaction. If the user later wishes to view different content in the application, the user clicks on a hyperlink specifying a different page in the application or provides an input to the page specifying it, and then on that different page The above-described request / response / load / draw procedure is performed.

  Database management system 110 (which may be referred to herein simply as a database) may be a commercially available DBMS or other data records management system. Although shown as a single DBMS, DMBS 110 may include one or more separate databases. Embodiments are not limited to the type of database management system.

  Clients 104a and 104b may be configured to run the same or different client applications. In the exemplary embodiment shown in FIG. 1, the first client 104a includes a web browser A116 and a web browser B117. The client 104a may also have a client-side application 120a, which is a native application, in its own right. When accessing the web application 112 using the browser A 116, the client-side code 118 of the web application 112 is executed within the browser A 116. In the same exemplary embodiment, second client 104b is configured to execute application 120b, which may be a native application. The client 104b may have a browser (for example, shown as a browser A or a browser C) in addition to the native application 120b. Client-side code 118 and application 120 may perform client-side processing for the corresponding web application on server 102.

  As shown in FIG. 1, when a client application (eg, 116/118 or 120a / 120b) communicates with the web application 112, the web application 112 obtains any information requested by the client from one or more external servers 106 And may be provided to client applications. In some embodiments, some or all of the information provided to the requesting client 104 may be generated locally by the server 102.

  Clients 104 may include personal computers, mobile computers, tablets, smartphones, and other electronic devices. In an exemplary embodiment, any electronic computing device, including at least a display and an input device for user input and a communication interface for communication with the server device, may operate as a client device.

  The external servers 106 (e.g., 106a, 106b, 106c) may include one or more servers controlled by an entity (e.g., a management entity) different from the entity that controls the one or more servers 102. For example, one or more of the external servers 106 may be managed by a service provider or vendor. The service provider or vendor provides the user of client device 104 with access and / or analysis of various application data under predetermined (e.g., previously agreed upon by the enterprise and vendor) service specifications. The service specification may be based on one or more of the number of users accessing the external server, the type and amount of information, the usage period, the usage frequency, and the like.

  It should be understood that the software modules shown in FIG. 1 are held and executed by hardware components (eg, processor and memory), and further, as software modules perform any operations herein. At any time when explaining, it is understood only to simplify the explanation, and in practice the operation is carried out by the underlying hardware in accordance with the instructions and data that make up the software module. It should be. Further details regarding exemplary hardware components that may be used to implement the features described herein are provided below with reference to FIG. 10, as well as elsewhere herein.

  In the exemplary implementation, computing environment 100 may be associated with an enterprise, such as Nasdaq Corporation. The example web application 112 may include a real time market analysis application and a client account status application. Users of web application 112 may include financial analysts and other employees of a business. The core service application 114 performs management (eg, user account generation, qualification management, etc.), authentication (eg, generation / management of a session for the user to access a predetermined service, etc.), user approval (eg, user predetermined It may provide common services such as checking whether the user is authorized to access a service or feature. The server 102 may represent one or more servers and associated infrastructure that the enterprise uses to execute the web application 112, the core service application 114 and associated software. The document management system 108 may include a customer relationship management application that communicates with web applications and / or core service applications to deliver services to users of the enterprise.

  In this exemplary implementation, each external server 106 may be operated by a corresponding application data vendor. Each vendor provides application data such as real-time financial market related information to an entity such as Nasdaq Corporation under certain service specifications (for example, agreed prices based on data type, usage amount, number of users, etc.) It is also good.

  When an analyst accesses the real-time market analysis application on the server 102 using the client 104a, the SPA is displayed on the client device and from the vendor (e.g., one that operates the external server 106) and / or the internal analyst of the company etc. A variety of real-time or value-added information may be displayed on one or more parts of the displayed SPA.

  An external server 106 (e.g., a vendor) can provide the requested information and identify the user accessing the service, as defined, for example, in the service description agreed between the enterprise and the vendor. It may depend on the enterprise (as a "vendor of record") to ensure that the user follows the terms of use. For example, based on the agreement with a particular vendor, using the core service application will qualify for accessing / obtaining that particular vendor / type of data from that particular vendor (of accessible data type / amount Designated and other restrictions (if any) can be assigned to the user and / or web application. Core service 114 may establish a session with the vendor for the corresponding user with valid credentials for the vendor's data. Core service 114 may provide or maintain a session table (eg, 116) at each vendor. If, for example, the user of client device 114 requests data from a vendor through one of the web applications on server 102, in one embodiment, the vendor checks the copy of its session table and the credentials of the requesting user May be requested to the core service 114, and the requested data may be provided if the qualification is valid.

  FIG. 2 illustrates an exemplary collection of data tables 200 that may be maintained by and / or accessible to core service application 114, according to an exemplary embodiment. Although referred to as a “table”, the data discussed in connection with FIG. 2 may be any form or data accessible to the core service application 114 and / or other applications configured to utilize the data. It may be held in structure.

  The user authentication information 202 may include a table of user authentication information. This table is accessed by the core service 114, for example, to authenticate the user during sign-on to one or more of the web applications. In user authentication information 202, specific information may be maintained for each user, such as any of a user ID, a password, a user specific cookie, and an entitlement associated with the user.

  User session information 204 includes a record of the currently active session when a user, such as a user of client device 104, communicates with a web application on server 102 through the currently active session. The user session information 204 may be in the form of a table in which each row represents an active session. In certain embodiments, inactive sessions (eg, recently deactivated / canceled sessions) may also be in the table. The user session information table 204 may include, for each session, fields / columns such as a user ID, a web application utilizing the session, a client, an authentication session identifier and / or one or more cookies. The table may also include the session start and end times and the current state. The state may indicate, for example, if the session is broken or is currently active, and if broken, the reason for the break (eg, a break due to MLP).

  The external server session information 206 holds the user session for the corresponding external server 106. In one embodiment, external server session information 206 may be maintained in a data structure for each external server 106. In one embodiment, each table 206 can be provided to a corresponding external server 106. In this case, when the request is given, the external server can locally check the permissions and / or entitlements associated with the request. In one embodiment, the session between server device 102 and external server 106 may be based on user session information 204, and a separate table may not be necessary.

  The credentials 208 include information regarding the credentials associated with access to the web application. As mentioned above, entitlements specify the scope of access to one or more external servers (or other resources) for a user or group of users. For example, credential information 208 may specify the type of external server (vendor) and data that each user or group of users has access to. The entitlement may also specify if simultaneous access by multiple client applications (eg simultaneous access via browser and native application) by the same user is permitted for a particular web application.

  FIG. 3 is a flow chart illustrating interactions between the client 104a and the server 102 that may occur in a single sign-on process 300 for a user of the client 104a, according to an exemplary embodiment.

  Process 300 may begin when the user directs the browser to a web application running on server 102 using client 104a. For example, a user may enter a predetermined URL (uniform resource locator) for accessing a web application in a web browser. Alternatively, the browser may be directed to the web application when the user "clicks" on a link displayed on the web page. The web pages of the web application encountered on the first arrival to the web application are called "landing pages".

  After reaching the landing page of the web application using a web browser (eg, Internet Explorer browser 312), the user is signed on to the web application (eg, 324) in operation 302 (also referred to as "login") ). The sign on process is detailed later in connection with FIG. If the user sign on process is successful, a session is generated and a cookie is generated. The creation of a session includes the addition of an entry to a session table, such as user session information 204, for example. The cookie may be unique for the generated session or may be a string generated using conventional techniques. The cookie is returned by the server 102 to the client 104a and stored on the client 104a for future use. Subsequent requests by users using client 104a to web application 324 (eg, HTTP requests) may include cookies, and server 102 may use the received cookies to track related requests. At this point, the user can properly sign on to the web application, and the client side portion of the web application operating on the browser content can exchange messages and / or data with the server side portion of the web application.

  In FIG. 3, operation 302 marks the flow lane of browser A 312 and the flow lane of web application 324 and the flow lane of core service 326 as a solid circle, and the flow lane of browser B 314 and the flow lane of application 316 correspond It is shown to have a circle of. The solid circle in the flow lane in an operation such as operation 302 indicates that the system component corresponding to that flow lane is actively participating in this operation (eg, exchanging messages with other system components) . Further, while it is common for actions to be ordered from the top of the page according to the order in which they occur, in some embodiments, more than one of the actions may occur simultaneously. Certain embodiments may include one or more additional operations not shown in the figures and / or may not include one or more operations shown. This aspect of showing system component level activity in a given operation is used in FIGS. 3-6.

  At act 304, a second client application (eg, 316), such as native application 316, is launched at client 104a. The native application 316 is an application that accesses the web application 324 on the server 102. According to one exemplary embodiment, a native application acquires spreadsheet data from a web application 324 on the server 102 during operation and / or exchanges data with the web application 324 (e.g. Excel).

  Native application 316 may use any of one or more browser controllers to communicate with server 102, such as via HTTP, by exchanging HTTP messages with, for example, a web server associated with web application 324 It may be configured. A native application may be able to use one or more browser controllers. The browser controller provides the ability for applications such as Excel programs to utilize HTTP, JSON and / or other protocols used for control and data exchange via the web. For example, the native application may incorporate a commercially available or freely available browser controller for one or more of Internet Explorer, Chrome, Firefox, Safari and the like. Native applications may also include customized add-in components (e.g., 318) that provide capabilities associated with the SSO functionality. For example, add-in 318 allows Excel spreadsheets in native application 316 to interact with web application 324 using one or more browser controllers. In one exemplary embodiment, custom add-in 318 is generated using Microsoft Automation or Microsoft COM.

  After native application 316 is launched, at operation 306, the native application determines if there is at least one existing session for any of the browsers (eg, 312 and 314) installed on the client. Browsers available on the client by techniques such as locating the directory structure known for each particular browser of the client storage and locating predetermined settings during installation and / or application launch. , May inform the native application. Alternatively or additionally, the native application may specify and automatically incorporate browser controls (eg, 320 and 322) for each of the browsers installed on the client. According to an embodiment, custom add-in 318 repeats the available browser controller for use by the native application. For example, for each of the available browser controllers, the native application instantiates the browser controller and sends an HTTP request to the server 102 in a configurable predetermined order or in the order in which the browser controller was discovered by the native application 316. . The request may specify all or a combination of the user, the client device, the web application, and the browser corresponding to the currently selected browser control. This process is repeated until a browser type in which a session already exists is found or until all browser types have been searched without finding an existing session. Further details regarding identifying the browser type for which a session already exists is described below with respect to FIG.

  When the server 102 receives a request from the client 104a, it corresponds to the information provided with the received request (e.g., any of a cookie, a user, a client, a web application, and a browser included in an HTTP request) Or determine whether there is an active session (corresponding to any of the combinations). This determination may be made by searching the session table to identify the corresponding session. In an exemplary embodiment, cookies generated when a session is established are sent by the client in each subsequent HTTP request to the server, and the server uses the accepted cookies in the session table. Uniquely identify the corresponding session. If it is determined that the corresponding session is currently active, session information and / or cookies associated with the corresponding session are returned to the native application.

  If the server determines that there is no session corresponding to the accepted HTTP request, the server returns a notification of the impact to the native application. In an exemplary embodiment, for example, an HTTP redirect (eg, "302 redirect") message is returned. When the native application is notified that the previous HTTP request did not result in identifying an existing connection, it forms a new HTTP request that includes information about the next browser in the list of browsers to try.

  If no corresponding existing session is found for any of the browser controls available to the native application, at operation 308, the sign-on is successfully performed and a new session and associated cookie is generated. Sign-on is detailed below in connection with FIG.

  Subsequently, at act 310, the native application operates with either the existing session identified at act 306 or the newly created session (generated at act 308). The operation of the native application may include sending an HTTP request for required data for the native application and receiving such data in HTTP / JSON format. However, native applications are not limited to using HTTP / JSON to communicate with server-side applications such as web applications. When the server device receives a data request for the web application, the session may be checked for legitimacy.

  FIG. 4 illustrates the interaction between client device 104a, client device 104b, and server device 102 that occurs when multiple login prevention (MLP) process 400 occurs. For example, in the situation where the user has already logged in and accessed a web application (e.g. 324) from a client device (e.g. client device 104a), the user signs in from a second client device (e.g. client device 104b) Process 400 may begin when accessing the same web application.

  Act 402 represents communication between a user of client device 104a and a web application on server device 102 through an established session using legitimate cookies. As shown, one of the browser and / or native applications on client device 104a may communicate via an established session.

  At some point while operation 402 continues, at operation 404, the user signs on at client device 104b. For example, the user may log in via the native application of client device 104b.

  At act 406, the native application of the client device 104b communicates with the web application on the server device by sending an HTTP request and receiving data in JSON format. As mentioned above, before sending the requested data to the requesting native application, a server-side check is performed on the legitimacy of the session. Further description of access to provider data and the authentication associated with the access is described below in connection with FIG.

  Act 408 represents the cancellation of the session between client device 104a and server device 102. Cancellation of a previous existing session may occur almost simultaneously with the creation of a new session. After the session of the client device 104a is canceled, subsequent HTTP requests from the client device 104a for requesting data to the web application fail. The user interface of the client device 104a indicates that future data acquisition from the web application will fail, and / or informs the user that the session of the client device 104a has been canceled due to a login from another location May be updated to

  FIG. 5 is between the client device 504 (eg, similar to client devices 104a, 104b) and the server device 102 that occur while performing the sign-on process 500 according to an exemplary embodiment. Show the exchange of

  Process 500 may begin when the user brings a browser to a so-called "landing page" of a web application. For example, for a web application named "IR Insights", the landing page may be at an address such as "irinsight.nasdaq.com" known to the user. Navigation may be performed by entering the URL of the landing page or by clicking on the corresponding link from another web page.

  At operation 502, when the browser on the client device reaches the landing page, the web application determines whether there is a corresponding currently active session and cookie. If no active session (and / or cookie) is found, the web application generates a temporary token and sends the token to the client device. In one embodiment, a temporary token may be pushed to the client with the web application's domain cookie.

  At act 504, the web application redirects the client device to the login application. According to one embodiment, redirection may be performed by sending a 302 HTTP redirect message to the client directing the browser on the client device to the login application. The web application's known identifier may be passed along with the redirect message. In this case, after the login process is complete, the login application can then redirect the client back to the web application. According to one embodiment, a Globally Unique Identifier (GUID) assigned to the web application may be used as the identifier passed with the redirect message.

  At act 506, the browser has received a redirect message from the web application and arrives at the login application at the address indicated in the redirect message. When accessing the login application, the browser may specify a web application (which is a browser redirect) by including a GUID corresponding to the HTTP request. The login application prompts the user for login credentials. According to an embodiment, the login credentials include a username and a password.

  At operation 508, the client sends login credentials.

  At act 510, the login application verifies login credentials. For example, the username and password may be verified against stored login and / or authentication information. After the user's login is approved, one or more existing sessions may be cancelled. In this case, the relevant service statement is not violated. According to one embodiment, the existing session for the user to access the web application may be cancelled. For example, a first in first out (FIFO) policy may be implemented for session cancellation when a new session is established. Thus, for example, if the service specification limits the number of client applications that can simultaneously access a particular web application to one, then a previously established session is canceled when a new session is created. In another embodiment, the user's existing sessions for accessing the web application are canceled if they are in the same "realm" associated with the new sign-on. "Realm" is a concept used to group GUIDs and / or GUID-Client combinations. For example, by placing certain combinations of web application 324 and client type (eg, desktop computer, smartphone) in different areas, simultaneous sign-on to the same web application 324 by the same user of desktop computer and smartphone may be permitted .

  At act 512, the login application provides a temporary token to the web application. This may be done by specifying a temporary token in the form of a key / value pair using an HTTP POST message. In one embodiment, a forgery resistant token may be provided along with a temporary token.

  At act 514, the login application redirects the client to the web application using the HTTP redirect message and the previously received identifier of the web application (eg, GUID). The login application may also generate a cookie that includes a temporary token. In one embodiment, the cookie may also include a forgery resistant cookie.

  At act 516, the client is redirected by the login application, reaches the web application, and presents the web application with one or more cookies, including a temporary token.

  At act 518, the web application validates the token.

  At act 520, the web application requests the login application to generate a permanent token.

  At act 522, the login application generates a permanent token.

  At act 524, the login application returns the generated persistent token to the web application.

  At act 526, the web application sends the client a permanent token.

  At act 528, the client stores the permanent token for future use. In one embodiment, a permanent token is used as a cookie to identify the corresponding session.

  Act 530 represents the process of following the HTTP request by the client and the return of the requested data by the server device using a message of HTTP / JSON or other format. The web application may check the subsequent legitimacy of the permanent token before returning the requested data. In one embodiment, for example, for every individual data request by the client, the web application and / or the corresponding external server checks the session legitimacy.

  FIG. 6 illustrates the interaction between the client 104a, the client 104b and the server infrastructure 102, showing the SSO and MLP in a combined series of interactions, according to an example embodiment.

  Process 600 may begin when the user brings a page, browser, to a so-called "landing page" of a web application. Navigation may be performed by entering the URL of the landing page or by clicking on the corresponding link from another web page.

  At operation 602, a user of client 104a signs in to web application 324 via browser 312. The sign on process may be performed according to the above described FIGS. 5A-5B. As described in connection with operation 302 of FIG. 3, a new session may be created for the user to interact with web application 324 and one or more corresponding cookies may be created.

  At act 604, active sessions that the user has from the client 104b are deactivated or removed. For example, as part of setting up a new session in operation 602, sessions that the same user has from other clients are deactivated. Deactivation may include marking the session table to indicate that one or more sessions are not active, or removing such a session from the session table.

  If the client 104b had an ongoing active session at the time of operation 602, then that session's entry in the session table may be removed or marked as inactive. After such removal or marking as inactive, subsequent data requests by the client 104b for the web application 324 will not succeed. This is because the server-side session validity check in response to each data request fails because it can not find an active session associated with the user and client 104b for the web application. This shows the implementation of MLP.

  At act 606, the application 316 on the client 104a is launched. The processing associated with this operation is similar to that described in connection with operation 304 of FIG.

  At act 608, the application determines an existing session. The processing associated with this operation is similar to that described in connection with operation 306 of FIG.

  FIG. 7 illustrates a process 700 performed by an application running on a client and one or more servers to enable a user to access a web application through the application according to an embodiment. Server processes to be

  Process 700 may be initiated when an application 704 (eg, native application 316 described above for accessing web application 324) is launched on a client (eg, client 104a). At act 712, upon launch, the custom add-in of application 704 (eg, add-in 318) determines available browser controls. According to one embodiment, the predetermined ordered list of browser controls may be considered as representing available browser controls. In other embodiments, available browsers may be automatically found on the client.

  At act 714, a first browser control is selected. In one embodiment, for example, the browser control that appears first in the ordered list is selected. In the exemplary embodiment, if the application includes an Excel program, then the Internet Explorer browser controller is selected as the first choice. This is because, for example, it is expected that a high level of compatibility exists between the Internet Explorer browser controller and the Excel program.

  At operation 716, a request for an existing session is sent to the server. The request indicates at least the selected browser control, the web application to be accessed, the user ID, and the client identification.

  The request may be sent to a predetermined designated web address. For example, a company may set an application on a server to a predetermined designated web address to support processing performed by a custom add-in incorporated into the application.

  At act 718, the web server 706 at the designated web address receives the request sent by the client. The web server 706 (possibly in conjunction with an application server, database and / or other processes) sends messages to other applications requesting information about existing sessions corresponding to requests received from clients. Do. Web server 706 and other applications may be applications within core service 114 in an embodiment.

  At operation 720, the other application 708 may be an account management application running on the server 102, and the other application 708 receives the request. The application 708 may determine an existing session corresponding to the parameters specified in the received request by checking the session table or other data structure in which the existing session is maintained. The parameters specified in the received request may include the type of browser (or the selected browser control described above), the identity of the user, the client and the requested web application.

  If an existing session is found, then the cookie associated with the existing session is accessed. As described above in connection with FIG. 2, each existing session may have an associated cookie.

  At operation 722, if the session is not found, the application 708 responds to the application 706, indicating that the session discovery has failed.

  Otherwise, if a session is found, at operation 722, application 708 responds to application 706 by providing information about the existing session and / or a copy of the accessed cookie.

  At act 724, application 706 sends a response to application 704 based on the response received from application 708. Thus, if an existing session is found in operation 720, information about the existing session and / or a copy of the cookie corresponding to the existing session is included in the response to application 704. If no existing session is found in operation 720, the response informs application 708 that the discovery of the existing session for the currently selected browser control has failed.

  At operation 726, the application 704 determines whether an existing session has been found based on the latest response received from the add-in support application 706.

  If an existing session is not found, application 704 attempts to select the next browser control from the one or more browser controls determined in operation 712. Then, if there is another browser control that has not yet been tested for the existing session, then at operation 728 another browser control for which the existing session is to be determined is selected, and processing proceeds to operation 716. At operation 716, a request may now be generated that includes the newly selected browser control, and processing may proceed to operation 718.

  If it is determined in act 726 that no existing session is found and there is no browser control left to be tested for the existing session, then in act 730 the session from the client for the web application to be accessed is It is determined that it does not currently exist, and the application 704 can perform sign-on.

  Sign-on may include the application 704 sending an HTTP request to a predetermined address of the web application. FIG. 5 illustrates an exemplary process that occurs when the browser running on the client is signed on. Similar processes (i.e., similar sequences of operations) may be performed by the server infrastructure and the application on the client when the application signs in. During the sign-on process, for example, when the application 704 receives a login prompt (shown to be sent from the core service 526), a login window is displayed for the user to enter login credentials. According to one embodiment, the login window in the application is described below in conjunction with FIG. A new session will be created when the application signs in for the first time before the session for the browser on the client is created. The application interacts with the web application using this new session.

  On the other hand, if an existing session is found, at operation 732 the cookie received in response from the add-in support application 706 is stored in a storage accessible to the application. Subsequent requests for the web application may include the cookie. Thus, with an existing session, and without requiring the user to perform a separate sign-on through the application, the web application can service the application 704.

  In one embodiment, more operations may be performed by application 704 before application 704 begins to access application data provided by the web application. In one embodiment, after operation 732 (eg, after an existing session has been discovered and a cookie for accessing the web application has been received by the application), the application 704 instantiates another browser control and finds Proceed to accessing the web application using the existing session (e.g., with the previously obtained cookie) and the newly instantiated browser control. This capability allows cookies to be shared across browsers (eg, between browsers). For example, in the context of acquiring a cookie from a chrome browser server, however, if the application requires certain features available on other types of browser controllers (e.g. Internet Explorer browser controller), the application newly Cookies already acquired by other types of instantiated browser controllers may be used.

  FIG. 8 shows a process 800 for an application or client-side code on client 804 to access data from external server 810, according to an exemplary embodiment.

  Process 800 may begin when an application or client-side code on client 804 signs on to a web application and then the application or client-side code on client requests access to data from an external server.

  At act 812, the client 804 sends a data request to the web application 806 on the server 102. The request may include a cookie previously obtained for the session and held by the client. The request indicates the data being requested.

  At operation 814, the web application 806 receives the request from the client 804. The processing at operation 814 may include determining where to obtain the requested data. Processing may also include determining at least some of the data being requested locally.

  At act 816, the web application sends a data request to the external server as determined at act 814 and / or as specified in the request from the client 804.

  At operation 818, the external server 810 receives the request. In one embodiment, processing at operation 818 may include checking a locally maintained table for a valid session. The check may be based on cookies from the request and / or user specific information. If the check from the locally maintained table indicates that the user approves to receive data, processing may proceed to operation 826 to provide the requested data.

  In some other exemplary embodiments, in addition to or instead of checking the locally maintained table, at operation 820, the external server requests the core service 808 to confirm the data request. Send a request for

  At act 822, the core service application 808 checks the session table and / or other data structures to determine if the data request is approved.

  At operation 824, the status is reported to the external server.

  At act 826, it is determined to provide data to the client based at least on whether the data request has been properly approved. Alternatively, if it is determined that the request has not been properly approved, then a determination is made not to provide data.

  At act 828, a response is sent to the web application 806 based on whether data should be provided to the client. The response may either contain the requested data or contain a failure notification.

  At act 830, the web application determines whether the client's request has succeeded or failed.

  At act 832, the web application sends a response to the client.

  FIG. 9 illustrates an exemplary implementation of a login window provided to a user from within an application, such as application 120a or 120b. For example, if it is determined that the user of client 104a needs to sign in anew while application 120a is running (as shown in window 900), to accept the user's login credentials. A login window 902 is displayed.

  FIG. 10 shows a non-limiting exemplary block diagram of the hardware architecture of system 100. In the example shown in FIG. 10, client system 1010 communicates with server system 1020 via network 1040. Network 1040 may include a network of interconnected computing devices, such as the Internet. Network 1040 may include a local area network (LAN) or may include peer-to-peer connections between client system 1010 and server system 1020.

  Exemplary client system 1010 and server system 1020 may correspond to client 104 and server 102 shown in FIG. That is, the hardware elements described in FIG. 10 can be used to implement the various software components and operations described and shown herein with reference to FIG. For example, the client system 1010 of FIG. 10 includes at least one processor CPU 1031, at least one memory 1032, at least one input / output device I / O 1033, and a component for generating and displaying a user interface UI 1034. May be included. The at least one memory 1032 may include a computer readable storage medium such as a random access memory (RAM), a static RAM, a flash memory, or a magnetic disk. The I / O device 1033 may include or may include all communication devices such as transceivers (eg, wireless transceivers, wired transceivers) that transmit and receive data. The I / O device 1033 may include an interface for connecting a non-transitory computer readable carrier medium to the client system 1010 to send and receive data.

  It should be understood that a combination of elements of client system 1010 can be used to implement the exemplary web browser applications 117, 118 and application 120a of FIG. For example, memory 1032 may load files (eg, HTML, XML, JavaScript files) associated with the application, and CPU 1031 may be used to execute instructions associated with the application. Using I / O device 1033, various elements can be fetched from server system 1020, including SPA, and / or can interact with the user.

  Server system 1020 comprises various hardware components used to implement server 102 shown in FIG. 1 or the software components of FIG. For example, server system 1020 may include the hardware components of at least one processor CPU 1021, at least one memory 1022, and at least one input / output device I / O 1023. At least one memory 1022 may include a computer readable carrier medium such as random access memory (RAM), static RAM, flash memory, magnetic disk, and the like. The I / O device 1023 may include or include all communication devices such as transceivers (eg, wireless transceivers, wired transceivers) that transmit and receive data. The I / O device 1023 may include an interface for connecting a non-transitory computer readable carrier to the server system 1020 to send and receive data. In one exemplary embodiment, the client system's I / O device 1033 can communicate with the server system's I / O 1023 via a network.

  Similar to client system 1010, server system 1020 can implement and / or execute an application. For example, memory 1022 can be used to store information in database 110 in addition to components and files used by web servers and application servers associated with web application 112 and core service 114. The CPU 1021 may be used in executing software necessary to generate a corresponding module requested by the client system 1010 and transmitted thereto. For example, the CPU 1021 may be used to generate necessary modules generated by the application server. Similarly, I / O device 1023 may be used by the web server to send different application elements to client system 1010. Of course, these examples are non-limiting, and the system envisages using hardware elements in various ways.

  The techniques described above with respect to the described SSO and MLP, among other things, provide the ability to reduce the misuse of web application resources while improving the efficiency with which the user interacts with the web application through the communication network. . As detailed above, certain embodiments may be used to control user access to various networked resources such that the entire usage statement for such resources is adhered to.

  In the examples herein, specific details are set forth such as specific nodes, functional entities, technologies, protocols, standards, etc. to provide an understanding of the described technology for purposes of illustration and not limitation. Ru. It will be apparent to those skilled in the art that other embodiments may be practiced apart from the detailed description below. In other instances, detailed descriptions of well-known methods, devices, techniques, etc. are omitted so as not to obscure the description with unnecessary detail. Individual functional blocks are shown in the figure. The functionality of these blocks is achieved by using a separate hardware circuit (e.g., as shown in FIG. 10) and a software program (e.g., as shown in FIG. 1) to cooperate with a suitable programmed microprocessor or general purpose computer. Those skilled in the art will appreciate that this can be accomplished using an application specific integrated circuit (ASIC) and / or using one or more digital signal processors (DSPs) using Will do. Software program instructions and data may be retained on a computer readable carrier medium, which when executed by a computer or other suitable processor control, perform the function. Although databases may be shown as tables below, other formats (including relational databases, object-based models, and / or distributed databases) can be used to hold and manipulate data.

Although the process steps, algorithms or the like may be described or claimed in a particular order, such processes may be configured to operate in a different order. In other words, the order of any sequences or steps specified or claimed does not necessarily indicate that the steps are to be performed in that order. The steps of processing described herein may be performed in any order that is possible. Also, although some steps are described or implied to occur non-simultaneously (e.g. because some steps are described after other steps), they are performed simultaneously sell. Furthermore, the description of the illustrated process in the drawings does not imply that the illustrated process is exclusive to other variations or modifications, and the illustrated process or any step thereof is not limited to the present technology. It does not imply that it is necessary, nor does it imply that the illustrated process is preferred.

  Various forms of computer readable media / transmissions may be involved in carrying data (e.g., sequences of instructions) to a processor. For example, data may be (i) transmitted from memory to the processor, (ii) carried via any type of transmission medium (eg, wired, wireless, optical, etc.), (iii) Ethernet May be formatted and / or transmitted according to any format, standard or protocol such as (or IEEE 802.3), ATP, Bluetooth, TCP / IP, TDMA, CDMA, 3G etc. and / or (Iv) may be encrypted to ensure privacy or to prevent leakage in any of a variety of known ways.

  In this document, operations may be performed, may be, or may be, and features, elements, or configurations may be included in a given context, or may be Are described as being able to “or” or “applicable” and “given”, “can” or “may” that a given item has a given property. Whenever, or whenever any similar phrase is used, including the terms "may", "can" or "may", a given operation, feature, element, configuration It should be understood that although at least one embodiment is shown in at least one embodiment, a property, etc. need not be shown in all embodiments.

  Although the techniques have been described in the context of Angular JS, this has been done to facilitate the description and the techniques described herein may be other SPA techniques or other web techniques and / or / or It is understood that it is applicable in the context of other software technologies.

  Although the present technology has been described in relation to what is presently considered to be the most practical and preferred embodiment, the present technology is not limited to the disclosed embodiments, but rather various It should be understood that it is intended to cover variations and equivalent arrangements of

Claims (15)

A system comprising at least one client device and at least one server device executing a server-side process of a web application, the system comprising:
A first client application comprising a first processing system wherein the at least one client device comprises at least one hardware processor, the first processing system providing a first client-side portion of the web application, and a first of the web application And a second client application configured to execute a second client application, wherein the first client application is a browser and the second client application is a native application.
The at least one server comprises a second processing system having at least one hardware processor, the second processing system being configured to execute the server side portion of the web application;
The second processing system
Having the first client application perform a sign-on process prior to accessing application data provided by the server side portion of the web application in response to a first access request received from the first client application; ,
Generating a first session in connection with the sign-on process to be performed, the access to the application data being provided to the first client application later using the first session; When,
When the second request is received from the second client application, the second client application uses the at least one identifier included in the second request and the browser type associated with the second request to use the application. Determining whether the first session can be used to access data;
If it is determined that the first client application can use the first session to access the application data, the second client application accesses the application data using the first session. To provide and
If it is determined that the second client application can not use the first session to access the application data, having the second client application perform a sign-on process before accessing the application data; After the second client application performs the sign-on process, the application data is sent to the second client application using a second session generated in connection with the sign-on process performed by the second client application. Providing access to
Creating a third session associated with sign-on by an instance of either the first client application or the second client application running on another client device , the third session running on the other device Later providing access to the application data using the third session to the instance to be created;
Deactivating the first session in response to generating the third session, and accessing the application data by the first client application and the second client application executed on the at least one client device; And a system configured to perform an action including: preventing.   The determination may include determining whether a value corresponding to the identifier is stored in the memory of the at least one server device in association with at least one of a plurality of session records. The system according to 1. The above determination is
Further including identifying a corresponding previously stored credential associated with the web application;
The system of claim 2, wherein the determining is further based on the identified qualification. The first processing system further comprises
Determining the one or more candidate browser controls used by the second client application to communicate with the server side portion of the web application by the second client application;
The second client application may send a first instance of the second request to the server device, wherein the first instance is a selected first candidate browser control of the one or more candidate browser controls. Corresponding to, sending, and
Whether the second client application accesses the application data or sends a second instance of the second request based on the response received for the sent first instance of the second request The method of claim 1, wherein determining whether the second instance is to correspond to another one of the one or more candidate browser controls is performed. system.   (A) if the browser type of the first client application is the same as the browser type of the first candidate browser control selected from the one or more candidate browser controls, the received response is the first session The received response if the presence of (b) the browser type of the first client application differs from the browser type of the selected first candidate browser control of the one or more candidate browser controls; The system according to claim 4, wherein indicates that the second client application has failed to find an available existing session. The first processing system further comprises
If the received response indicates the presence of the first session and the browser type of the currently selected candidate browser control of the one or more candidate browser controls is different from a predetermined browser type, Obtaining a first session identifier included in the response;
Instantiating the predetermined browser type browser control;
The system of claim 5, configured to access the application data using the instantiated browser control of the predetermined browser type and the first session identifier. The first processing system further comprises
The second client application is configured to perform the sign on in response to a response received for an instance of the second request after sending one or more instances of the second request. The system described in 5. The second processing system further comprises
Determining whether the first session corresponds to a browser type currently associated with the second request in response to receiving an instance of the second request;
Returning a first session identifier associated with the first session to the second client application if the determining determines that the first session corresponds to a browser type currently associated with the second request And
If it is determined that the determination does not correspond to the browser type currently associated with the second request, then the second client application finds a session usable by the second client application The system of claim 1, configured to: return an indication that it did not exist. A server device comprising at least one hardware processor configured to execute a server side portion of a web application, the at least one processor comprising:
A first client application having a first client-side portion of the web application, the first client application being responsive to a first access request received from a first client application executed by a first client device; Executing a sign-on process prior to accessing application data provided by the server-side portion of the application, wherein the first client application is a browser application;
Generating a first session in connection with the sign-on process to be performed, the access to the application data being provided to the first client application later using the first session; When,
At least one second client application having a second client-side portion of the web application, the second request being received from a second client application executed by a first client device , the second request being included in the second request Determining whether the second client application can use the first session to access the application data using an identifier and a browser type associated with the second request. Determining that the second client application is a native application;
If it is determined that the first client application can use the first session to access the application data, the second client application accesses the application data using the first session. To provide and
If it is determined that the second client application can not use the first session to access the application data, having the second client application perform a sign-on process before accessing the application data; After the second client application performs the sign-on process, the application data is sent to the second client application using a second session generated in connection with the sign-on process performed by the second client application. Providing access to
Creating a third session associated with sign-on by an instance of either the first client application or the second client application running on another client device , the third session running on the other device Later providing access to the application data using the third session to the instance to be created;
In response to creating the third session, deactivate the first session to prevent access to the application data by the first client application and the second client application executed on the first client device And a server device configured to perform an operation. The at least one processor further comprises:
Determining whether the first session corresponds to a browser type currently associated with the second request in response to receiving an instance of the second request;
Returning a first session identifier associated with the first session to the second client application if the determining determines that the first session corresponds to a browser type currently associated with the second request And
If it is determined that the determination does not correspond to the browser type currently associated with the second request, then the second client application finds a session usable by the second client application 10. The server device of claim 9, configured to: return an indication that it did not exist. Executing the server side portion of the web application, the method being performed by a server device comprising at least one processor;
A first client application having a first client-side portion of the web application, the first client application being responsive to a first access request received from a first client application executed by a first client device; Executing a sign-on process prior to accessing application data provided by the server-side portion of the application, wherein the first client application is a browser application;
Generating a first session in connection with the performed sign-on process, the access to the application data being provided to the first client application later using the first session; When,
At least one second client application having a second client-side portion of the web application, the second request being received from a second client application executed by a first client device , the second request being included in the second request Determining whether the second client application can use the first session to access the application data using an identifier and a browser type associated with the second request. Determining that the second client application is a native application;
If it is determined that the first client application can use the first session to access the application data, the second client application accesses the application data using the first session. To provide and
If it is determined that the second client application can not use the first session to access the application data, having the second client application perform a sign-on process before accessing the application data; After the second client application performs the sign-on process, the application data is sent to the second client application using a second session generated in connection with the sign-on process performed by the second client application. Providing access to
Creating a third session associated with sign-on by an instance of either the first client application or the second client application running on another client device , the third session running on the other device Later providing access to the application data using the third session to the instance to be created;
In response to creating the third session, deactivate the first session to prevent access to the application data by the first client application and the second client application executed on the first client device And how to contain it. A non-transitory computer readable storage medium having program instructions stored thereon, wherein said program instructions are executed by a server device computer on said server device,
Running the server-side part of the web application,
A first client application having a first client-side portion of the web application, the first client application being responsive to a first access request received from a first client application executed by a first client device; Executing a sign-on process prior to accessing application data provided by the server-side portion of the application, wherein the first client application is a browser application;
Generating a first session in connection with the sign-on process to be performed, the access to the application data being provided to the first client application later using the first session; When,
At least one second client application having a second client-side portion of the web application, the second request being received from a second client application executed by a first client device , the second request being included in the second request Determining whether the second client application can use the first session to access the application data using an identifier and a browser type associated with the second request;
If it is determined that the first client application can use the first session to access the application data, the second client application accesses the application data using the first session. To provide and
If it is determined that the second client application can not use the first session to access the application data, having the second client application perform a sign-on process before accessing the application data; After the second client application performs the sign-on process, the application data is sent to the second client application using a second session generated in connection with the sign-on process performed by the second client application. Providing access to
Creating a third session associated with sign-on by an instance of either the first client application or the second client application running on another client device , the third session running on the other device Later providing access to the application data using the third session to the instance to be created;
In response to creating the third session, deactivate the first session to prevent access to the application data by the first client application and the second client application executed on the first client device And non-transitory computer readable carrier medium for performing operations including. A client device comprising at least one hardware processor, the at least one hardware processor being a browser application providing a first client-side portion of a web application, a first client application and a second client of the web application And at least one hardware processor configured to execute a second client application that is a native application providing the side part,
The first client application that has sent a first request to the server side portion of the web application signs on to the server side portion of the web application, and the sign is made after the sign on made. Accessing application data from the server side portion of the web application using a first session generated in connection with on;
Wherein the second client application Gasa Badebaisu, wherein to communicate with the server-side portion of the web application, the second request including the one selected of one or more candidate browser controls used by the second client application To send
Whether the second client application accesses application data of the server-side portion of the web application or another of the second request based on the response received for the second request sent. Determining whether to send an instance, and
The server side portion of the web application is:
When the second request is received from the second client application, the second client application may use the at least one identifier included in the second request and the browser type associated with the second request. Determining whether the first session can be used to access application data;
If it is determined that the first client application can use the first session to access the application data, the second client application accesses the application data using the first session. To provide and
If it is determined that the second client application can not use the first session to access the application data, having the second client application perform a sign-on process before accessing the application data; After the second client application performs the sign-on process, the application data is sent to the second client application using a second session generated in connection with the sign-on process performed by the second client application. Providing access to
Creating a third session in connection with sign-on by an instance of either the first client application or the second client application running on another client device, wherein the third session is performed on the other client device Generating, later providing access to the application data using the third session to the instance to be executed;
Deactivating the first session in response to creating the third session to prevent access to the application data by the first client application and the second client application executed on the client device; , Client device configured to do.   (A) if the browser type of the first client application is the same as the browser type of the candidate browser control selected from the one or more candidate browser controls, the received response indicates the presence of the first session And (b) if the browser type of the first client application is different from the browser type of the candidate browser control selected from the one or more candidate browser controls, the received response is the second The client device according to claim 13, wherein the client device represents failure to find an existing session that can be used. The at least one hardware processor further indicates that the received response indicates the presence of the first session, and a browser type of the selected candidate browser control of the one or more candidate browser controls is predetermined. Obtaining a first session identifier included in the response if different from a browser type;
Instantiating the predetermined browser type browser control;
15. The client device of claim 14, configured to access the application data using the instantiated browser control of the predetermined browser type and the first session identifier.

Images