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 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 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: 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: Location-based authentication may be provided by an access management system on a server. The location-based authentication may determine whether a device should be granted access to a resource. The resource may either be located on or remote from the server. The location-based authentication may provide an additional authentication factor that is based on a past location of a user and/or device associated with the user requesting authentication. The past location may be associated with a user-configured question. The user-configured question may be provided to the device for an additional level of security. An answer received in response to a user-configured question may be compared to a user-configured answer that is associated with the user-configured question. In other examples, the answer may be compared to one or more possible answers that are determined by the access management system.

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 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 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: Location-based authentication may be provided by an access management system on a server. The location-based authentication may determine whether a device should be granted access to a resource. The resource may either be located on or remote from the server. The location-based authentication may provide an additional authentication factor that is based on a past location of a user and/or device associated with the user requesting authentication. The past location may be associated with a user-configured question. The user-configured question may be provided to the device for an additional level of security. An answer received in response to a user-configured question may be compared to a user-configured answer that is associated with the user-configured question. In other examples, the answer may be compared to one or more possible answers that are determined by the access management system.

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.

Abstract: An enterprise software system access manager saves cookies for users' sessions on client devices but creates server-side sessions on the fly when needed for the users to access certain features, when there is a constraint on the client device, or due to application policies. The server-side session objects can have references to the client-side cookies and can have key-value pairs added to them instead of the associated cookie.

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.