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