Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: A method and system for resource based authentication may include, in response to a client attempting to access a protected resource of a system, implementing resource based authentication. A policy agent may intercept the client access request and redirect it to an appropriate authentication gateway module based upon authentication polices. If the protected resource is not associated with any resource specific authentication technique, the policy agent may apply a default authentication technique. If, however, the protected resource is associated with a particular resource specific authentication technique, the policy agent may apply the resource specific authentication technique without applying the default authentication technique.