Oracle International Corporation

Madhu Martin

Stephen Mathew

Vikas Pooven Chathoth

Vipin Anaparakkal Koottayi

Aarathi Balakrishnan

Vamsi Motukuru

Ramya Subramanya

Dharmvir Singh

Mayank Maria

Deepak Ramakrishanan

Rohit Koul

Ramya Kukehalli Subramanya

Venkatesh Uppalapati

Vikas Pooven Chathath

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.

Single sign-on enabled with OAuth token

Single sign-on enabled OAuth token

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.

Maintaining session stickiness across authentication and authorization channels for access management

Single Sign-On enabled OAuth token

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.

Mechanisms for anomaly detection and access management

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.

Single sign-on between multiple data centers

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.

Whitelist construction

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.

Access manager session management strategy

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.

Techniques for authentication level step-down

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.

Methods and systems are described for upgrading an access manager framework. In response to an upgrade request from a client, current and new versions of the access manager framework are identified. Upon successful identification of the current version, one or more supported upgrade paths are determined for the upgrade process. An appropriate upgrade path from the current version to the new version is determined upon successful identification of the current and/or new version of the access manager framework. In response to determination of the appropriate upgrade path, a version specific program upgrade component and a version specific upgrade program are associated with the determined upgrade path. In addition, a set of information may be extracted from the access manager framework, transformed, and imported to the upgraded access manager framework based at least in part upon the determined version specific upgrade program and the version specific program upgrade component.

Growing community of inventors

Bengaluru, India

Madhu Martin