Sun Java Communications Suite 5 Deployment Planning Guide

Instant Messaging Portal-based or Archiving Architecture

You can deploy Instant Messaging to support message archiving and to have basic Instant Messaging functionality through the Portal Desktop. An Instant Messaging architecture that provides for this functionality also provides the same functionality as Basic Instant Messaging Architecture. In addition, the Instant Messenger client is made available to end users through the Portal Server desktop. To provide this functionality, you need to install the components listed in Basic Instant Messaging Architecture and also install Portal Server and Access Manager.

This architecture uses the directory and Web servers accessed by the Access Manager. You do not need to install additional instances of those servers. In addition, because this architecture requires Access Manager, all the features described in Instant Messaging Access Manager or SSO Architecture are also available.

Figure 21–7 shows the Instant Messaging Portal-based architecture.

Figure 21–7 Instant Messaging Architecture With Portal-based Secure Mode or Archiving

This diagram shows the Instant Messaging archive components
and data flow.

In this example:

Authentication in a Portal Server Architecture

Figure 21–8 illustrates 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–8 Flow of Authentication Requests in a Portal Server and Access Manager Configuration

This diagram shows Instant Messaging when deployed with
Portal Server.

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 Portal Server by entering the URL in a web browser.

  2. The Access Manager software authenticates the end user and returns a session token and the Portal Server downloads the Desktop for the end user. The Portal Server Desktop is displayed in the end user’s browser. See Step 6 for an explanation of the session token.

  3. The end user clicks the Instant Messenger URL link from the Instant Messaging channel on the Desktop.

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

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

  6. Instant Messenger requests authentication to the Instant Messaging server using the 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.

  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, and so forth.

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