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.
In this example:
The LDAP server provides user entries.
The web server (can also be an application server, which includes a web server) downloads the Instant Messaging resources via a browser to the clients. The resources are basically the client.
Clients are always connect through an Instant Messaging multiplexor.
Instant Messaging related services provided by Access Manager include the presence service and the Instant Messaging service.
The web server can be used to access the Access Manager administration interface, which manages the identity-based services for the Instant Messaging deployment. The web server for both Access Manager and Portal Server can be the same as the one that serves the Instant Messaging resources. See the Sun Java System Access Manager and Sun Java System Portal Server documentation for more details.
The Access Manager SDK provides the API used by the Instant Messaging server to interact with the Access Manager.
The Instant Messaging channel is supported by Portal Server and enables users to access Instant Messenger from the Portal Desktop.
Portal Server provides archive functionality that allows you to save instant messages sent through the deployment.
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.
The authentication process of the Instant Messaging server in this deployment within a single sign-on environment works as follows:
The end user logs in to the Portal Server by entering the URL in a web browser.
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.
The end user clicks the Instant Messenger URL link from the Instant Messaging channel on the Desktop.
Java Web Start or the Java plugin downloads the necessary Instant Messenger resource files and starts the Instant Messenger.
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.
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.
The Instant Messaging server must query LDAP directly to get or set end-user information, such as contact lists or subscriptions.