Sun Java Communications Suite 5 Deployment Planning Guide

Authentication in an Access Manager Only Architecture

Figure 21–6 illustrates the authentication process used by the Instant Messaging software in collaboration with Portal Server and Access Manager components in a single sign-on environment. As with Figure 21–2, this figure focuses on the flow of authentication requests. An explanation of the steps in this process follows the figure.

Figure 21–6 Flow of Authentication Requests in an Access Manager Configuration

This diagram shows Instant Messaging archive components
and data flow.

The authentication process of the Instant Messaging server in this deployment within a single sign-on environment works as follows:

  1. The end user logs in to the Access Manager server by entering the URL in a web browser.

  2. The Access Manager software authenticates the end user and returns a session token.

    The session token is what enables single sign-on to work. This token is provided as an applet parameter and is used throughout the authentication process. End users are not asked for their credentials again as long as the session token is present.

  3. End user accesses the Instant Messenger applet URL from a browser and chooses a method to invoke the client.

  4. The browser invokes Java Web Start or the Java plugin as appropriate.

  5. Java Web Start or the Java plugin downloads the necessary Instant Messenger resource files and starts Instant Messenger.

  6. Instant Messenger requests authentication to the Instant Messaging server using the session token.

  7. The Instant Messaging server asks Access Manager to validate the session token. If the session is valid, Instant Messenger displays the end user’s contact list and the end user can then use Instant Messenger services: chat, alerts, polls, etc.

  8. The Instant Messaging server must query LDAP directly to get or set end-user information, such as contact lists or subscriptions.