System and method for controlling state tokens

#The invention generally relates to a system and method for controlling state tokens, and in particular, to securing sensitive application state tokens, linking an application state token to one or more identities or other state tokens, and maintaining application state tokens to integrate various different systems or applications.

#In many organizations, workers interact with multiple applications during daily routines to access or input sensitive information. Further, with the proliferation of intranets, business-to-business extranets, cloud applications, and other distributed work environments have lead to customers, partners, and employees demanding anytime, anywhere access to critical applications, information, and services. However, although these information technology developments present new opportunities to increase revenues, manage costs, and deepen relationships with users, opening information technology organizations to distributed work environments can introduce significant security, management, and compliance challenges. For example, because users often interact with sensitive data and multiple applications that can be distributed among various information technology environments, many applications have been front-ended with secure logon processes to handle data security and compliance requirements. However, because different systems and applications typically have different authentication schemes, users often have to enter different authentication credentials to access the various systems and applications. In an effort to accommodate these diverse authentication processes, many users resort to insecure practices such as writing down passwords or using the same password for multiple systems or applications, which can defeat the purpose of secure logon procedures, especially in situations where workers or users share workstations or work areas (e.g., in hospitals or help desk environments).

#As such, despite the promise that distributed work environments have to increase revenues, manage costs, and deepen user relationships, existing systems tend to fall short in effectively balancing security needs to protect sensitive data with business needs to provide workers with efficient access. For example, enterprise resource planning (ERP) solutions were originally deployed in client/server implementations, but in recent years many ERP vendors have developed web-based front ends to ease delivering these solutions to users. However, like any other standalone application, these solutions tend to come with distinct security systems and require separate logon processes. While most ERP solutions generally provide single sign-on (SSO) capabilities between the individual ERP components, they typically do not integrate access security with other web-based applications that may be distributed across the organization. Thus, because many organizations have initiated efforts to move towards web-based approaches to deliver applications that need to meet information and access needs for substantial numbers of internal and external users, the need to extend SSO capabilities across the organization has become increasingly important. Further, to let business in while keeping risk out, many organizations have sought to standardize and centralize information technology infrastructures, including security management. These factors, among others, result in a strong desire within the information technology community to have a single access management system that can provide centralized authentication, authorization, auditing, and SSO across all web-enabled applications.

#FIG. 1 illustrates an exemplary system that can secure sensitive state tokens, link multiple state tokens to one another, integrate various different systems or applications with state tokens, and otherwise control state tokens, according to one aspect of the invention.

#FIG. 2 illustrates an exemplary method that can secure and otherwise control sensitive state tokens, according to one aspect of the invention.

#FIG. 3 illustrates an exemplary method that can embed validators into state tokens to link multiple state tokens to one another, according to one aspect of the invention.

#According to one aspect of the invention, FIG. 1 illustrates an exemplary system 100 that can secure sensitive state tokens, link multiple state tokens to one another, integrate various different systems or applications with state tokens, and otherwise control state tokens. In particular, the system 100 illustrated in FIG. 1 may generally provide various mechanisms to secure sensitive application state tokens, link one application state token to one or more other state tokens that represent certain communication sessions or identities, and maintain application state tokens to integrate various different systems or applications. For example, as will be described in further detail herein, the system 100 may override schemes that one or more applications use to manage state information, wherein the system 100 may operate in a framework that can enforce various state management overrides to define policies that provide fine-grained control over any default or other semantics that the applications use to manage tokens representing the state information. Furthermore, in one implementation, the system 100 may link a first application state token to another state token that represents a certain identity or communication session, whereby the first application state token may be validated in response to determining that the identity or session represented in the other state token created the first application state token, or alternatively rejected in response to determining that the identity or session represented in the other state token did not create the first application state token. In one implementation, state tokens that represent active communication sessions may be copied from browser processes to various external clients or applications, which may share information contained in the state tokens among the various external clients or applications and thereby integrate state information across the various external clients or applications. In one implementation, as will be described in further detail herein, the system 100 shown in FIG. 1 may generally include a web server 130 having various modules that provide the mechanisms noted above to control state tokens.

#In particular, the web server 130 may generally include, among other things, a token input/output (I/O) module 135 that can handle inbound and outbound state token processing and a token validation module 140 that can validate whether a particular state token complies with any control parameters or other constraints associated with the state token. Furthermore, in one implementation, the web server 130 may further include a configuration module 145 that communicates with one or more agent configuration objects 180 that reside on a policy server 170 via an agent application program interface 160, wherein the policy server 170 and the agent configuration objects 180 residing thereon may configure the token I/O module 135 and the token validation module 140 that handle inbound, outbound, and validation processing for the state tokens controlled thereby. Thus, the policy server 170 and the agent configuration objects 180 may provide a centralized mechanism that can configure and manage inbound, outbound, and validation state token processing in the web server 130. Furthermore, the web server 130 may include a transaction module 150 that provides functionality to control or otherwise manage the state tokens, wherein the functionality provided with the transaction module 150 may include encrypting or otherwise securing the state tokens, linking multiple state tokens to one another, and embedding validation information within the state tokens, among other things. For example, the transaction module 150 may utilize one or more keys contained in a key store 190 located on the policy server 170 to encrypt the state tokens or otherwise leverage any key management mechanisms that the policy server 170 may provide. As such, the token I/O module 135, the token validation module 140, the configuration module 145, and the transaction module 150 deployed on the web server 130 may collectively provide the framework to control state tokens, wherein the state token control framework may be packaged within a standalone framework or bundled with the policy server 170 and/or components associated therewith to control or otherwise manage identities, policies, or other controls associated with the state tokens.

#In one implementation, as noted above, the system 100 may provide a mechanism to secure sensitive application state tokens. In particular, although the HTTP Cookie specification described in “HTTP State Management Mechanism,” the contents of which are hereby incorporated by reference in their entirety, generally describes mechanisms that can restrict the manner in which a web browser 115 executing on a client device 125 returns a cookie or other state token, the HTTP Cookie specification lacks any built-in mechanisms to secure the information contained in the cookie or other state token to maintain the state information. Rather, the information contained in the cookie or other state token must be encrypted to protect the information contained therein from unauthorized inspection. As such, in one implementation, the transaction module 150 located on the web server 130 may be configured to encrypt application cookies or other application state tokens, which may alternatively referred to herein simply as “state tokens,” with one or more keys retrieved from the key store 190 located on the policy server 170, thereby securing the information contained in the state tokens. The secured state tokens may therefore be opaque during transit between the web server 130 and the web browser 115, opaque to any applications 120 that receive the state tokens from the web browser 115, and transparent to the web server 130, the policy server 170, or any other servers that interact with such applications 120. For example, in response to the web server 130, the policy server 170, or other servers receiving the encrypted and secured state tokens, the servers may retrieve the appropriate key from the key store 190 to decrypt the state tokens and read the contents contained therein.