US20110213956A1 - Techniques for managing a secure communication session - Google Patents
Techniques for managing a secure communication session Download PDFInfo
- Publication number
- US20110213956A1 US20110213956A1 US12/714,451 US71445110A US2011213956A1 US 20110213956 A1 US20110213956 A1 US 20110213956A1 US 71445110 A US71445110 A US 71445110A US 2011213956 A1 US2011213956 A1 US 2011213956A1
- Authority
- US
- United States
- Prior art keywords
- browser
- server
- session
- secure communication
- browser application
- 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.)
- Granted
Links
Images
Classifications
-
- 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- 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/16—Implementing security features at a particular protocol layer
- H04L63/166—Implementing security features at a particular protocol layer at the transport layer
Definitions
- web browser is the most ubiquitous and common application that exists today for communicating. Because of this reason, many Identity systems have developed their authentication model assuming the web browser to be their application that initiates authentication. Also, web browser cookies are the most common form of holding the identity of a session that is authenticated.
- non-web based applications such as a Secure Socket Layer (SSL) Virtual Private Network (VPN)
- SSL Secure Socket Layer
- VPN Virtual Private Network
- This kind of a non-web application uses the server's web interface to gain authentication and access policy information. Users may also close the browser accidentally resulting in un-wanted disconnection of their non-web application. Also, the web browsers generally cannot be minimized to the system tray area.
- a method for managing a secure communication session is provided.
- a request for a secure communication session is detected; the secure communication session between a non-browser application and a server and the request initiated by the non-browser application.
- the secure communication session is established between the non-browser application and the server via a browser.
- a session cookie that the browser uses with the secure communication session is mapped to a secure token and this secure token is transferred to the non-browser application in a secure fashion via the browser.
- the secure communication session is maintained after the browser is shut down by translating the secure token supplied by the non-browser application into the session cookie expected by the server for the secure communication session.
- FIG. 1 is a diagram of a method for managing a secure communication session, according to an example embodiment.
- FIG. 2 is a diagram of another method for dynamically managing a secure communication session, according to an example embodiment.
- FIG. 3 is a diagram of a secure communication session management system, according to an example embodiment.
- FIG. 4 is a diagram of an example flow interaction diagram for a secure communication session management system, according to an example embodiment.
- a “resource” includes a user, service, system, device, directory, data store, groups of users, combinations of these things, etc.
- a “principal” is a specific type of resource, such as an automated service or user that acquires an identity.
- a designation as to what is a resource and what is a principal can change depending upon the context of any given network transaction. Thus, if one resource attempts to access another resource, the actor of the transaction may be viewed as a principal.
- An “identity” is something that is formulated from one or more identifiers and secrets that provide a statement of roles and/or permissions that the identity has in relation to resources.
- An “identifier” is information, which may be private and permits an identity to be formed, and some portions of an identifier may be public information, such as a user identifier, name, etc. Some examples of identifiers include social security number (SSN), user identifier and password pair, account number, retina scan, fingerprint, face scan, etc.
- SSN social security number
- password password
- non-browser application is a software service, system, and/or module that does not rely on and is not implemented within a browser.
- the non-browser application includes a web interface to interact with and communicate with a browser but does not require a browser and is not embedded within a browser.
- Various embodiments of this invention can be implemented in existing network architectures.
- the techniques presented herein are implemented in whole or in part in the Novell® operating system products, access management products, directory-based products and other products distributed by Novell®, Inc., of Waltham, Mass.
- the techniques presented herein are implemented in machines, such as processor or processor-enabled devices. These machines are configured to specifically perform the processing of the methods and systems presented herein. Moreover, the methods and systems are implemented and reside within computer-readable storage media and processed on the machines configured to perform the methods.
- FIG. 1 is a diagram of a method 100 for managing a secure communication session, according to an example embodiment.
- the method 100 (hereinafter “server communication service”) is implemented in a machine-accessible and computer-readable medium and instructions that execute on one or more processors (machines, computers, processors, etc.).
- the machine such as a server, is specifically configured to process the server communication service.
- the server communication service is operational over and processes within a network.
- the network may be wired, wireless, or a combination of wired and wireless.
- the server communication service represents processing for a Secure Socket Layer (SSL) Virtual Private Network (VPN) (referred to as an SSL VPN) performed by a server.
- SSL Secure Socket Layer
- VPN Virtual Private Network
- the server communication service detects a request for a secure communication session between a non-browser application and a server.
- the request is initiated by the non-browser application.
- a secure communication session is an authenticated communication session that can use encryption.
- the server communication service identifies the request as a request for the secure communication session to a SSL VPN between the non-browser application and the server.
- the server communication service establishes the secure communication session between the non-browser application and the server via a browser. That is, a browser is used as an intermediary to initially establish the secure communication session.
- a browser is used as an intermediary to initially establish the secure communication session.
- conventionally the browser needed to stay alive and active during the session between the non-browser application and the server; that is not the case with the techniques presented herein and below (as described more completely below).
- the server communication service authenticates the non-browser application via redirection of the browser to an identity service.
- the identity service performs authentication on behalf of the server. So, the server offloads authentication to a third-party, such as an identity service.
- the identity service is used to authenticate the non-browser application or a user of the non-browser application for access to the secure communication session and correspondingly the server.
- the server communication service maps a session cookie that the browser uses with the secure communication session to a secure token and then the server communication service instructs the browser to supply the secure token to the non-browser application.
- the server communication service instructs the browser to set the session cookie supplied by the server and an authentication token supplied by the identity service within the browser. These can be set as two distinct cookies (a more complete explanation of this scenario is described in detail below with reference to the FIG. 4 ).
- the server communication service instructs the browser to shut down and close; again, this is after the secure token is supplied or successfully provided to the non-browser application.
- the server communication service maintains the secure communication session after the browser is shut down or closed. This is done by the server communication service translating the secure token supplied by the non-browser application into the session cookie expected by the server. So, the server maintains and recognizes the session cookie but the browser closed at this point in time. So, the server communication service maintains the session cookie and its mapping to the secure token and when the secure token is supplied by the non-browser application, the server communication service translates the secure token to the session cookie and provides that to the server so the secure communication session continues unabated even without the presence of the browser. This can also be done by re-forming the secure communication session with the session cookie. Conventionally, this could not be achieved as the browser had to remain active to supply the session cookie or the secure session was lost.
- the server communication service logs the non-browser application into the secure communication session after the browser is shut down using the secure token.
- the server communication service instructs the non-browser application to use a new session cookie in place of the secure token for communications after logging into the secure communication session.
- the new session cookie mapped to the original session cookie and the new session cookie supplied to the server each time the non-browser application communicates during the secure communication session with the new session cookie.
- FIG. 2 is a diagram of another method 200 for dynamically managing a secure communication session, according to an example embodiment.
- the method 200 (hereinafter “client communication service”) is implemented in a machine-accessible and computer-readable storage medium as instructions that execute on one or more processors of a network.
- the network may be wired, wireless, or a combination of wired and wireless.
- the processor such as a client, (device having a processing instance of the client communication service) is specifically configured to process the client communication service.
- the client communication service is a non-browser application. That is, the client communication service is not browser based and executes independent of a browser.
- the server communication service represented by the method 100 of the FIG. 1 provides processing from the perspective of a server, whereas the client communication service represents processing that occurs on a client and that occurs outside a browser of the client.
- the client communication service requests a SSL VPN connection with a server.
- the request for the SSL VPN connection is made to a browser or intercepted and initially handled by the browser on behalf of the client communication service.
- the client communication service generates the request in response to an action of a user. That is, the user activates a request to connect to the server and in response to that an URL link is constructed as the request and the browser initiates to assist in establishing the SSL VPN connection with the server.
- the client communication service interacts with a user via the browser to authenticate the user to an identity service for the SSL VPN connection.
- the client communication service receives a secret token from the browser.
- the browser acquired the secret token as part of a mapping to a session cookie for the SSL VPN connection from the server. The details of this mapping was provided above with reference to the method 100 of the FIG. 1 .
- the client communication service supplies the secret token directly back to the server for purposes of initially logging into and establishing the SSL VPN connection with the server.
- the client communication service receives from the server a new cookie.
- the new cookie is to replace the secret token after the SSL VPN connection is initially established via the secure token.
- the client communication service supplies the new session cookie for each communication with the server during the SSL VPN connection.
- the method 100 of the FIG. 1 translates the new session cookie into the original session cookie to maintain the SSL VPN connection with the server for the client communication service.
- the client communication service shuts down the browser while maintaining the SSL VPN connection with the service. This is done via the secure token that the server translates to the session cookie so that the SSL VPN connection remains active. So, the SSL VPN connection remains active and valid after the browser is closed or shut down and is non-operational on the client.
- the client communication service shuts down the browser based on a manual instruction from the user to close the browser. So, the user may be given a notice that the user can shut the browser down if desired. The decision or action to shut the browser down rests with the user in this scenario.
- the client communication service automatically shuts down the browser once the SSL VPN connection is established via the secret token.
- a profile associated with the client communication service or a user can be used to decide whether the user is given control to shut the browser or down or whether the browser is automatically shut down. It is noted that the browser does not have to be shut down but when the browser is shut down the SSL VPN connection is not lost.
- FIG. 3 is a diagram of a secure communication session management system 300 , according to an example embodiment.
- the secure communication session management system 300 is implemented in a machine-accessible and computer-readable storage medium as instructions that execute on one or more processors (multiprocessor) and that is operational over a network.
- the one or more processors are specifically configured to process the components of the secure communication session management system 300 .
- the network may be wired, wireless, or a combination of wired and wireless.
- the secure communication session management system 300 implements, inter alia, certain aspects of the methods 100 and 200 represented by the FIGS. 1 and 2 , respectively.
- the secure communication session management system 300 includes a non-browser application 301 and a server 302 . Each of these and their interactions with one another will now be discussed in turn.
- the non-browser application 301 is implemented in a computer-readable storage medium (non-transitory) and executes on a processor, such as a client of the network.
- Example processing associated with the non-browser application 301 was presented in detail above with reference to the method 200 of the FIG. 2 .
- the non-browser application 301 is configured to interact with a browser 303 to establish a secure communication session with the server 302 over the network.
- the non-browser application 301 is also configured to resupply a secret token (discussed below) to the server 302 independent of the browser 303 or any assistance of the browser 303 .
- This resupplied secret token initiates the secure communication session with the server 302 and the browser 303 is closed after this but the secure communication session continues and remains active between the non-browser application 301 and the server 302 .
- the secure communication session is a SSL VPN session with a secure communication tunnel established between the non-browser application 301 and the server 302 .
- the non-browser application 301 is configured to close the browser 303 once the secure communication session is successfully established between the non-browser application 301 and the server 302 .
- the browser 303 can also be manually closed by the user at any point desired by the user and the secure communication session continues unabated.
- the server 302 is configured to process over the network and interacts with the client of the non-browser application 301 .
- Example processing associated with the server 302 was provided in detail above with reference to the method 100 of the FIG. 1 . It is noted that the server 302 may also be a thick client acting as a server provider to other clients, such as the client that processes the non-browser application 301 . So, the server 302 can also be a thick client.
- the server 302 is configured to interact with the browser 303 to set a session cookie for the secure communication session.
- the server 302 is also configured to provide a secret token to the non-browser application 301 via the browser 303 .
- the secret token maps to the session cookie and that mapping is maintained by the server 302 .
- the server 302 is also configured to redirect the browser 303 to an identity service to authenticate a user of the non-browser application 301 for the secure communication session.
- the server 302 directs the browser 303 to set the session cookie within the browser 303 . This is done until the secret token is supplied and mapped by the server 302 to the session cookie in a manner that is independent of the browser 303 .
- the server 302 is configured to direct the non-browser application 301 to replace the secret token with a new session cookie after the secret token is supplied at least once from the non-browser application 301 .
- the non-browser application 301 is then further instructed to supply the new session cookie with all subsequent communication during the secure communication session with the server 302 .
- FIG. 4 is a diagram of an example flow interaction diagram for a secure communication session management system, according to an example embodiment.
- the user attempts to establish a secure tunnel between the workstation and the corporate server.
- the user is prompted to input his/her credentials and the user is authenticated.
- the secure tunnel is established and the browser is closed by the user.
- the secure tunnel continues to operate.
- the processing sequence depicted in the FIG. 4 is now presented to illustrate how this processing is achieved.
- the user wishes to establish the VPN tunnel to the server. He/she clicks the connect button on the EWC (Embedded Web Container) Client (non-browser application).
- EWC embedded Web Container
- Client non-browser application
- a parameter “myport” is appended here, so that the web browser knows at what port it can connect later on to the EWC client.
- the operating system opens the default web browser with the URL (uniform resource locator (URL) link).
- URL uniform resource locator
- SSL VPN Server forwards the request to the SSL VPN authentication service provider (SSLVPN Embedded Authentication Service Provider (ESP)).
- SSL VPN authentication service provider SSLVPN Embedded Authentication Service Provider (ESP)
- the ESP redirects the user to the Authentication provider (IDP—identity service).
- the IDP prompts the user for credentials if he/she is not authenticated already at the IDP. If browser has already been authenticated at this IDP, IDP does not force for credentials again. It performs a Single Sign On (SSO) operation and redirects the user back to the SSL VPN server.
- SSO Single Sign On
- CK 1 A cookie for the SSL VPN server and SSL VPN ESP domains.
- the cookies CK 1 (IDP) and CK 2 (SSL-VPN) are set on the browser and browser goes to the SSL VPN server with CK 1 .
- the SSL VPN server generates a secret token (ST) and associates this secret token with cookie CK 1 .
- HTTP Hypertext Transfer Protocol
- the browser loads the response, and the javascript connects to EWC @ localhost:4123 and passes the information about the secret token (ST).
- EWC connects to the SSL VPN server and authenticates itself by presenting the secret token (ST).
- SSL VPN Server recognizes the token and associates with the existing cookie CK 1 .
- a new cookie CK 3 is generated and a new association is established at the SSL VPN server between CK 1 and CK 3 .
- SSL VPN ESP When ever a request comes with CK 3 to the SSLVPN server, and if the server needs to communicate to SSL VPN ESP, it presents the cookie CK 1 in place of CK 3 .
- the SSL VPN server responds to EWC client with a 200 OK response with setcookie: CK 3 .
- the EWC receives the response, establishes the VPN tunnel with the server (the process of establishing the tunnel is not in the scope of this document). After establishing the connection, it responds to the browser that the tunnel has been established. The browser displays the successful message and either it closes its self, or it displays a message that the browser can be closed.
- the techniques presented herein provide a mechanism of using a browser only for cookie-based authentication and then transferring an authenticated session to a non-web browser application in a secure manner by using secure tokens. Moreover, a single authenticated session at two or more clients of a workstation can be achieved. The browser and the non-browser application can share the authentication of a single browser. A technique is also shown for securely translating the authenticated cookie into another authenticated cookie by means of a secure token in a single sign on fashion. The concept of dynamic replacement of CK 3 with CK 1 for all the cookie dependent applications on the SSL VPN server based on policy and secure tokens received.
- any e-commerce application which is a non-web browser
- the e-commerce application is a non-web browser based (for example a native client that implements web services).
- the authentication provider requires the presence of web browser as the client during authentication (For selecting an info card, or for displaying JSPs and for running JavaScripts).
- the non-web browser e-commerce application requires the single sign on to the server, where the browser from the same workstation has already been authenticated.
- One such scenario can be easily seen: a user accesses some information from an e-commerce website of a corporation using the web browser (he/she authenticates to the e-commerce server). The same user starts another application (non-web browser) and attempts to connect to the same corporation; since the corporation is using a single authentication provider, SSO is achieved for the non-web browser application.
Abstract
Description
- The web browser is the most ubiquitous and common application that exists today for communicating. Because of this reason, many Identity systems have developed their authentication model assuming the web browser to be their application that initiates authentication. Also, web browser cookies are the most common form of holding the identity of a session that is authenticated.
- As long as the cookie is alive at the browser, the authentication at the server is alive and the communication channels that depend on this authenticated session continue to perform their activities. A lot of authentication providers require the web browser to be the application requesting authentication because of the usage of info cards, smartcards, BasicAuth, need for running Java Server Pages (JSPs), JavaScripts and many other browser features.
- However, for certain non-web based applications (such as a Secure Socket Layer (SSL) Virtual Private Network (VPN)), keeping the browser open and alive may be annoying and users prefer to close the browser after authentication is done. This kind of a non-web application uses the server's web interface to gain authentication and access policy information. Users may also close the browser accidentally resulting in un-wanted disconnection of their non-web application. Also, the web browsers generally cannot be minimized to the system tray area.
- In various embodiments, techniques for managing a secure communication session are presented. More specifically, and in an embodiment, a method for managing a secure communication session is provided. A request for a secure communication session is detected; the secure communication session between a non-browser application and a server and the request initiated by the non-browser application. The secure communication session is established between the non-browser application and the server via a browser. Next, a session cookie that the browser uses with the secure communication session is mapped to a secure token and this secure token is transferred to the non-browser application in a secure fashion via the browser. Finally, the secure communication session is maintained after the browser is shut down by translating the secure token supplied by the non-browser application into the session cookie expected by the server for the secure communication session.
-
FIG. 1 is a diagram of a method for managing a secure communication session, according to an example embodiment. -
FIG. 2 is a diagram of another method for dynamically managing a secure communication session, according to an example embodiment. -
FIG. 3 is a diagram of a secure communication session management system, according to an example embodiment. -
FIG. 4 is a diagram of an example flow interaction diagram for a secure communication session management system, according to an example embodiment. - A “resource” includes a user, service, system, device, directory, data store, groups of users, combinations of these things, etc. A “principal” is a specific type of resource, such as an automated service or user that acquires an identity. A designation as to what is a resource and what is a principal can change depending upon the context of any given network transaction. Thus, if one resource attempts to access another resource, the actor of the transaction may be viewed as a principal.
- An “identity” is something that is formulated from one or more identifiers and secrets that provide a statement of roles and/or permissions that the identity has in relation to resources. An “identifier” is information, which may be private and permits an identity to be formed, and some portions of an identifier may be public information, such as a user identifier, name, etc. Some examples of identifiers include social security number (SSN), user identifier and password pair, account number, retina scan, fingerprint, face scan, etc.
- A “non-browser application” is a software service, system, and/or module that does not rely on and is not implemented within a browser. The non-browser application includes a web interface to interact with and communicate with a browser but does not require a browser and is not embedded within a browser.
- Various embodiments of this invention can be implemented in existing network architectures. For example, in some embodiments, the techniques presented herein are implemented in whole or in part in the Novell® operating system products, access management products, directory-based products and other products distributed by Novell®, Inc., of Waltham, Mass.
- Also, the techniques presented herein are implemented in machines, such as processor or processor-enabled devices. These machines are configured to specifically perform the processing of the methods and systems presented herein. Moreover, the methods and systems are implemented and reside within computer-readable storage media and processed on the machines configured to perform the methods.
- Of course, the embodiments of the invention can be implemented in a variety of architectural platforms, devices, operating and server systems, and/or applications. Any particular architectural layout or implementation presented herein is provided for purposes of illustration and comprehension only and is not intended to limit aspects of the invention.
- It is within this context that embodiments of the invention are now discussed within the context of
FIGS. 1-4 . -
FIG. 1 is a diagram of amethod 100 for managing a secure communication session, according to an example embodiment. The method 100 (hereinafter “server communication service”) is implemented in a machine-accessible and computer-readable medium and instructions that execute on one or more processors (machines, computers, processors, etc.). The machine, such as a server, is specifically configured to process the server communication service. Furthermore, the server communication service is operational over and processes within a network. The network may be wired, wireless, or a combination of wired and wireless. - According to an embodiment, the server communication service represents processing for a Secure Socket Layer (SSL) Virtual Private Network (VPN) (referred to as an SSL VPN) performed by a server.
- At 110, the server communication service detects a request for a secure communication session between a non-browser application and a server. The request is initiated by the non-browser application. A secure communication session is an authenticated communication session that can use encryption.
- For example, at 111, the server communication service identifies the request as a request for the secure communication session to a SSL VPN between the non-browser application and the server.
- At 120, the server communication service establishes the secure communication session between the non-browser application and the server via a browser. That is, a browser is used as an intermediary to initially establish the secure communication session. However, conventionally the browser needed to stay alive and active during the session between the non-browser application and the server; that is not the case with the techniques presented herein and below (as described more completely below).
- According to an embodiment, at 121, the server communication service authenticates the non-browser application via redirection of the browser to an identity service. The identity service performs authentication on behalf of the server. So, the server offloads authentication to a third-party, such as an identity service. The identity service is used to authenticate the non-browser application or a user of the non-browser application for access to the secure communication session and correspondingly the server.
- At 130, the server communication service maps a session cookie that the browser uses with the secure communication session to a secure token and then the server communication service instructs the browser to supply the secure token to the non-browser application.
- In an embodiment, at 131 and continuing with the embodiment of 121, the server communication service instructs the browser to set the session cookie supplied by the server and an authentication token supplied by the identity service within the browser. These can be set as two distinct cookies (a more complete explanation of this scenario is described in detail below with reference to the
FIG. 4 ). - In a scenario, at 132 and after the browser supplies the token to the non browser application, the server communication service instructs the browser to shut down and close; again, this is after the secure token is supplied or successfully provided to the non-browser application.
- At 140, the server communication service maintains the secure communication session after the browser is shut down or closed. This is done by the server communication service translating the secure token supplied by the non-browser application into the session cookie expected by the server. So, the server maintains and recognizes the session cookie but the browser closed at this point in time. So, the server communication service maintains the session cookie and its mapping to the secure token and when the secure token is supplied by the non-browser application, the server communication service translates the secure token to the session cookie and provides that to the server so the secure communication session continues unabated even without the presence of the browser. This can also be done by re-forming the secure communication session with the session cookie. Conventionally, this could not be achieved as the browser had to remain active to supply the session cookie or the secure session was lost.
- According to an embodiment, at 141, the server communication service logs the non-browser application into the secure communication session after the browser is shut down using the secure token.
- Continuing with the embodiment of 141 and at 142, the server communication service instructs the non-browser application to use a new session cookie in place of the secure token for communications after logging into the secure communication session. The new session cookie mapped to the original session cookie and the new session cookie supplied to the server each time the non-browser application communicates during the secure communication session with the new session cookie.
-
FIG. 2 is a diagram of anothermethod 200 for dynamically managing a secure communication session, according to an example embodiment. The method 200 (hereinafter “client communication service”) is implemented in a machine-accessible and computer-readable storage medium as instructions that execute on one or more processors of a network. The network may be wired, wireless, or a combination of wired and wireless. Furthermore, the processor, such as a client, (device having a processing instance of the client communication service) is specifically configured to process the client communication service. - The client communication service is a non-browser application. That is, the client communication service is not browser based and executes independent of a browser.
- The server communication service represented by the
method 100 of theFIG. 1 provides processing from the perspective of a server, whereas the client communication service represents processing that occurs on a client and that occurs outside a browser of the client. - At 210, the client communication service requests a SSL VPN connection with a server. The request for the SSL VPN connection is made to a browser or intercepted and initially handled by the browser on behalf of the client communication service.
- According to an embodiment, at 211, the client communication service generates the request in response to an action of a user. That is, the user activates a request to connect to the server and in response to that an URL link is constructed as the request and the browser initiates to assist in establishing the SSL VPN connection with the server.
- In another case, at 212, the client communication service interacts with a user via the browser to authenticate the user to an identity service for the SSL VPN connection.
- At 220, the client communication service receives a secret token from the browser. The browser acquired the secret token as part of a mapping to a session cookie for the SSL VPN connection from the server. The details of this mapping was provided above with reference to the
method 100 of theFIG. 1 . - At 230, the client communication service supplies the secret token directly back to the server for purposes of initially logging into and establishing the SSL VPN connection with the server.
- In an embodiment, at 231, the client communication service receives from the server a new cookie. The new cookie is to replace the secret token after the SSL VPN connection is initially established via the secure token.
- Continuing with the embodiment of 231 and at 232, the client communication service supplies the new session cookie for each communication with the server during the SSL VPN connection. The
method 100 of theFIG. 1 translates the new session cookie into the original session cookie to maintain the SSL VPN connection with the server for the client communication service. - At 240, the client communication service shuts down the browser while maintaining the SSL VPN connection with the service. This is done via the secure token that the server translates to the session cookie so that the SSL VPN connection remains active. So, the SSL VPN connection remains active and valid after the browser is closed or shut down and is non-operational on the client.
- In one case, at 241, the client communication service shuts down the browser based on a manual instruction from the user to close the browser. So, the user may be given a notice that the user can shut the browser down if desired. The decision or action to shut the browser down rests with the user in this scenario.
- In an alternative configuration, at 242, the client communication service automatically shuts down the browser once the SSL VPN connection is established via the secret token.
- A profile associated with the client communication service or a user can be used to decide whether the user is given control to shut the browser or down or whether the browser is automatically shut down. It is noted that the browser does not have to be shut down but when the browser is shut down the SSL VPN connection is not lost.
-
FIG. 3 is a diagram of a secure communicationsession management system 300, according to an example embodiment. The secure communicationsession management system 300 is implemented in a machine-accessible and computer-readable storage medium as instructions that execute on one or more processors (multiprocessor) and that is operational over a network. The one or more processors are specifically configured to process the components of the secure communicationsession management system 300. Moreover, the network may be wired, wireless, or a combination of wired and wireless. In an embodiment, the secure communicationsession management system 300 implements, inter alia, certain aspects of themethods FIGS. 1 and 2 , respectively. - The secure communication
session management system 300 includes anon-browser application 301 and aserver 302. Each of these and their interactions with one another will now be discussed in turn. - The
non-browser application 301 is implemented in a computer-readable storage medium (non-transitory) and executes on a processor, such as a client of the network. Example processing associated with thenon-browser application 301 was presented in detail above with reference to themethod 200 of theFIG. 2 . - The
non-browser application 301 is configured to interact with abrowser 303 to establish a secure communication session with theserver 302 over the network. - The
non-browser application 301 is also configured to resupply a secret token (discussed below) to theserver 302 independent of thebrowser 303 or any assistance of thebrowser 303. This resupplied secret token initiates the secure communication session with theserver 302 and thebrowser 303 is closed after this but the secure communication session continues and remains active between thenon-browser application 301 and theserver 302. - In an embodiment, the secure communication session is a SSL VPN session with a secure communication tunnel established between the
non-browser application 301 and theserver 302. - According to an embodiment, the
non-browser application 301 is configured to close thebrowser 303 once the secure communication session is successfully established between thenon-browser application 301 and theserver 302. As noted above, thebrowser 303 can also be manually closed by the user at any point desired by the user and the secure communication session continues unabated. - The
server 302 is configured to process over the network and interacts with the client of thenon-browser application 301. Example processing associated with theserver 302 was provided in detail above with reference to themethod 100 of theFIG. 1 . It is noted that theserver 302 may also be a thick client acting as a server provider to other clients, such as the client that processes thenon-browser application 301. So, theserver 302 can also be a thick client. - The
server 302 is configured to interact with thebrowser 303 to set a session cookie for the secure communication session. Theserver 302 is also configured to provide a secret token to thenon-browser application 301 via thebrowser 303. The secret token maps to the session cookie and that mapping is maintained by theserver 302. - According to an embodiment, the
server 302 is also configured to redirect thebrowser 303 to an identity service to authenticate a user of thenon-browser application 301 for the secure communication session. - Also, the
server 302 directs thebrowser 303 to set the session cookie within thebrowser 303. This is done until the secret token is supplied and mapped by theserver 302 to the session cookie in a manner that is independent of thebrowser 303. - In another scenario, the
server 302 is configured to direct thenon-browser application 301 to replace the secret token with a new session cookie after the secret token is supplied at least once from thenon-browser application 301. Thenon-browser application 301 is then further instructed to supply the new session cookie with all subsequent communication during the secure communication session with theserver 302. -
FIG. 4 is a diagram of an example flow interaction diagram for a secure communication session management system, according to an example embodiment. - The user attempts to establish a secure tunnel between the workstation and the corporate server. The user is prompted to input his/her credentials and the user is authenticated. After the authentication, the secure tunnel is established and the browser is closed by the user. After closing the browser, the secure tunnel continues to operate. The processing sequence depicted in the
FIG. 4 is now presented to illustrate how this processing is achieved. - 1. The user wishes to establish the VPN tunnel to the server. He/she clicks the connect button on the EWC (Embedded Web Container) Client (non-browser application).
- 2. The details under this processing item are provided for the purpose of better understanding of the flow; other arrangements are conceivable without departing from the teachings presented herein.
- The click action of the user generates an action url://www.sslvpn.com/login?myport=4123. A parameter “myport” is appended here, so that the web browser knows at what port it can connect later on to the EWC client. The operating system opens the default web browser with the URL (uniform resource locator (URL) link).
- The web browser opens up the URL and connects to the SSL VPN Server. As this is not an authenticated session, SSL VPN Server, forwards the request to the SSL VPN authentication service provider (SSLVPN Embedded Authentication Service Provider (ESP)). The ESP redirects the user to the Authentication provider (IDP—identity service).
- The IDP prompts the user for credentials if he/she is not authenticated already at the IDP. If browser has already been authenticated at this IDP, IDP does not force for credentials again. It performs a Single Sign On (SSO) operation and redirects the user back to the SSL VPN server.
- While the above actions have happened, the following cookies are generated on the server and set on the browser:
- CK1. A cookie for the SSL VPN server and SSL VPN ESP domains.
- CK2. A cookie for the IDP domain.
- 3. The cookies CK1 (IDP) and CK2 (SSL-VPN) are set on the browser and browser goes to the SSL VPN server with CK1.
- 4. At this point the SSL VPN server generates a secret token (ST) and associates this secret token with cookie CK1.
- 5. The Hypertext Transfer Protocol (HTTP) response to the browser contains the following:
-
- A javascript page that can connect to the EWC on the local host, and pass the secret cookie information.
- The port at which the javascript can connect on the local host. In this
example port 4123 was originally passed from the EWC client.
- 6. The browser loads the response, and the javascript connects to EWC @ localhost:4123 and passes the information about the secret token (ST).
- 7. EWC connects to the SSL VPN server and authenticates itself by presenting the secret token (ST).
- 8. SSL VPN Server recognizes the token and associates with the existing cookie CK1. A new cookie CK3 is generated and a new association is established at the SSL VPN server between CK1 and CK3. When ever a request comes with CK3 to the SSLVPN server, and if the server needs to communicate to SSL VPN ESP, it presents the cookie CK1 in place of CK3.
- 9. The SSL VPN server responds to EWC client with a 200 OK response with setcookie: CK3.
- 10. The EWC receives the response, establishes the VPN tunnel with the server (the process of establishing the tunnel is not in the scope of this document). After establishing the connection, it responds to the browser that the tunnel has been established. The browser displays the successful message and either it closes its self, or it displays a message that the browser can be closed.
- The techniques presented herein provide a mechanism of using a browser only for cookie-based authentication and then transferring an authenticated session to a non-web browser application in a secure manner by using secure tokens. Moreover, a single authenticated session at two or more clients of a workstation can be achieved. The browser and the non-browser application can share the authentication of a single browser. A technique is also shown for securely translating the authenticated cookie into another authenticated cookie by means of a secure token in a single sign on fashion. The concept of dynamic replacement of CK3 with CK1 for all the cookie dependent applications on the SSL VPN server based on policy and secure tokens received. Even though the user started his/her authentication at a non-web browser application, if the web browser has already authenticated at the authentication provider, the user achieves a seamless single sign on at the client by reusing the browser session with an identity service. This concept itself is very unique.
- It is also noted that the techniques provided herein can be applied to any e-commerce application, which is a non-web browser, where the e-commerce application is a non-web browser based (for example a native client that implements web services). The authentication provider requires the presence of web browser as the client during authentication (For selecting an info card, or for displaying JSPs and for running JavaScripts). The non-web browser e-commerce application requires the single sign on to the server, where the browser from the same workstation has already been authenticated. One such scenario can be easily seen: a user accesses some information from an e-commerce website of a corporation using the web browser (he/she authenticates to the e-commerce server). The same user starts another application (non-web browser) and attempts to connect to the same corporation; since the corporation is using a single authentication provider, SSO is achieved for the non-web browser application.
- The above description is illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of embodiments should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
- The Abstract is provided to comply with 37 C.F.R. §1.72(b) and will allow the reader to quickly ascertain the nature and gist of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.
- In the foregoing description of the embodiments, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting that the claimed embodiments have more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Description of the Embodiments, with each claim standing on its own as a separate exemplary embodiment.
Claims (20)
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/714,451 US8799640B2 (en) | 2010-02-27 | 2010-02-27 | Techniques for managing a secure communication session |
EP11153259.4A EP2362602B1 (en) | 2010-02-27 | 2011-02-03 | Techniques for managing a secure communication session |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/714,451 US8799640B2 (en) | 2010-02-27 | 2010-02-27 | Techniques for managing a secure communication session |
Publications (2)
Publication Number | Publication Date |
---|---|
US20110213956A1 true US20110213956A1 (en) | 2011-09-01 |
US8799640B2 US8799640B2 (en) | 2014-08-05 |
Family
ID=44148570
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/714,451 Expired - Fee Related US8799640B2 (en) | 2010-02-27 | 2010-02-27 | Techniques for managing a secure communication session |
Country Status (2)
Country | Link |
---|---|
US (1) | US8799640B2 (en) |
EP (1) | EP2362602B1 (en) |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8701199B1 (en) * | 2011-12-23 | 2014-04-15 | Emc Corporation | Establishing a trusted session from a non-web client using adaptive authentication |
US20150121462A1 (en) * | 2013-10-24 | 2015-04-30 | Google Inc. | Identity application programming interface |
US9117061B1 (en) * | 2011-07-05 | 2015-08-25 | Symantec Corporation | Techniques for securing authentication credentials on a client device during submission in browser-based cloud applications |
US20160021204A1 (en) * | 2012-06-11 | 2016-01-21 | The Nielsen Company (Us), Llc | Methods and apparatus to share online media impressions data |
US20160112402A1 (en) * | 2014-10-21 | 2016-04-21 | Microsoft Technology Licensing, Llc. | Single Sign-on via Application or Browser |
WO2016145116A1 (en) * | 2015-03-09 | 2016-09-15 | Neustar, Inc. | System and method for secure device authentication |
US9578111B2 (en) | 2012-06-08 | 2017-02-21 | International Business Machines Corporation | Enabling different client contexts to share session information |
US20170331815A1 (en) * | 2016-05-13 | 2017-11-16 | MobileIron, Inc. | Unified vpn and identity based authentication to cloud-based services |
US20190028895A1 (en) * | 2015-11-12 | 2019-01-24 | Finjan Mobile, Inc. | Authorization of authentication |
US10505920B2 (en) | 2017-11-30 | 2019-12-10 | Mocana Corporation | System and method of device identification for enrollment and registration of a connected endpoint device, and blockchain service |
US10523660B1 (en) | 2016-05-13 | 2019-12-31 | MobileIron, Inc. | Asserting a mobile identity to users and devices in an enterprise authentication system |
WO2021231065A1 (en) * | 2020-05-11 | 2021-11-18 | Citrix Systems, Inc. | Local authentication virtual authorization |
US11546310B2 (en) * | 2018-01-26 | 2023-01-03 | Sensus Spectrum, Llc | Apparatus, methods and articles of manufacture for messaging using message level security |
US11595217B2 (en) | 2018-12-06 | 2023-02-28 | Digicert, Inc. | System and method for zero touch provisioning of IoT devices |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106961420B (en) * | 2013-11-08 | 2021-04-02 | 北京奇虎科技有限公司 | Cookie information processing method and device |
US20150294346A1 (en) * | 2014-04-09 | 2015-10-15 | Valassis Communications, Inc. | State information session token |
CN112788073A (en) * | 2019-11-06 | 2021-05-11 | 广州凡科互联网科技股份有限公司 | Novel Cookie processing method for non-browser end |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7032110B1 (en) * | 2000-06-30 | 2006-04-18 | Landesk Software Limited | PKI-based client/server authentication |
US7065507B2 (en) * | 2001-03-26 | 2006-06-20 | Microsoft Corporation | Supervised license acquisition in a digital rights management system on a computing device |
US20070245409A1 (en) * | 2006-04-12 | 2007-10-18 | James Harris | Systems and Methods for Providing Levels of Access and Action Control Via an SSL VPN Appliance |
US20090025080A1 (en) * | 2006-09-27 | 2009-01-22 | Craig Lund | System and method for authenticating a client to a server via an ipsec vpn and facilitating a secure migration to ssl vpn remote access |
US20090037998A1 (en) * | 2007-08-03 | 2009-02-05 | Saibal Adhya | Systems and Methods for Authorizing a Client in an SSL VPN Session Failover Environment |
US20090199285A1 (en) * | 2008-01-26 | 2009-08-06 | Puneet Agarwal | Systems and Methods for For Proxying Cookies for SSL VPN Clientless Sessions |
US7631084B2 (en) * | 2001-11-02 | 2009-12-08 | Juniper Networks, Inc. | Method and system for providing secure access to private networks with client redirection |
US7930732B2 (en) * | 2008-02-22 | 2011-04-19 | Novell, Inc. | Techniques for secure transparent switching between modes of a virtual private network (VPN) |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7725737B2 (en) * | 2005-10-14 | 2010-05-25 | Check Point Software Technologies, Inc. | System and methodology providing secure workspace environment |
-
2010
- 2010-02-27 US US12/714,451 patent/US8799640B2/en not_active Expired - Fee Related
-
2011
- 2011-02-03 EP EP11153259.4A patent/EP2362602B1/en not_active Not-in-force
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7032110B1 (en) * | 2000-06-30 | 2006-04-18 | Landesk Software Limited | PKI-based client/server authentication |
US7065507B2 (en) * | 2001-03-26 | 2006-06-20 | Microsoft Corporation | Supervised license acquisition in a digital rights management system on a computing device |
US7631084B2 (en) * | 2001-11-02 | 2009-12-08 | Juniper Networks, Inc. | Method and system for providing secure access to private networks with client redirection |
US20070245409A1 (en) * | 2006-04-12 | 2007-10-18 | James Harris | Systems and Methods for Providing Levels of Access and Action Control Via an SSL VPN Appliance |
US20090025080A1 (en) * | 2006-09-27 | 2009-01-22 | Craig Lund | System and method for authenticating a client to a server via an ipsec vpn and facilitating a secure migration to ssl vpn remote access |
US20090037998A1 (en) * | 2007-08-03 | 2009-02-05 | Saibal Adhya | Systems and Methods for Authorizing a Client in an SSL VPN Session Failover Environment |
US20090199285A1 (en) * | 2008-01-26 | 2009-08-06 | Puneet Agarwal | Systems and Methods for For Proxying Cookies for SSL VPN Clientless Sessions |
US8090877B2 (en) * | 2008-01-26 | 2012-01-03 | Citrix Systems, Inc. | Systems and methods for fine grain policy driven cookie proxying |
US7930732B2 (en) * | 2008-02-22 | 2011-04-19 | Novell, Inc. | Techniques for secure transparent switching between modes of a virtual private network (VPN) |
Non-Patent Citations (2)
Title |
---|
Java WS Core (Developer's Guide, DRAFT, 07/2008) * |
Juniper Networks Secure Access Administration Guide, Release 5.5Writers: Paul Battaglia, Gary Beichler, Claudette Hobbart, Mark SmallwoodEditor: Claudette HobbartCopyright © 2006, Juniper Networks, Inc.Part Number: 55A031207http://www.juniper.net/techpubs/software/ive/admin/5.5-IVEAdminGuide.pdf * |
Cited By (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9117061B1 (en) * | 2011-07-05 | 2015-08-25 | Symantec Corporation | Techniques for securing authentication credentials on a client device during submission in browser-based cloud applications |
US8701199B1 (en) * | 2011-12-23 | 2014-04-15 | Emc Corporation | Establishing a trusted session from a non-web client using adaptive authentication |
US9578111B2 (en) | 2012-06-08 | 2017-02-21 | International Business Machines Corporation | Enabling different client contexts to share session information |
US11356521B2 (en) | 2012-06-11 | 2022-06-07 | The Nielsen Company (Us), Llc | Methods and apparatus to share online media impressions data |
US20160021204A1 (en) * | 2012-06-11 | 2016-01-21 | The Nielsen Company (Us), Llc | Methods and apparatus to share online media impressions data |
US10536543B2 (en) | 2012-06-11 | 2020-01-14 | The Nielsen Company (Us), Llc | Methods and apparatus to share online media impressions data |
US10027773B2 (en) * | 2012-06-11 | 2018-07-17 | The Nielson Company (Us), Llc | Methods and apparatus to share online media impressions data |
US20150121462A1 (en) * | 2013-10-24 | 2015-04-30 | Google Inc. | Identity application programming interface |
US20160112402A1 (en) * | 2014-10-21 | 2016-04-21 | Microsoft Technology Licensing, Llc. | Single Sign-on via Application or Browser |
US9531703B2 (en) * | 2014-10-21 | 2016-12-27 | Microsoft Technology Licensing, Llc | Single sign-on via application or browser |
WO2016145116A1 (en) * | 2015-03-09 | 2016-09-15 | Neustar, Inc. | System and method for secure device authentication |
US9706402B2 (en) | 2015-03-09 | 2017-07-11 | Neustar, Inc. | System and method for secure device authentication |
US20190028895A1 (en) * | 2015-11-12 | 2019-01-24 | Finjan Mobile, Inc. | Authorization of authentication |
US10623958B2 (en) * | 2015-11-12 | 2020-04-14 | Finjan Mobile, Inc. | Authorization of authentication |
US11178132B2 (en) | 2016-05-13 | 2021-11-16 | MobileIron, Inc. | Unified VPN and identity based authentication to cloud-based services |
US10523660B1 (en) | 2016-05-13 | 2019-12-31 | MobileIron, Inc. | Asserting a mobile identity to users and devices in an enterprise authentication system |
US10673838B2 (en) * | 2016-05-13 | 2020-06-02 | MobileIron, Inc. | Unified VPN and identity based authentication to cloud-based services |
US20170331815A1 (en) * | 2016-05-13 | 2017-11-16 | MobileIron, Inc. | Unified vpn and identity based authentication to cloud-based services |
US11368449B2 (en) | 2016-05-13 | 2022-06-21 | Mobileiron Inc. | Asserting a mobile identity to users and devices in an enterprise authentication system |
US10979419B2 (en) | 2017-11-30 | 2021-04-13 | Mocana Corporation | System and method of device identification for enrollment and registration of a connected endpoint device, and blockchain service |
US10505920B2 (en) | 2017-11-30 | 2019-12-10 | Mocana Corporation | System and method of device identification for enrollment and registration of a connected endpoint device, and blockchain service |
US11546310B2 (en) * | 2018-01-26 | 2023-01-03 | Sensus Spectrum, Llc | Apparatus, methods and articles of manufacture for messaging using message level security |
US11595217B2 (en) | 2018-12-06 | 2023-02-28 | Digicert, Inc. | System and method for zero touch provisioning of IoT devices |
WO2021231065A1 (en) * | 2020-05-11 | 2021-11-18 | Citrix Systems, Inc. | Local authentication virtual authorization |
Also Published As
Publication number | Publication date |
---|---|
US8799640B2 (en) | 2014-08-05 |
EP2362602B1 (en) | 2014-09-17 |
EP2362602A1 (en) | 2011-08-31 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8799640B2 (en) | Techniques for managing a secure communication session | |
US10904262B2 (en) | Graduated authentication in an identity management system | |
US10230725B2 (en) | Edge protection for internal identity providers | |
US9894055B2 (en) | Redirect to inspection proxy using single-sign-on bootstrapping | |
US8984621B2 (en) | Techniques for secure access management in virtual environments | |
US9473480B2 (en) | Controlled access | |
CA2775206C (en) | System and method of handling requests in a multi-homed reverse proxy | |
US8504704B2 (en) | Distributed contact information management | |
US20160044124A1 (en) | Network traffic monitoring system and method to redirect network traffic through a network intermediary | |
EP3117578B1 (en) | Disposition engine for single sign on (sso) requests | |
US8832857B2 (en) | Unsecured asset detection via correlated authentication anomalies | |
US8250633B2 (en) | Techniques for flexible resource authentication | |
US8738897B2 (en) | Single sign-on functionality for secure communications over insecure networks | |
US20140298413A1 (en) | Mapping the Network File System (NFS) protocol to secure web-based applications | |
CN107395566B (en) | Authentication method and device | |
US20230195914A1 (en) | Method for proving device identity to security brokers |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: NOVELL, INC., UTAH Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MUKKARA, PRAKASH UMASANKAR;BURCH, LLOYD LEON;SIGNING DATES FROM 20100225 TO 20100227;REEL/FRAME:024009/0655 |
|
AS | Assignment |
Owner name: CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH, NEW YORK Free format text: GRANT OF PATENT SECURITY INTEREST;ASSIGNOR:NOVELL, INC.;REEL/FRAME:026270/0001 Effective date: 20110427 |
|
AS | Assignment |
Owner name: CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH, NEW YORK Free format text: GRANT OF PATENT SECURITY INTEREST (SECOND LIEN);ASSIGNOR:NOVELL, INC.;REEL/FRAME:026275/0018 Effective date: 20110427 |
|
AS | Assignment |
Owner name: NOVELL, INC., UTAH Free format text: RELEASE OF SECURITY INTEREST IN PATENTS FIRST LIEN (RELEASES RF 026270/0001 AND 027289/0727);ASSIGNOR:CREDIT SUISSE AG, AS COLLATERAL AGENT;REEL/FRAME:028252/0077 Effective date: 20120522 Owner name: NOVELL, INC., UTAH Free format text: RELEASE OF SECURITY IN PATENTS SECOND LIEN (RELEASES RF 026275/0018 AND 027290/0983);ASSIGNOR:CREDIT SUISSE AG, AS COLLATERAL AGENT;REEL/FRAME:028252/0154 Effective date: 20120522 |
|
AS | Assignment |
Owner name: CREDIT SUISSE AG, AS COLLATERAL AGENT, NEW YORK Free format text: GRANT OF PATENT SECURITY INTEREST FIRST LIEN;ASSIGNOR:NOVELL, INC.;REEL/FRAME:028252/0216 Effective date: 20120522 Owner name: CREDIT SUISSE AG, AS COLLATERAL AGENT, NEW YORK Free format text: GRANT OF PATENT SECURITY INTEREST SECOND LIEN;ASSIGNOR:NOVELL, INC.;REEL/FRAME:028252/0316 Effective date: 20120522 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
CC | Certificate of correction | ||
AS | Assignment |
Owner name: NOVELL, INC., UTAH Free format text: RELEASE OF SECURITY INTEREST RECORDED AT REEL/FRAME 028252/0316;ASSIGNOR:CREDIT SUISSE AG;REEL/FRAME:034469/0057 Effective date: 20141120 Owner name: NOVELL, INC., UTAH Free format text: RELEASE OF SECURITY INTEREST RECORDED AT REEL/FRAME 028252/0216;ASSIGNOR:CREDIT SUISSE AG;REEL/FRAME:034470/0680 Effective date: 20141120 |
|
AS | Assignment |
Owner name: BANK OF AMERICA, N.A., CALIFORNIA Free format text: SECURITY INTEREST;ASSIGNORS:MICRO FOCUS (US), INC.;BORLAND SOFTWARE CORPORATION;ATTACHMATE CORPORATION;AND OTHERS;REEL/FRAME:035656/0251 Effective date: 20141120 |
|
AS | Assignment |
Owner name: MICRO FOCUS SOFTWARE INC., DELAWARE Free format text: CHANGE OF NAME;ASSIGNOR:NOVELL, INC.;REEL/FRAME:040020/0703 Effective date: 20160718 |
|
AS | Assignment |
Owner name: JPMORGAN CHASE BANK, N.A., AS SUCCESSOR AGENT, NEW Free format text: NOTICE OF SUCCESSION OF AGENCY;ASSIGNOR:BANK OF AMERICA, N.A., AS PRIOR AGENT;REEL/FRAME:042388/0386 Effective date: 20170501 |
|
AS | Assignment |
Owner name: JPMORGAN CHASE BANK, N.A., DELAWARE Free format text: SECURITY INTEREST;ASSIGNORS:ATTACHMATE CORPORATION;BORLAND SOFTWARE CORPORATION;NETIQ CORPORATION;AND OTHERS;REEL/FRAME:044183/0718 Effective date: 20170901 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.) |
|
AS | Assignment |
Owner name: JPMORGAN CHASE BANK, N.A., AS SUCCESSOR AGENT, NEW Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE TO CORRECT TYPO IN APPLICATION NUMBER 10708121 WHICH SHOULD BE 10708021 PREVIOUSLY RECORDED ON REEL 042388 FRAME 0386. ASSIGNOR(S) HEREBY CONFIRMS THE NOTICE OF SUCCESSION OF AGENCY;ASSIGNOR:BANK OF AMERICA, N.A., AS PRIOR AGENT;REEL/FRAME:048793/0832 Effective date: 20170501 |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20180805 |
|
AS | Assignment |
Owner name: NETIQ CORPORATION, WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: MICRO FOCUS SOFTWARE INC. (F/K/A NOVELL, INC.), WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: ATTACHMATE CORPORATION, WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: SERENA SOFTWARE, INC, CALIFORNIA Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: MICRO FOCUS (US), INC., MARYLAND Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: BORLAND SOFTWARE CORPORATION, MARYLAND Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: MICRO FOCUS LLC (F/K/A ENTIT SOFTWARE LLC), CALIFORNIA Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: MICRO FOCUS SOFTWARE INC. (F/K/A NOVELL, INC.), WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 035656/0251;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062623/0009 Effective date: 20230131 Owner name: MICRO FOCUS (US), INC., MARYLAND Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 035656/0251;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062623/0009 Effective date: 20230131 Owner name: NETIQ CORPORATION, WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 035656/0251;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062623/0009 Effective date: 20230131 Owner name: ATTACHMATE CORPORATION, WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 035656/0251;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062623/0009 Effective date: 20230131 Owner name: BORLAND SOFTWARE CORPORATION, MARYLAND Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 035656/0251;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062623/0009 Effective date: 20230131 |