Abstract: Techniques are described for providing session management functionalities using an access token (e.g., an Open Authorization (OAuth) access token). Upon successful user authentication, a session (e.g., a single sign-on session) is created for the user along with a user identity token that includes information identifying the session. The user identity token is presentable in an access token request sent to an access token issuer authority (e.g., an OAuth server). Upon receiving the access token request, the user identity token is parsed to identify and validate the session against information stored for the session. The validation can include various session management-related checks. If the validation is successful, the token issuer authority generates the access token. In this manner, the access token that is generated is linked to the session. The access token can then be used by an application to gain access to a protected resource.

Abstract: Techniques are described for providing session management functionalities using an access token (e.g., an Open Authorization (OAuth) access token). Upon successful user authentication, a session (e.g., a single sign-on session) is created for the user along with a user identity token that includes information identifying the session. The user identity token is presentable in an access token request sent to an access token issuer authority (e.g., an OAuth server). Upon receiving the access token request, the user identity token is parsed to identify and validate the session against information stored for the session. The validation can include various session management-related checks. If the validation is successful, the token issuer authority generates the access token. In this manner, the access token that is generated is linked to the session. The access token can then be used by an application to gain access to a protected resource.

Abstract: Techniques are described that enable maintaining of session stickiness across authentication and authorization channels in an access management system, through the use an identifier for an access manager from a plurality of access managers. The access manager authenticates a user of a client device based on an authentication request. In response to response to successful authentication of the user, the access manager creates a session. The access manager also generates the identifier and causes the identifier to be stored for the session. The access manager can then receive a second request, which is sent to the access manager based on identifying the access manager using the stored identifier.

Abstract: Techniques are described for providing session management functionalities using an access token (e.g., an Open Authorization (OAuth) access token). Upon successful user authentication, a session (e.g., a single sign-on session) is created for the user along with a user identity token that includes information identifying the session. The user identity token is presentable in an access token request sent to an access token issuer authority (e.g., an OAuth server). Upon receiving the access token request, the user identity token is parsed to identify and validate the session against information stored for the session. The validation can include various session management-related checks. If the validation is successful, the token issuer authority generates the access token. In this manner, the access token that is generated is linked to the session. The access token can then be used by an application to gain access to a protected resource.

Abstract: Techniques are described for providing session management functionalities using an access token (e.g., an Open Authorization (OAuth) access token). Upon successful user authentication, a session (e.g., a single sign-on session) is created for the user along with a user identity token that includes information identifying the session. The user identity token is presentable in an access token request sent to an access token issuer authority (e.g., an OAuth server). Upon receiving the access token request, the user identity token is parsed to identify and validate the session against information stored for the session. The validation can include various session management-related checks. If the validation is successful, the token issuer authority generates the access token. In this manner, the access token that is generated is linked to the session. The access token can then be used by an application to gain access to a protected resource.

Abstract: The present disclosure relates generally to threat detection, and more particularly, to techniques for managing user access to resources in an enterprise environment. Some aspects are directed to the concept of managing access to a target resource based on a threat perception of a user that is calculated using a rule or policy based risk for the user and a behavior based risk for the user. Other aspects are directed to preventing insider attacks in a system based on a threat perception for each user logged into the system that is calculated using a rule or policy based risk for each user and a behavior based risk for each user. Yet other aspects are directed to providing a consolidated view of users, applications being accessed by users, and the threat perception, if any, generated for each of the users.

Abstract: Techniques are described that enable maintaining of session stickiness across authentication and authorization channels in an access management system, through the use an identifier for an access manager from a plurality of access managers. The access manager authenticates a user of a client device based on an authentication request. In response to response to successful authentication of the user, the access manager creates a session. The access manager also generates the identifier and causes the identifier to be stored for the session. The access manager can then receive a second request, which is sent to the access manager based on identifying the access manager using the stored identifier.

Abstract: Techniques are described that enable maintaining of session stickiness across authentication and authorization channels in an access management system, through the use an identifier for an access manager from a plurality of access managers. The access manager authenticates a user of a client device based on an authentication request. In response to response to successful authentication of the user, the access manager creates a session. The access manager also generates the identifier and causes the identifier to be stored for the session. The access manager can then receive a second request, which is sent to the access manager based on identifying the access manager using the stored identifier.

Abstract: The present disclosure relates generally to threat detection, and more particularly, to techniques for managing user access to resources in an enterprise environment. Some aspects are directed to the concept of managing access to a target resource based on a threat perception of a user that is calculated using a rule or policy based risk for the user and a behavior based risk for the user. Other aspects are directed to preventing insider attacks in a system based on a threat perception for each user logged into the system that is calculated using a rule or policy based risk for each user and a behavior based risk for each user. Yet other aspects are directed to providing a consolidated view of users, applications being accessed by users, and the threat perception, if any, generated for each of the users.

