Oracle International Corporation

Stephen Mathew

Vipin Anaparakkal Koottayi

Madhu Martin

Ramya Subramanya

Vikas Pooven Chathoth

Vamsi Motukuru

Ramya Kukehalli Subramanya

Aarathi Balakrishnan

Vipin Anaparakkal Kootayi

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

The disclosure relates to techniques for enforcing a limit on single sign-on (SSO) sessions for users across multiple data centers in a multi data center deployment. Users may request access to resources that are governed by an access manager deployed across multiple data centers, with each data center being associated with its own identifier. Each user may be associated with an identity attribute preserved in identity stores across the multiple data centers. The prerequisite for session creation at a data center may be to update the identity attribute of the user to that data center's identifier. If the identity attribute can be updated successfully, the access manager can create a new SSO session at that data center. Updates to the identity attribute may be synchronized across all of the data centers, with each data center aware of any existing sessions based on the current value of the identity attribute.

Managing session access across multiple data centers

The present disclosure relates generally to access control, and more particularly, to techniques for seamless transition between world wide web (WEB) resource access and application programming interface (API) resource access on an enterprise network with security restrictions. One technique includes receiving a request for access to a first resource, determining the first resource is a WEB resource, creating an authentication cookie and a bearer token that are tied together using a common identifier, and providing access to the WEB resource based on the authentication cookie. The technique may further include receiving a call for access to a second resource, where the call includes the bearer token in a header of the call, determining the second resource is an API resource, initiating a token exchange of the bearer token for an access token; and providing access to the API resource based on the access token.

Seamless transition between WEB and API resource access

Techniques are disclosed for restricting access to resources accessible in a SSO session. An access management system may provide access one or more resources by implementing an SSO system to provide a SSO session. An SSO session may provide an authenticated user with access to protected resources to which the user is entitled to access. In some instances, a user sharing a computer with other users may want to access a particular protected resource so as to restrict other users sharing the computer from accessing other protected resources accessible to the user in an SSO session. The access management system may enable the user to dynamically choose, such as during login, the protected resources which to restrict and/or permit. Upon successful authentication, a session may be established for only those protected resources that are permitted based on the user's selection, while the other resources are restricted.

Restricting access for a single sign-on (SSO) session

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 disclosed for enabling a user to validate the authenticity of a computing system (e.g., an access management system) such as one which controls access to one or more resources. A user can determine the authenticity of an access management system before the user provides credential information to the access management system. A user can be presented at a client system with an interface to request authentication of an access management system. The access management system may provide the user at the client system with temporary access information to submit back to the access management system. The access management system may provide recent personal information to the user at the client system to verify the access management system. Upon verification of the personal information, the access management system may prompt the user for credential information to establish a session.

End user initiated access server authenticity check

Techniques are disclosed for providing users of an access management system the capability to manage the user's active sessions. The system may receive a first request by a user at a first device to modify one or more sessions established for the user. The system may access session information about the one or more sessions that are associated with the user, wherein a session of the one or more sessions provides the user with access to one or more resources. The system may send the session information to the first device, the session information causing the first device to display a graphical interface including the session information about the one or more sessions. The system may receive, from the first device, a second request indicating a modification to the session. The system may modify the session in accordance with the modification indicated in the second request.

Techniques for configuring sessions across clients

Techniques are disclosed for facilitating impersonation for accessing resources through an access management system. When a user ('impersonator') requests access to impersonate another user ('impersonatee'), the access management system may generate security data having two parts. One part may include a first security key that is sent to the impersonator and a second part may include a second security key that is sent to the impersonatee. Receipt of the second security key notifies the impersonatee about a request for impersonation to access a resource according to access permitted to the impersonatee. The impersonatee, if consenting to impersonation, may provide the security key received to the impersonator, thereby implicitly providing the impersonator with trust at run-time to access the resource. Upon verification of both security keys, by the access management system, access to a resource is provided to the impersonator based on access to the resource permitted to the impersonatee.

Run-time trust management system for access impersonation

Techniques are disclosed for managing session activity of SSO access across multiple data centers. Session activity of SSO access is managed across multiple geographically disperse computing systems clustered together to form a multi-data center (MDC) system. A first data center in the MDC system may implement session adoption to manage an SSO session of the user in the MDC system. Information about subsequent sessions established by other data centers may be adopted by the first data center. The first data center may obtain session activity data from each session that is adopted for the user. The session activity may be used to determine whether SSO session is active for the user across data centers in the MDC system. Authorization to access a resource at any data center in the MDC system may be granted based on the status of the SSO session using session adoption among the data centers.

Session activity tracking for session adoption across multiple data centers

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

Techniques are disclosed for protecting a user from denial of service (DOS) to access his/her a user account that has been locked. An access management system can provide features that enable an owner of an account to prevent the account from becoming locked. Specifically, the techniques disclosed herein enable an account holder to circumvent procedures of the access management system that lock an account after several unsuccessful attempts to access the account. The access management system may operate according to a configuration for managing access to account. The access management system can manage access to an account by presenting a user with an interface to received access information (e.g., account information and credential information) for the account to determine whether to unlock the account. The access management system can deny access to an account upon determining that the credential information is not correct for the account.

Growing community of inventors

Bengaluru, India

Stephen Mathew