Using single sign-on

LiveCycle users can connect to multiple LiveCycle web applications to perform a task. As users move from one web application to another, it is not efficient to require them to log in separately to each web application. The LiveCycle single sign-on mechanism lets users log in once, and then access any LiveCycle web application. Because LiveCycle developers can create client applications for use with LiveCycle, they must also be able to take advantage of the single sign-on mechanism.

Each LiveCycle web application is packaged in its own Web Archive (WAR) file, which is then packaged as part of an Enterprise Archive (EAR) file. Because an application server does not allow the sharing of session data across different web applications, LiveCycle uses HTTP cookies to store authentication information. Authentication cookies enable a user to log in to a LiveCycle application, and then connect to other LiveCycle web applications. This technique is known as single sign-on.

LiveCycle developers write client applications to extend the functionality of form Guides (deprecated) and to customize Workspace. For example, a Workspace application can start a process. The client application then uses a remoting endpoint to retrieve data from the LiveCycle service.

When a LiveCycle service is invoked using (Deprecated for AEM forms) LiveCycle Remoting, the client application passes the authentication cookie as part of the request. Because the user has already authenticated, no additional login is required to make a connection from the client application to the LiveCycle service.

Note: If a cookie is invalid or missing, there is no implicit redirect to a login page. Therefore, you can still call an anonymous service.

You can bypass the LiveCycle single sign-on mechanism by writing a client application that logs in and logs out on its own. If you bypass the single sign-on mechanism, you can use either basic or custom authentication with your application.

Because this mechanism does not use the LiveCycle single sign-on mechanism, no authentication cookie is written to the client. Login credentials are stored in the ChannelSet object for the remoting channel. Therefore, any RemoteObject calls you make over the same ChannelSet are made in the context of those credentials.

// Ethnio survey code removed