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

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

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

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

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

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

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

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

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.