Oracle International Corporation

Mrudul Pradeep Uchil

Siva Sundeep Kuppala

Bhavik Sankesara

Damien Carru

Marc B Manza

Swati Jain

Smith William Cornwell

Risheng Xia

Sudhamsh Goutham Teegala

Ashish Kolli

Elangovan Subramanian

Dharmvir Singh

Jay Vijay Gangawane

Binoy Joseph

Josh Brunaugh

Embodiments provide cloud based identity management to authenticate a user. At a first authentication layer, embodiments receive a request from the user to be authenticated, where the request is received from a browser application on a user computer, and create at least one cookie, where the cookie includes state information of the request and is adapted to be stored on the browser application. At the first authentication layer, embodiments first redirect the request to a second authentication layer. At the second authentication layer, embodiments receive the cookie from the browser application and authenticate the user, and second redirect the request to the first authentication layer, where the second redirecting includes providing a result of the authenticating as a query parameter.

Cookie based state propagation for a multi-tenant identity cloud service

A cloud-based identity and access management system that implements single sign-on ('SSO') receives a first request for an identity management service configured to allow for accessing an application. Embodiments send the first request to a first microservice which performs the identity management service by generating a token. The first microservice generates the token at least in part by sending a second request to a SSO microservice that is configured to provide SSO functionality across different microservices that are based on different protocols. Embodiments then receive the token from the first microservice and provide the token to the application, where the token allows for accessing the application.

Single sign-on functionality for a multi-tenant identity and data security management cloud service

Web-based single sign-on can enable a user to log in to a single interface (such as through a web browser or thin client) and then provide SSO services to the user for one or more web applications. The web-based SSO system can be extended to support one or more different access control methods, such as form-fill, Federated (OIF), SSO Protected (OAM), and other policies. The web-based SSO system can include a user interface through which the user can access different web applications, systems, etc. and manage their credentials. Each SSO service can be associated with a web interface allowing the SSO services to be accessed over the web. The web interfaces can provide CRUD (create, read, update, delete) functionality for each SSO service. To support different access policy types, the web-based SSO system can include an extensible data manager that can manage data access to different types of repositories transparently.

Web-based interface integration for single sign-on

A cloud-based identity and access management system that implements single sign-on ('SSO') receives a first request for an identity management service configured to allow for accessing applications. Embodiments send the first request to a first microservice, where the first microservice performs the identity management service by generating a token. The first microservice generates the token at least in part by sending a second request to a SSO. The SSO microservice implements an SSO and generates a cookie that includes a global state and is used for communicating with different microservices. Embodiments receive a single log-out (SLO) of the SSO and use the cookie to iteratively log-out of the applications, where, after each log-out of an application of a first protocol, a redirect is performed to the SSO microservice to trigger log-out of applications of a different protocol.

Single logout functionality for a multi-tenant identity and data security management cloud service

A system that provides cloud based identity management, at a first microservice, saves a current state on a cookie that is stored on a browser, where the current state is saved in a format specific to the first microservice. The system performs an operation on the first microservice that generates a first portion of information and a second portion of information. The system stores the first portion of information related to the operation on the cookie, the first portion including the current state. The system provides a second portion of information related to the operation to a second microservice as a query parameter on a redirect Uniform Resource Locator ('URL'), where the second portion is removed from the cookie.

Virtualized data storage and management of policy and credential data sources

Web-based single sign-on logon manager

Embodiments described herein relate to extending the functionality of one or more access management servers, using plug-in files which may be uploaded while the servers are running. The plug-in files may be discovered in both the plug-in file's own class path and the server's class path, and then may be used in the server's authentication and other operations. In certain embodiments, the server's class path need not be modified during this process, and the server need not be shut down or restarted. Certain embodiments may implement a parallel class loader. Custom plug-in file code may be loaded by the parallel class loader, and the parallel class loader is started a container class loader may be made the parent of the parallel class loader.

Hot pluggable extensions for access management system

A file containing code for customizing a server's functionality can be 'hot plugged' into the server without requiring server restart. The file is added in a class path of its own. The server's class path is not modified during this process, and, consequently, the server does not need to be shut down or restarted. Changes are made to the class-loading pattern of a JVM. Whenever the JVM starts, the JVM's own container class loader component loads the classes. Custom plug-in jar file code is loaded by a parallel class loader that executes in parallel with the container class loader. When the parallel class loader is started, the container class loader is made the parent of the parallel class loader. Because the container class loader is made a super class of the parallel class loader, components loaded by the parallel class loader become recognized by the parent container class loader.

Growing community of inventors

Bengaluru, India

Mrudul Pradeep Uchil