Abstract: The present disclosure relates generally to threat detection, and more particularly, to techniques for managing user access to resources in an enterprise environment. Some aspects are directed to the concept of managing access to a target resource based on a threat perception of a user that is calculated using a rule or policy based risk for the user and a behavior based risk for the user. Other aspects are directed to preventing insider attacks in a system based on a threat perception for each user logged into the system that is calculated using a rule or policy based risk for each user and a behavior based risk for each user. Yet other aspects are directed to providing a consolidated view of users, applications being accessed by users, and the threat perception, if any, generated for each of the users.

Abstract: Techniques are disclosed for a single sign-on (SSO) enterprise system with multiple data centers that can use a lightweight cookie on a user's client device. The lightweight cookie can include a reference to a data center in which the user is already authenticated, and a new data center can contact the old data center for creating a session for the user on the new data center. If the old data center is unavailable, then the new data center may fall back to accessing a local security store, a backup of keys, security tokens, and/or other security data, in order to create a local session for the user on the new data center.

Abstract: Techniques are provided for of constructing a whitelist of redirection uniform resource locators (URLs). A method can include receiving, by a computing system executing an access manager application, a request to log out a user from an application executing on a device; determining, by the access manager application, a redirection address for the application; validating, by the access manager application, the redirection address; and based on the validation, causing, by the access manager application, the application to perform one of redirecting the user to the redirection address and determining addition of the redirection address to a list of valid redirection addresses.

Abstract: Techniques are described for providing session management functionalities using an access token (e.g., an Open Authorization (OAuth) access token). Upon successful user authentication, a session (e.g., a single sign-on session) is created for the user along with a user identity token that includes information identifying the session. The user identity token is presentable in an access token request sent to an access token issuer authority (e.g., an OAuth server). Upon receiving the access token request, the user identity token is parsed to identify and validate the session against information stored for the session. The validation can include various session management-related checks. If the validation is successful, the token issuer authority generates the access token. In this manner, the access token that is generated is linked to the session. The access token can then be used by an application to gain access to a protected resource.

Abstract: Techniques are disclosed for managing session information stored by an access management system. Certain techniques are disclosed for updating session information based characteristics of the session information to be updated. The disclose techniques disclose how session information is updated and the frequency in which the session information is updated. Certain embodiments may enable a decrease in computing performance overhead and/or memory usage overhead caused by managing session information (e.g., performing authentication or determining authorization to access a resource) for a session.

Abstract: Techniques are disclosed to modify the authentication level of a session providing access to resources. In some embodiments, an access management system is configurable to enable voluntary (e.g., request by a user) or involuntary (e.g., by the access management system) reduce, or “step-down” the authentication level for a session if a lower authentication level exists. For example, an access management system may be configured to enable a user to request a step-down of the authentication level of a session to prevent access to resources at a higher authentication level. By reducing the authentication level to a lower authentication level, a user may be prompted to provide credentials for authentication according to the authentication schemes defined for higher authentication levels. These techniques can reduce, if not prevent, unauthorized access to protected resources by challenging a user for credentials to authenticate to higher authentication levels.

Abstract: Techniques are described that enable maintaining of session stickiness across authentication and authorization channels in an access management system, through the use an identifier for an access manager from a plurality of access managers. The access manager authenticates a user of a client device based on an authentication request. In response to response to successful authentication of the user, the access manager creates a session. The access manager also generates the identifier and causes the identifier to be stored for the session. The access manager can then receive a second request, which is sent to the access manager based on identifying the access manager using the stored identifier.

Abstract: Techniques are disclosed for a single sign-on (SSO) enterprise system with multiple data centers that can use a lightweight cookie on a user's client device. The lightweight cookie can include a reference to a data center in which the user is already authenticated, and a new data center can contact the old data center for creating a session for the user on the new data center. If the old data center is unavailable, then the new data center may fall back to accessing a local security store, a backup of keys, security tokens, and/or other security data, in order to create a local session for the user on the new data center.

Abstract: The present disclosure relates generally to threat detection, and more particularly, to techniques for managing user access to resources in an enterprise environment. Some aspects are directed to the concept of managing access to a target resource based on a threat perception of a user that is calculated using a rule or policy based risk for the user and a behavior based risk for the user. Other aspects are directed to preventing insider attacks in a system based on a threat perception for each user logged into the system that is calculated using a rule or policy based risk for each user and a behavior based risk for each user. Yet other aspects are directed to providing a consolidated view of users, applications being accessed by users, and the threat perception, if any, generated for each of the users.

Abstract: Techniques are disclosed for a single sign-on (SSO) enterprise system with multiple data centers that can use a lightweight cookie on a user's client device. The lightweight cookie can include a reference to a data center in which the user is already authenticated, and a new data center can contact the old data center for creating a session for the user on the new data center. If the old data center is unavailable, then the new data center may fall back to accessing a local security store, a backup of keys, security tokens, and/or other security data, in order to create a local session for the user on the new data center.

Abstract: Systems and methods are disclosed for a single sign-on (SSO) enterprise system with multiple data centers that use a lightweight cookie on a user's client device. The lightweight cookie includes a reference to a data center in which the user is already authenticated, and a new data center contacts the old data center for creating a session for the user on the new data center. If the old data center is unavailable, then the new data center may fall back to accessing a local security store, a backup of keys, security tokens, and/or other security data, in order to create a local session for the user on the new data center.