Abstract: A client request message is received at a policy enforcement system from a client-side application intended for a server-side application. The client request message is forwarded to a server-side application. An application response message from the server-side application is intercepted at the policy enforcement system in response to the client request message, resulting in an intercepted application response message. The intercepted application response message is analyzed in view of context information and a network policy. Code to inject into the intercepted application response message is determined based on the analyzing. The code has instructions for eliminating accumulation of stale computing sessions. The code is injected into the intercepted application response message, resulting in a modified message. The modified message is forwarded to the client-side application for automatically executing the instructions on the client-side application.

Abstract: A client request message is received at a policy enforcement system from a client-side application intended for a server-side application. The client request message is forwarded to a server-side application. An application response message from the server-side application is intercepted at the policy enforcement system in response to the client request message, resulting in an intercepted application response message. The intercepted application response message is analyzed in view of context information and a network policy. Code to inject into the intercepted application response message is determined based on the analyzing. The code has instructions for eliminating accumulation of stale computing sessions. The code is injected into the intercepted application response message, resulting in a modified message. The modified message is forwarded to the client-side application for automatically executing the instructions on the client-side application.

Abstract: An example method facilitates dynamic runtime execution of computer code that is selectively injected into messages in accordance with predetermined configuration rules for automatic execution at a message destination. The injection of code into messages, such as messages exchanged during an authenticated computing session, by a policy enforcement system, can be used to efficiently effectuate enhance computing environment security and computing resource use. For example, in a specific embodiment, code for detecting a browser-close event and then terminating a computing session can be automatically executed client side via a browser extension or plugin, thereby helping to eliminate the accumulation of stale computing sessions; thereby mitigating associated security risks and computing resource consumption of stale computing sessions. In another example embodiment, injected code encrypts session cookies, such as via a Time based One Time Password (TOTP).

Abstract: Techniques for securing user sessions using a time-based one-time password (TOTP) generated from a shared secret. The shared secret can be a cryptographic hash of one or more user credentials. In response to a successful authentication based on the user credential(s), a session is created. The authentication is performed in connection with an initial access request from a client application. A subsequent access request for a protected resource during the session is processed by extracting a session cookie and a TOTP and generating a corresponding TOTP using the shared secret. The TOTP can be generated by combining the shared secret with one or more additional parameters such as a Uniform Resource Locator associated with the resource, or the session cookie. Access to the protected resource is conditioned upon the session, which is identified by the session cookie, being valid and upon the TOTPs matching.

Abstract: Techniques for described for generating session-related timeout parameters that are user-specific in value. A user-specific timeout parameter offers several advantages over a static timeout parameter, including minimized the risk of session hijacking, fewer stale sessions to manage, and timeout parameters that more closely match the user's actual behavior. A value for a timeout parameter can therefore depend on information stored for a specific user. The stored information can indicate user behavior observed over a period of time encompassing multiple sessions and/or multiple accesses to the same or different resources. In certain embodiments, a value for a timeout parameter is determined by a prediction engine implemented using a machine learning (ML) model. The ML model may determine the timeout parameter based on information obtained records associated with the user for whom the timeout parameter value is being determined, as well as information from records associated with other users.

Abstract: An example method facilitates dynamic runtime execution of computer code that is selectively injected into messages in accordance with predetermined configuration rules for automatic execution at a message destination. The injection of code into messages, such as messages exchanged during an authenticated computing session, by a policy enforcement system, can be used to efficiently effectuate enhance computing environment security and computing resource use. For example, in a specific embodiment, code for detecting a browser-close event and then terminating a computing session can be automatically executed client side via a browser extension or plugin, thereby helping to eliminate the accumulation of stale computing sessions; thereby mitigating associated security risks and computing resource consumption of stale computing sessions. In another example embodiment, injected code encrypts session cookies, such as via a Time based One Time Password (TOTP).

Abstract: Techniques for described for generating session-related timeout parameters that are user-specific in value. A user-specific timeout parameter offers several advantages over a static timeout parameter, including minimized the risk of session hijacking, fewer stale sessions to manage, and timeout parameters that more closely match the user's actual behavior. A value for a timeout parameter can therefore depend on information stored for a specific user. The stored information can indicate user behavior observed over a period of time encompassing multiple sessions and/or multiple accesses to the same or different resources. In certain embodiments, a value for a timeout parameter is determined by a prediction engine implemented using a machine learning (ML) model. The ML model may determine the timeout parameter based on information obtained records associated with the user for whom the timeout parameter value is being determined, as well as information from records associated with other users.

Abstract: Techniques for transaction-specific authentication. An access manager receives information for a transaction. The information can be received in an authentication request from an application that is to perform the transaction or received as part of a transaction request. The information identifies an attribute associated with the transaction and includes a value for the attribute. The access manager uses the value to generate a first one-time password (OTP). The first OTP is compared to a second OTP received from a client device of a user who requested the transaction. Matching of the first OTP and the second OTP indicates that the value received in the information for the transaction matches a value provided by the user to the client device. Based on determining that the first OTP matches the second OTP, the access manager transmits an indication to the application that the user is successfully authenticated for the transaction.

Abstract: Techniques for securing user sessions using a time-based one-time password (TOTP) generated from a shared secret. The shared secret can be a cryptographic hash of one or more user credentials. In response to a successful authentication based on the user credential(s), a session is created. The authentication is performed in connection with an initial access request from a client application. A subsequent access request for a protected resource during the session is processed by extracting a session cookie and a TOTP and generating a corresponding TOTP using the shared secret. The TOTP can be generated by combining the shared secret with one or more additional parameters such as a Uniform Resource Locator associated with the resource, or the session cookie. Access to the protected resource is conditioned upon the session, which is identified by the session cookie, being valid and upon the TOTPs matching.

Abstract: Techniques for transaction-specific authentication. An access manager receives information for a transaction. The information can be received in an authentication request from an application that is to perform the transaction or received as part of a transaction request. The information identifies an attribute associated with the transaction and includes a value for the attribute. The access manager uses the value to generate a first one-time password (OTP). The first OTP is compared to a second OTP received from a client device of a user who requested the transaction. Matching of the first OTP and the second OTP indicates that the value received in the information for the transaction matches a value provided by the user to the client device. Based on determining that the first OTP matches the second OTP, the access manager transmits an indication to the application that the user is successfully authenticated for the transaction.

Abstract: Techniques are disclosed for providing and/or implementing utilizing declarative techniques for transaction-specific authentication. Certain techniques are disclosed herein that enable transaction signing using modular authentication via declarative requests from applications. An application can declaratively specify one or more transaction factor values to be used in an authentication, and the authentication, using a transaction-signed one-time password, can be directed by an access manager module without further involvement of the application. Upon a successful or non-successful authentication, the access manager module can provide the result back to the application. Accordingly, an authentication process specific to (and valid only for) a particular transaction can be performed without direct involvement of the application and without application-centric knowledge required by the access manager module.

Abstract: Techniques are disclosed for providing and/or implementing utilizing declarative techniques for transaction-specific authentication. Certain techniques are disclosed herein that enable transaction signing using modular authentication via declarative requests from applications. An application can declaratively specify one or more transaction factor values to be used in an authentication, and the authentication, using a transaction-signed one-time password, can be directed by an access manager module without further involvement of the application. Upon a successful or non-successful authentication, the access manager module can provide the result back to the application. Accordingly, an authentication process specific to (and valid only for) a particular transaction can be performed without direct involvement of the application and without application-centric knowledge required by the access manager module.