Abstract: In an approach to enforcing EULA version aware application response, responsive to receiving a request from a user to access an application, details of an End User License Agreement (EULA) are sent to the application. A response is received from the application based on the details of the EULA. A message is sent to the user, where the message contains the response from the application.

Abstract: In an approach for autonomous claim requirements discovery of APIs, a processor receives an access request from a client to a server. A processor validates the access request. A processor queries claim requirements in a claim document from the server upon the validation of the access request. A processor receives the claim requirements. A processor constructs a token based on the claim requirements. A processor sends the token to the server. A processor receives a response from the server. A processor sends the response to the client.

Abstract: In an approach for autonomous claim requirements discovery of APIs, a processor receives an access request from a client to a server. A processor validates the access request. A processor queries claim requirements in a claim document from the server upon the validation of the access request. A processor receives the claim requirements. A processor constructs a token based on the claim requirements. A processor sends the token to the server. A processor receives a response from the server. A processor sends the response to the client.

Abstract: A “sign-off” cookie is generated and stored upon initiation of a web session between a client and a web application executing on a server. The sign-off cookie preferably comprises both an identifier for the session (a “session ID”) together with an identifier (such as a URL) for a sign-off resource (associated with a sign-off mechanism) that can be used to clean-up the web session following its termination. The sign-off cookie may be returned to the client and/or retained within a proxy. Upon termination of the web session, the URL in the sign-off cookie is used to initiate a request to the sign-off mechanism to clean-up the web session. This approach provides for dynamic web session clean-up without requiring any pre-configuration of the sign-off mechanism.

Abstract: An approach is provided that responds to a connection request to connect to an external network entity using a connection from a managed connection pool. The connection pool is managed by selecting connections from the connection pool that includes one or more currently unused connections with the external network entity. One of the selected connections is validated by comparing an idle time associated with each of the selected connections to a maximum idle time value corresponding to the external network entity. The maximum idle time value being previously identified at the information handling system. The validated connection is then used to connect to the external network entity to satisfy the connection request.

Abstract: The problem of sharing session information across client contexts is addressed by binding initial session information to a persistent, short-lived and one-time use temporary identifier. This identifier is persisted on a client side (e.g., through a cookie jar) that is shared among the different client contexts that can share the original session. This temporary identifier, in turn, allows one or more other sessions to use the original session information by acting as an index into that session information, which is stored on the server side. Preferably, this temporary identifier contains a unique identifier (ID) that is generated as a sufficiently-complex random number. A mapping back to the real session identifier is maintained on the server side for this short-lived ID.

Abstract: A method, apparatus and computer program product to detect and apply security policy to active client requests within a secure user session begins by applying a first heuristic to a plurality of requests for a particular resource to identify a pattern indicating of an active client. In one embodiment, the heuristic evaluates a frequency of requests for the particular resource across one or more secure user sessions. Later, upon receipt of a new request for the particular resource, a determination is then made whether the new request is consistent with the pattern. If so, an action is taken with respect to a secure session policy.

Abstract: An intermediary (such as a web reverse proxy), which is located between a web browser and one or more backend applications, manages cookies that are provided by the backend applications and returned to the web browser during a user session. When a session sign-off event is initiated in the reverse proxy, HTTP “Set-Cookie” headers are sent back to the web browser to destroy the cookies (in the browser) that represent sessions with the one or more backend application(s).

Abstract: An intermediary (such as a web reverse proxy), which is located between a web browser and one or more backend applications, manages cookies that are provided by the backend applications and returned to the web browser during a user session. The intermediary decides which cookies should be sent to the browser and which cookies should be stored therein. Preferably, this determination is made in an automated manner by examining the response for any cookie-dependent code (e.g., scripting) included in the response.

