Instant Messaging Access Manager or SSO Architecture

You can deploy Instant Messaging to use Access Manager policy features and single sign-on (SSO). An Instant Messaging architecture that uses Access Manager provides the same functionality as Basic Instant Messaging Architecture. To provide this functionality, you need to install the components listed inBasic Instant Messaging Architecture and also install Access Manager. In addition, you need to install the Access Manager SDK on the Instant Messaging server host.

In this architecture, Instant Messaging uses the directory to search for users but not to authenticate or authorize them. Instead, Access Manager is responsible for authenticating and authorizing users.

If you are planning on using SSO with Access Manager, you must configure Access Manager and Instant Messaging to use the same web container.

Figure 23–5 shows the Instant Messaging Access Manager architecture.

Figure 23–5 Instant Messaging Architecture With Access Manager-based Server Policy Management or Single Sign On

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 always connect through a multiplexor.

• Instant Messaging related services provided by the 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 Access Manager can be the same as the one that serves the Instant Messaging resources. See the Access Manager documentation for more details.

• The Access Manager SDK provides the API used by the Instant Messaging server to interact with the Access Manager.

Authentication in an Access Manager Only Architecture

Figure 23–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 23–2, this figure focuses on the flow of authentication requests. An explanation of the steps in this process follows the figure.

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

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.