Abstract: An authorization method is implemented in an authorization engine external to an authorization server. The authorization server includes a cache. The external authorization engine comprises an authorization decision engine, and a policy analytics engine. The method begins when the authorization decision engine receives a request for an authorization decision. The request is generated (at the authorization server) following receipt of a client request for which an authorization decision is not then available at the server. The authorization decision engine determines an authorization policy to apply to the client request, applies the policy, and generates an authorization decision. The authorization decision is then provided to the policy analytics engine, which stores previously-generated potential cache directives that may be applied to the authorization decision. Preferably, the cache directives are generated in an off-line manner (e.g.

Abstract: A method, apparatus and computer program product to detect and apply security policy to active client requests within a secure user session begins by applying a first heuristic to a plurality of requests for a particular resource to identify a pattern indicating of an active client. In one embodiment, the heuristic evaluates a frequency of requests for the particular resource across one or more secure user sessions. Later, upon receipt of a new request for the particular resource, a determination is then made whether the new request is consistent with the pattern. If so, an action is taken with respect to a secure session policy.

Abstract: An intermediary (such as a web reverse proxy), which is located between a web browser and one or more backend applications, manages cookies that are provided by the backend applications and returned to the web browser during a user session. The intermediary decides which cookies should be sent to the browser and which cookies should be stored therein. Preferably, this determination is made in an automated manner by examining the response for any cookie-dependent code (e.g., scripting) included in the response.

Abstract: The problem of sharing session information across client contexts is addressed by binding initial session information to a persistent, short-lived and one-time use temporary identifier. This identifier is persisted on a client side (e.g., through a cookie jar) that is shared among the different client contexts that can share the original session. This temporary identifier, in turn, allows one or more other sessions to use the original session information by acting as an index into that session information, which is stored on the server side. Preferably, this temporary identifier contains a unique identifier (ID) that is generated as a sufficiently-complex random number. A mapping back to the real session identifier is maintained on the server side for this short-lived ID.

Abstract: A method for detecting and applying security policy to active client requests within a secure user session begins by applying a first heuristic to a plurality of requests for a particular resource to identify a pattern indicating of an active client. In one embodiment, the heuristic evaluates a frequency of requests for the particular resource across one or more secure user sessions. Later, upon receipt of a new request for the particular resource, a determination is then made whether the new request is consistent with the pattern. If so, an action is taken with respect to a secure session policy. In one embodiment, the action bypasses the secure session policy, which policy is associated with an inactivity time-out that might otherwise have been triggered upon receipt of the new request. In addition, a second heuristic may be applied to determine whether a response proposed to be returned (in response to the new request) is expected by the active client. If so, the response is returned unaltered.

Abstract: A “sign-off” cookie is generated and stored upon initiation of a web session between a client and a web application executing on a server. The sign-off cookie preferably comprises both an identifier for the session (a “session ID”) together with an identifier (such as a URL) for a sign-off resource (associated with a sign-off mechanism) that can be used to clean-up the web session following its termination. The sign-off cookie may be returned to the client and/or retained within a proxy. Upon termination of the web session, the URL in the sign-off cookie is used to initiate a request to the sign-off mechanism to clean-up the web session. This approach provides for dynamic web session clean-up without requiring any pre-configuration of the sign-off mechanism.

Abstract: An approach is provided where an HTTP request is received and a Request for Security Token (RST) is created. Parameters are selected from the request and mappings are retrieved corresponding to the parameters. Context attributes are created in the RST corresponding to the parameters. A context attribute type value is set based on an HTTP section where the parameter is located within the HTTP request. The RST is sent to a security token service for processing. In another approach, a Request Security Token Response (RSTR) is received and an HTTP response is created. RSTR parameters are selected and parameter mappings are retrieved corresponding to the selected RSTR parameters from a mapping table with a TYPE value being identified based on the retrieved parameter mapping. Context attributes are added to the HTTP response based on the identified TYPE values. The HTTP response is transmitted to a remote computer system.

Abstract: An approach is provided in which a number of requests are received from a variety of clients over a computer network. The system uses a processor to calculate request priority values pertaining to the received requests. The calculation of the request priority values is based on one or more attributes that correspond to the respective requests. For example, the attributes could include network level attributes, session attributes, and application specific attributes. Each of the requests is assigned a request priority value. A request may receive the same request priority value as other requests. The requests are queued in a memory based on the request priority values that were assigned to the requests. The queued requests are then serviced in order of request priority so that queued requests assigned higher request priority values are processed before queued requests with lower request priority values.

Abstract: An authorization method is implemented in an authorization engine external to an authorization server. The authorization server includes a cache. The external authorization engine comprises an authorization decision engine, and a policy analytics engine. The method begins when the authorization decision engine receives a request for an authorization decision. The request is generated (at the authorization server) following receipt of a client request for which an authorization decision is not then available at the server. The authorization decision engine determines an authorization policy to apply to the client request, applies the policy, and generates an authorization decision. The authorization decision is then provided to the policy analytics engine, which stores previously-generated potential cache directives that may be applied to the authorization decision. Preferably, the cache directives are generated in an off-line manner (e.g.

Abstract: A method for detecting and applying security policy to active client requests within a secure user session begins by applying a first heuristic to a plurality of requests for a particular resource to identify a pattern indicating of an active client. In one embodiment, the heuristic evaluates a frequency of requests for the particular resource across one or more secure user sessions. Later, upon receipt of a new request for the particular resource, a determination is then made whether the new request is consistent with the pattern. If so, an action is taken with respect to a secure session policy. In one embodiment, the action bypasses the secure session policy, which policy is associated with an inactivity time-out that might otherwise have been triggered upon receipt of the new request. In addition, a second heuristic may be applied to determine whether a response proposed to be returned (in response to the new request) is expected by the active client. If so, the response is returned unaltered.

Abstract: An approach is provided where an HTTP request is received and a Request for Security Token (RST) is created. Parameters are selected from the request and mappings are retrieved corresponding to the parameters. Context attributes are created in the RST corresponding to the parameters. A context attribute type value is set based on an HTTP section where the parameter is located within the HTTP request. The RST is sent to a security token service for processing. In another approach, a Request Security Token Response (RSTR) is received and an HTTP response is created. RSTR parameters are selected and parameter mappings are retrieved corresponding to the selected RSTR parameters from a mapping table with a TYPE value being identified based on the retrieved parameter mapping. Context attributes are added to the HTTP response based on the identified TYPE values. The HTTP response is transmitted to a remote computer system.