Sun Java Communications Suite 5 Deployment Planning Guide

Part IV Deploying Instant Messaging

This part contains the following chapters:

Chapter 19 Introduction to Instant Messaging Software

Instant Messaging enables secure, real-time communication and collaboration, combining presence awareness with instant messaging capabilities such as chat, conferences, alerts, news, polls, and file transfers to create a rich collaborative environment. These features enable one-to-one as well as group collaboration through either short-lived communications or persistent venues such as conference rooms or news channels.

Instant Messaging ensures the integrity of communications through its multiple authentication mechanisms and Secure Sockets Layer (SSL) connections. Integration with Portal Server and Access Manager brings additional security features, services-based provisioning access policy, user management, and secure remote access.

This chapter contains the following sections:

What Is an Instant Messaging Service?

At a simplistic level, an instant messaging service:

In addition, an instant messaging service can provide real-time conferencing, news and calendar alerts, and for offline users, email message forwarding.

Of crucial importance to a good instant messaging service is that the service provides for scalability, high availability, reliability, and good performance.

Instant Messaging Core Product Components

Instant Messaging contains the following core components:

Components Related to Instant Messaging

The software components discussed in this section work with the Instant Messaging server, but are installed separately. Chapter 21, Developing an Instant Messaging Architecture provides more detailed information that illustrates how these servers interact with Instant Messaging.

Web Container

(Required) For any deployment, you need to install a web container, such as Sun Java System Web Server or Sun Java System Application Server. You can also use any open standard web server (for example, Apache). In all cases, the Instant Messenger resources must reside on the web container host.

Instant Messaging requires a web container to serve the Instant Messenger resources. The Instant Messenger resource files include:

You must install Instant Messenger resources on the same host where the web container is installed. In an Access Manager deployment, you can install these resources on the Access Manager server’s host or on a different web container host. In most cases, the resources will be installed on the same host where you installed the Instant Messaging server software. It is possible to locate the Instant Messenger resources on a host other than the Instant Messaging server or multiplexor.


Note –

Install the web container before configuring Instant Messaging.


LDAP Server

(Required) Instant Messaging uses an LDAP server, such as Directory Server, for end user authentication and search. In a deployment with Portal Server, Instant Messaging uses the same LDAP server used by Portal Server. If you do not have an LDAP directory already installed, you must install one.

The Instant Messaging server does not store the Instant Messenger end-user authentication information. This information is stored in the LDAP server.

By default, the Instant Messaging server relies on the common end-user attributes cn and uid to search for end-user and group information. If you want, you can configure the server to use another attribute for search. In addition, Instant Messaging properties (such as contact lists and subscriptions) can be stored in files on the Instant Messaging server or in the LDAP server.

For instructions on configuring the server to use a non-default attribute for user search, see the Sun Java System Instant Messaging 7.2 Administration Guide.


Note –

Because a proper Directory Server implementation is instrumental to a successful Instant Messaging deployment, also see the Directory Server documentation:

http://docs.sun.com/app/docs/coll/1316.2


SMTP Server

(Optional) An SMTP messaging server, such as Messaging Server, is used to forward instant messages, in the form of email, to end users who are offline. The SMTP server can also be used to archive instant messaging communications. This is in lieu of or in addition to the archive capability provided by Portal Server. The SMTP server does not have to reside on the same host as the Instant Messaging server.

Calendar Server

(Optional) Calendar Server is used to notify users of calendar-based events.

Access Manager and Access Manager SDK

(Optional) Access Manager and Access Manager SDK provide end user, service, and policy management, authentication and single sign-on services. In addition, Access Manager and Access Manager SDK are required in deployments that include Portal Server. In both deployments, the SDK must be installed on the Instant Messaging server’s host.

Portal Server

(Optional) Portal Server supports message archiving, and enables you to run Instant Messaging in secure mode. In addition, the Instant Messenger client is made available to end users through the Portal Server desktop. The following two Portal Server components provide additional functionality:

Portal Server Desktop

Instant Messenger installed in the Portal Server environment can be launched from the Instant Messaging channel available to end users on Portal Server Desktop.

Secure Remote Access

Secure Remote Access enables remote end users to securely access their organization’s network and its services over the Internet. The end user can access Secure Remote Access by logging into the web-based Portal Server Desktop through the portal gateway. The authentication module configured for Portal Server authenticates the end user. The end-user session is established with Portal Server and the access is enabled to the end user’s Portal Server Desktop.

In the Portal Server environment, you can configure Instant Messenger in either secure or non-secure mode. In secure mode, communication is encrypted through the Portal Server Netlet. When you access Instant Messenger in secure mode, a lock icon appears in the Status area of the Instant Messenger application. In non-secure mode, the Instant Messenger session is not encrypted. For more information on Netlet, see the Portal Server documentation:

http://docs.sun.com/coll/1293.2

Instant Messaging Supported Standards

Instant Messaging is built on native Internet technology, so you can maintain a single architecture inside and outside your organization, even when collaborating with your customers and partners. Additionally, you aren’t locked into a proprietary system. All key components of Instant Messaging are based on proven, open Internet standards such as:

Instant Message Structure Format

XMPP protocol is used to format the instant messages. The message bodies themselves may be wrapped in HTML.

Access Protocol

In Instant Messaging, user information and preferences are retrieved from an LDAP directory. This directory can either be dedicated for use by Instant Messaging, or be shared by other components such as Access Manager or Portal Server. User data is typically retrieved using LDAP search functions. Instant Messaging deployments that make use of Access Manager and Portal Server make use of the same LDAP server.

Communication and Message Transfer Protocols

Instant Messaging server-to-server and client-to-server communications occur over TCP/IP. You can secure these communications by using TLS encryption.

Instant Messaging uses SMTP to send messages to offline users and for email archiving.

Browsers use HTTP to retrieve Instant Messenger resource files from the Web server. Once retrieved, the browser reads the HTML and displays the contents of the files. Client-to-server communication can take place over HTTP/HTTPS/SOCKS proxy. Also, HTTPBIND is a server component (that uses the HTTP protocol) through which browser-based XMPP clients can communicate with the Instant Messaging server.

Instant Messaging 7.2 is an XMPP client/server solution, able to communicate with XMPP-compliant servers, clients, and gateways. Gateways are available in the open-source community to enable communication between Instant Messaging server and AOL, Yahoo, and other instant messaging systems.

Instant Messaging Software Architecture

Figure 19–1 shows the Instant Messaging software architecture.

Figure 19–1 Instant Messaging Software Architecture

This diagram the relationship between components in Instant
Messaging.

The web server (or an application server with a web service embedded), downloads the Instant Messenger resources from a browser to the clients. The resource files make up the client. Clients send messages to one another through a multiplexor, which forwards the messages to the Instant Messaging server.

The directory server stores and retrieves local user and group delivery information such as preferences, location, and to which multiplexor to route messages for this user. When the Instant Messaging server receives a message, it uses this information to determine where and how the message should be delivered. In addition, the directory server can contain user information such as contact lists and subscriptions.

In this basic configuration, Instant Messaging directly accesses Directory Server to verify user login name and passwords for mail clients that use Instant Messaging.

Outgoing instant messages from clients go directly to the multiplexor. The multiplexor sends the message to the appropriate Instant Messaging server, which in turn forwards the message to another Instant Messaging server, or if the message is local, to the multiplexor with which the recipient is associated. (See Instant Messaging Physical Deployment Examples for illustrations of this process.)

New users are created by adding user entries to the directory. Entries in the directory can be created through Instant Messaging Server (by enabling new-user registration feature) or changed by using the tools provided with the directory server.

Instant Messaging components are administered through a set of command-line interfaces and text-based configuration files. Any machine connected to the Instant Messaging host can perform administrative tasks (assuming, of course, the administrator has the required privileges).


Note –

Typical Instant Messaging deployments are not installed on a single machine. They also have additional features like multiplexing and high availability enabled. See Chapter 21, Developing an Instant Messaging Architecture for more information.


The following sections outline the three primary components of Instant Messaging in further detail:

Instant Messaging Server

The Instant Messaging server handles tasks such as maintaining presence information for each user, controlling Instant Messenger privileges and security, enabling Instant Messenger clients to communicate with each other by sending alerts, initiating chat conversations, and posting messages to the available news channels. The Instant Messaging server also handles archiving, calendar alerts, and offline email notifications

The Instant Messaging server supports the connection of a multiplexor that consolidates connections over one socket. For more information on the multiplexor, see Instant Messaging Multiplexor.

Access control files and Access Manager policies are used for administration of end users, news channels, and conference rooms.

The Instant Messaging server routes, transfers, and delivers instant messages for the Instant Messaging product.

Direct LDAP Lookup

The server can look up directory information directly from the LDAP server. The results of the LDAP queries are cached in the process, with configurable aging and expiration, so settings are tunable. Refer to the Directory Server documentation for further information.

http://docs.sun.com/app/docs/coll/1316.2

Message Delivery

After the message is processed, the server sends the message to the next stop along the message’s delivery path. This can be the intended recipient’s multiplexor or another server. Once received by a multiplexor, the message is routed directly to the intended recipient. See Basic Instant Messaging Architecture for an illustration of this process.

Instant Messaging Multiplexor

The Instant Messaging multiplexor component connects multiple instant messenger connections into one TCP (Transmission Control Protocol) connection, which is then connected to the Instant Messaging server. The multiplexor reads data from Instant Messenger and writes it to the server. Conversely, when the server sends data to Instant Messenger, the multiplexor reads the data and writes it to the appropriate connection. The multiplexor does not perform any end user authentication or parse the client-server protocol (IM protocol). Each multiplexor is connected to one and only one Instant Messaging server.

Although you can configure Instant Messaging without a multiplexor, production deployments should be configured to use the multiplexor. You can install multiple multiplexors based on your deployment requirements. For more information, Chapter 21, Developing an Instant Messaging Architecture.

Instant Messenger Client

Instant Messenger is Instant Messaging’s client that can be configured to be a browser-based applet using Java plugin, or a standalone Java application using JavaTM Web Start.

To run Instant Messenger client on Solaris or Linux, you must use Java Web Start. On Microsoft Windows you can run Instant Messenger as an applet or a Java Web Start application. In most cases, run Instant Messenger as a Java Web Start application.

For more information on customizing Instant Messenger, see the Sun Java System Instant Messaging 7.2 Administration Guide.

Instant Messenger provides the following modes of communication:


Note –

Instant messages can contain embedded URLs. If you are using proxy servers, you might need to have clients using Java Web Start modify their proxy configuration for resolving such URLs.

For more information on configuring the proxy settings manually, see the Sun Java System Instant Messaging 7.2 Administration Guide.


Designing Your Instant Messaging Deployment

The deployment process consists of the following general phases, referred to as the Solution Life Cycle:

The deployment phases are not rigid: the deployment process is iterative in nature.

For detailed information on the deployment process for Instant Messaging, and other Java Enterprise System components, see the Sun Java Enterprise System Deployment Planning Guide.

Chapter 20 Planning an Instant Messaging Sizing Strategy

This chapter introduces the concepts, context, and rationale of sizing your Instant Messaging deployment.

This chapter contains the following sections:

Instant Messaging Sizing Strategy Overview

When you design your deployment, you must decide how to configure your Instant Messaging server to provide optimum performance, scalability, and reliability.

Sizing is an important part of the design effort. The sizing process enables you to identify what hardware and software resources are needed so that you can deliver your desired level of service or response time according to the estimated workload that your Instant Messaging server users generate. Sizing is an iterative effort.

Because each deployment has its own set of unique features, this chapter will not provide detailed Instant Messaging sizing information for your specific site. Also, this chapter will not provide sizing information for servers with which Instant Messaging interoperates, such as LDAP, SMTP, and so on. Rather, this chapter explains what you need to consider when you architect your sizing plan. In addition, you’ll find general guidelines for Instant Messaging components you can modify to suit your site’s needs. Work with your Sun technical representative for your deployment hardware and software needs.

Collecting Instant Messaging Sizing Data

Use this section to identify the data you need to size your Instant Messaging deployment. The following topics are covered in this section:

Determining Peak Volume of Unique Instant Messaging Logins

Your peak volume is the largest concentrated numbers of unique logins to your Instant Messaging system within a given period in a day. The volume can vary from site to site as well as across different classes of users. For example, peak volume among groups might occur during corporate-held core hours which differ between time zones.

Analyzing peak volume involves three basic operations:

  1. Determining when and for how long the peaks occur

  2. Sizing your deployment against peak volume load assumptions

    Once patterns are analyzed, choices can be made to help the system handle the load and provide the services that users demand.

  3. Making sure that your Instant Messaging deployment can support the peak volume that you have determined

Creating Your Instant Messaging Usage Profile

Measuring your load is important for accurate sizing. Your usage profile determines the factors that programs and processes place on your Instant Messaging servers and multiplexors.

This section helps you create your usage profile to measure the amount of load that is placed on your deployment.

Creating a usage profile involves answering the following questions:

  1. What is the total number of users on your system?

    When counting the number of users on your system, account for not only the users who have accounts and can log into the system, but also the users with accounts who are currently not logged into the system. The following table describes the types of users that make up the total.

    Connection  

    Description  

    Inactive User 

    A user with an Instant Messaging account who currently is not logged into the system. Non-connected users consume disk space but no CPU or memory. 

    Connected/Inactive 

    These users are logged in, but are not currently sending or receiving instant messages. 

    Connected/Active 

    Logged into the system and actively sending messages, updating user information such as contact lists, and attending conferences throughout the day. 

    Characterize your configured users using these three general profiles. The total of these users should give you an idea of the total number of concurrent connections you need to support.

    If you have a small deployment, the defaults might be sufficient to meet your site’s needs. So, if you have a very small deployment (for example, less than 300 users), you might not need to go through this process of planning a sizing strategy. Work with your Sun Client Services representative to determine your individual needs.

  2. How many connections are on your system during your peak volume?

    Correctly formulating the maximum number of concurrent users that has to be sustained by the system is key to planning your resource requirements. Although a deployment usually has maximum number of configured users, it is important to plan for the maximum number of concurrent users (connected and more or less active). A conservative estimate for the number of concurrent users can then be determined based on a 1:10 ratio. Thus, for a deployment of 50,000 configured users, the concurrent users would be 5,000.

    Specifically, note the number of concurrent connections, idle, and busy connections.

    Connection  

    Description  

    Concurrent Connection 

    Number of unique TCP connections or sessions that are established on your system at any given time. 

    Idle Connection 

    Connection where no information is being sent between the client and multiplexor or server and multiplexor. 

    Busy Connection 

    A connection that is in progress. An established connection where information is being sent between the client and multiplexor or multiplexor and server. 

    To determine the number of concurrent connections in your deployment, you can count the number of established TCP connections by using the netstat command on Solaris platforms.

    To determine the number of concurrent connections you can support, you need to obtain two values from parameters within the iim.conf file that are used for tuning multiplexor performance:

    1. iim_mux.numinstances - Specifies the number of multiplexor instances.

    2. iim_mux.maxsessions - Specifies the maximum number of clients that one mutliplexor process can handle. The default is 1000.

    Once you have obtained these values, multiply the numinstances number by the maxsessions number. This gives the total number of concurrent connections supported by your deployment. For information on the iim.conf file, see the Sun Java System Instant Messaging 7.2 Administration Guide.

  3. If you have a large deployment, how will you organize your users?

    For example, consider placing active users on one server and inactive users on another.

  4. What is the amount of storage used for each user?

    If you are storing your end user data, such as contact lists, in LDAP, you need to plan for the space required to store this data. If you configure the server to store this data outside LDAP, the server stores it in a flat file. See the Sun Java System Instant Messaging 7.2 Administration Guide for more information.

  5. How many messages enter your Instant Messaging system from the Internet?

    The number of messages should be measured in messages per second during your peak volume.

  6. How many messages are sent by your users to:

    • End users on your system?

    • The Internet?

    This number of messages is also measured in messages per second during the peak volume.

  7. Will you be using SSL? If yes, what percentage of users and what type of users?

    For example, in a particular organization, 20% of connections during peak hours will enable SSL.

Answering these questions provides a preliminary usage profile for your deployment. You can refine your usage profile as your Instant Messaging needs change.

Additional Questions

While the following questions are not applicable to creating your usage profile, they are important to developing your sizing strategy. How you answer these questions might require you to consider additional hardware.

  1. How much redundancy do you want in your deployment?

    For example, do you need to consider high availability.

  2. What backup and restore strategy do you have in place (such as disaster recovery and site failover)? What are the expected times to accomplish recovery tasks?

    Typically you need to back up the server configuration files, database, and any resource files you have customized.

Defining Your Instant Messaging User Base or Site Profile

Once you establish a usage profile, compare it to sample pre-defined user bases that are described in this section. A user base is made up of the types of Instant Messaging operations that your users will perform. Instant Messaging users fall into one of these user bases:

The sample user bases described in this section broadly generalize user behavior. Your particular usage profile might not exactly match the user bases; you will be able to adjust these differences when you run your load simulator (as described in Using an Instant Messaging Load Simulator).

Casual Users

A lightweight user base typically consists of users with simple Instant Messaging requirements. These users rarely initiate chat sessions and rarely receive invitations. They might only use Instant Messaging as a presence tool.

Heavy Users

A heavy user uses significantly more system resources than a casual user. Typical usage for a this type of user may be something like the following:

Using an Instant Messaging Load Simulator

To measure the performance of your Instant Messaging architecture, use your user bases (described in Defining Your Instant Messaging User Base or Site Profile) and your usage profile (described in Creating Your Instant Messaging Usage Profile) as inputs into a load simulator.

A load simulator creates a peak volume environment and calibrates the amount of load placed on your servers. You can determine if you need to alter your hardware, throughput, or deployment architecture to meet your expected response time, without overloading your system. Using a load simulator involves five basic steps:

  1. Defining the user base that you want to test (for example, casual users)

    If necessary, adjust individual parameters to best match your usage profile.

  2. Defining the hardware that will be tested

  3. Running the load simulator and measuring the maximum number of concurrent connections on the tested hardware with the user base

  4. Publishing your results and comparing those results with production deployments

  5. Repeating this process using different user bases and hardware until you get the response time that is within an acceptable range for your organization under peak load conditions


Note –

Contact Sun Client Services for recommended load simulators and support.


Understanding Instant Messaging System Performance Guidelines

Once you evaluate your hardware and user base with a load simulator, you need to assess your system performance. The topics in this section address methods by which you can improve your overall system performance.

Instant Messaging Memory Utilization

Make sure you have an adequate amount of physical memory on each machine in your deployment. Additional physical memory improves performance and enables the Instant Messaging server to operate at peak volume. With sufficient memory, Instant Messaging can operate efficiently without excessive swapping.

For most deployments, you need at least 256 MB of RAM. The amount of RAM needed depends on the number of concurrent client connections, and whether the server and multiplexor are deployed on the same host. For information about concurrent connections, see Creating Your Instant Messaging Usage Profile. For information on hosting the server and multiplexor on the same host, see Developing Instant Messaging Architectural Strategies.

You can set the amount of memory allocated to the server by modifying the iim.jvm.maxmemorysize parameter in the iim.conf file. This parameter specifies the maximum number of megabytes of memory that the Java Virtual Machine (JVM) running the server is allowed to use. The default setting is 256 MB, and the maximum setting is 500 MB. For instructions on modifying this parameter, see the Sun Java System Instant Messaging 7.2 Administration Guide.

Instant Messaging Disk Throughput

Disk throughput is the amount of data that your system can transfer from memory to disk and from disk to memory. The rate at which this data can be transferred is critical to the performance of Instant Messaging. To improve efficiency in your system’s disk throughput:

Instant Messaging Disk Capacity

When planning Instant Messaging server system disk space, be sure to include space for operating environment software, Instant Messaging software, and for any servers not currently in your network that need to be installed to support Instant Messaging (such as LDAP). Be sure to use an external disk array. In addition, user disk space needs to be allocated. Typically, this space is determined by your site’s policy. Typical installations will require:

Use Table 20–1 to determine server and multiplexor disk space sizing numbers whether archiving is enabled or disabled. The figures listed in the table were generated using a 400MHz Ultra SPARC II Processor.

Table 20–1 Instant Messaging Server and Multiplexor Memory Disk Space Sizing for Concurrent Users

 

Server Memory Consumption for Connected/Inactive Users  

Server Memory Consumption for Connected/Active Users  

Multiplexor Memory Consumption for Connected/Inactive Users  

Multiplexor Memory Consumption for Connected/Active Users  

Archive Disabled 

8 MB +20 K per User 

120 MB + 20 K per User 

8 MB + 20 K per User 

8MB + 28K per User 

SSO/Portal/Archive enabled 

100MB +25K per User 

120MB +30K per User 

8M+35K per user 

8 MB +40K per user 

Instant Messaging Network Throughput

Network throughput is the amount of data at a given time that can travel through your network between your client application and server. When a networked server is unable to respond to a client request, the client typically retransmits the request a number of times. Each retransmission introduces additional system overhead and generates more network traffic.

Improving data integrity, system performance, and network congestion reduces the number of retransmissions. Steps to do this involve:

Instant Messaging CPU Resources

Enable enough CPU for your servers and multiplexing services. In addition, enable enough CPU for any RAID systems that you plan to use. If you intend to use archiving in your deployment, you need to take those space requirements into consideration as well.

Use Table 20–2 to help determine the number of CPUs your installation requires for optimum performance whether archive is enabled or disabled. The figures listed in the table were generated using a 400MHz Ultra SPARC II Processor.

Table 20–2 Instant Messaging CPU Utilization Numbers

 

Server CPU Utilization for Connected/Inactive Users  

Server CPU Utilization for Connected/Active Users  

Multiplexor CPU Utilization for Connected/Inactive Users  

Multiplexor CPU Utilization for Connected/Active Users  

Archive Disabled 

Several hundred thousand users per CPU 

30 K users per CPU 

50 K users per CPU 

5 K users per CPU 

Instant Messaging Multiplexor Configuration Best Practices

Consider the following suggestions and generalizations when planning your multiplexor deployment. The parameters discussed in this section are located in the iim.conf file.

See the Sun Java System Instant Messaging 7.2 Administration Guide for more detailed information about these parameters.

Developing Instant Messaging Architectural Strategies

Once you have identified your system performance needs, the next step in sizing your Instant Messaging deployment is to size specific components based on your architectural decisions.

The topics in this section point out sizing considerations when you deploy two-tiered and one-tiered architectures. Using load balancers with Instant Messaging is also discussed.

Two-tiered Instant Messaging Architecture

A two-tiered architecture splits the Instant Messaging server deployment into two layers: an access layer and a data layer. In a simplified two-tiered deployment, you might add one or more multiplexors and servers to the access layer. The multiplexor acts as a proxy for users, and relays messages to the Instant Messaging server. The data layer holds the Instant Messaging server database and Directory servers. Figure 20–1 shows a simplified two-tiered Instant Messaging architecture.

Figure 20–1 Simplified Two-tiered Instant Messaging Architecture

This diagram shows a simplified two-tiered Instant Messaging
architecture.

Two-tiered architectures have advantages over one-tiered architectures that can impact your sizing decisions. Two-tiered architectures:

Sizing Your Multiplexing Services

When you size your multiplexor, the calculation is based on your system load, particularly the number of concurrent connections the multiplexor needs to handle.

In addition, you must:

  1. Add CPU or a hardware accelerator for SSL if appropriate.

  2. Add memory to the machine if the multiplexor is being configured on it.

  3. Account for denial of service.

  4. Add capacity for load balancing and redundancy, if appropriate.

One or more of each type of machine should still handle peak load without a substantial impact to throughput or response time when you plan for redundancy in your deployment.

One-tiered Instant Messaging Architecture

In a one-tiered architecture, there is no separation between access and data layers. The Instant Messaging server, multiplexor, and sometimes the Directory server are installed in one layer. The following figure illustrates the idea.

Figure 20–2 Simplified One-tiered Instant Messaging Architecture

This diagram shows a simplified one-tiered deployment
for Instant Messaging server, a Directory Server, a multiplexor, and end users.

One-tiered architectures have lower up-front hardware costs than two-tiered architectures. However, if you choose a one-tiered architecture, you need to allow for significant maintenance windows.

To size a one-tiered architecture:

  1. Add CPU for SSL, if necessary.

  2. Account for denial of service attacks.

  3. Add more disks for the increased number of client connections.

  4. Add more disks for each multiplexor.

For specific instructions on sizing Instant Messaging components in one-tiered or two-tiered architectures, contact your Sun Client Services representative.

Using Load Balancers With Instant Messaging

Instant Messaging supports the use of load balancers located in front of the Instant Messaging multiplexors. However, you cannot currently use load balancers between the Instant Messaging multiplexors and the Instant Messaging server.

When deploying Instant Messaging as part of a Portal Server/Secure Remote Access deployment, you can locate load balancers between the Secure Remote Access gateway and the Instant Messaging multiplexors.


Note –

If you just need security for the client connection, and not HTTP tunneling, consider using SSL instead of Secure Remote Access. You can configure a secure Instant Messaging client connection by enabling SSL on the multiplexors and locating them outside the firewall.


Example Instant Messaging Resource Requirements

This section provides example resource distributions and recommended sizing information for the following two Instant Messaging deployment types:

Small Deployment Sample Resource Requirements Numbers

For a small Instant Messaging deployment with the server and multiplexor on a single server having 10,000 users with the following profile:

The hardware requirements are: one or two CPUs with 300-500 MB RAM each.

Large Deployment Sample Resource Requirements Numbers

For a large Instant Messaging deployment having 1,000,000 users with the following profile:

The server memory requirements are 4 GB RAM on two CPUs. The multiplexor requirement is 4 GB RAM on 16 CPUs.

Chapter 21 Developing an Instant Messaging Architecture

This chapter describes a variety of Instant Messaging architectures. Depending on your deployment, you will need to install different components. For example, to support email notification, you need to install an SMTP server. If you do not want to support email notification, do not install an SMTP server.

For more detailed information about components that interoperate with Instant Messaging, see Components Related to Instant Messaging.

This chapter contains the following sections:


Note –

Currently, all deployment options are available on Solaris OS. A subset of the deployment options is available on the Linux operating system.


Basic Instant Messaging Architecture

Figure 21–1 shows the basic Instant Messaging architecture.

Figure 21–1 Basic Instant Messaging Architecture

This diagram shows the relationship between components
in a basic Instant Messaging deployment.

The basic Instant Messaging architecture provides such functionality as chat, news alerts, and conferences. To provide this basic functionality, you need to install the following components:

In this example:

Authentication in a Basic Architecture

Figure 21–2 shows the interaction of the software components in the authentication process of a basic architecture of Instant Messaging. The focus is on the flow of authentication requests. An explanation of the steps in this process follows the figure.

Figure 21–2 Flow of Authentication Requests in a Basic Instant Messaging Architecture

This diagram shows the flow of authentication requests
during the authenication process of an LDAP-only  Instant Messaging server
configuration.

The authentication process in a basic architecture works as follows:

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

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

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

  4. The login window appears and the end user enters the login name and password. The login data is sent to the Instant Messaging server through the multiplexor.

  5. The Instant Messaging server communicates with the LDAP server to authenticate the end user and to request end-user information, such as contact lists or subscriptions.

When the end-user authentication is complete, the Instant Messaging main window appears, displaying the contact list for the end user. The end user can now start and participate in Instant Messaging sessions with the other end users.

Instant Messaging Email Notification (Calendar Alert) Architecture

You can deploy Instant Messaging to support email notification to offline users, as well as Instant Messaging based notification of calendar events to users.

An Instant Messaging architecture that supports email notification and calendar alerts provides the same functionality as Basic Instant Messaging Architecture. To provide this functionality, you need to include the components listed in Basic Instant Messaging Architecture. To support email alerts, you also install an SMTP server such as Sun Java System Messaging Server. To support calendar alerts, you also install Sun Java System Calendar Server.

To enable email notification, you are prompted to identify the SMTP server to use with Instant Messaging during installation. If you do not have an SMTP server installed, you must install one before installing the Instant Messaging software. Figure 21–3 shows Instant Messaging with email notification enabled on the network.

If you do not have Calendar Server installed, you must install it before installing the Instant Messaging software. Figure 21–4 shows Instant Messaging with calendar notification enabled on the network.

Authentication flow in this architecture is the same as in a basic deployment. See Authentication in a Basic Architecture for more information.

Figure 21–3 Instant Messaging Architecture with Email Notification

This diagram shows the relationship between components
in an Instant Messaging deployment with email notification enabled.

In this example:

Figure 21–4 Instant Messaging Architecture with Calendar Alerts

This diagram shows the relationship between components
in an Instant Messaging deployment with Calendar event notification enabled.

In this example:

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

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

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

This diagram shows the relationship between components
in an Instant Messaging deployment with Access Manager.

In this example:

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.

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.

Instant Messaging With All Features Enabled

You can deploy Instant Messaging and enable all the features listed in this section by installing:

You also need to configure the Access Manager Instant Messaging Service on the Access Manager host.

Instant Messaging Physical Deployment Examples

This section explains variations to the deployment scenario described in Basic Instant Messaging Architecture. For example, you can install the various required servers and components in the following physical configurations:

These variations can be applied in any of the architectures described in this chapter. You might choose to include them based on your deployment requirements.

Instant Messaging Physical Deployment Example: Web Server on Separate Host

Figure 21–9 shows a configuration consisting of the Instant Messaging server and multiplexor installed on the same host. The web server is installed on a separate host. The Instant Messaging resources are also present on the web server host. Use this configuration when there is an existing instance of a web server and an LDAP server, and you do not want to install other applications on these hosts.

Figure 21–9 Separate Web Server and Instant Messaging Hosts

This diagram shows the web server and the Instant Messenger
installed on a separate host.

Instant Messaging Physical Deployment Example: Multiplexors on Separate Hosts

Figure 21–10 shows a configuration consisting of two multiplexors installed on two separate hosts. The Instant Messaging server is installed on a different host. This configuration enables you to place a multiplexor outside your company’s firewall. Installing multiplexors on multiple hosts distributes the load of the Instant Messaging server across multiple systems.


Note –

The multiplexor can be resource-intensive, so putting it on a separate host can improve the overall performance of the system.


Figure 21–10 Instant Messaging Multiplexors Installed on Separate Hosts

This diagram displays several servers: two multiplexors
on separate hosts and an Instant Messaging server on yet a different host.

Instant Messaging Physical Deployment Example: Multiple Instant Messaging Hosts

Figure 21–11 shows a configuration consisting of two Instant Messaging servers. This configuration is used when the site contains multiple administrative domains. The server configuration on each Instant Messaging server host has to be set up so that end users on one Instant Messaging server can communicate with end users on other Instant Messaging servers.

Figure 21–11 Multiple Instant Messaging Server Hosts

This diagram shows a site with two administrative domains.

Chapter 22 Planning Instant Messaging Security

This chapter describes how to plan for and protect the various components of your Instant Messaging deployment.

This chapter contains the following sections:

Protecting Instant Messaging Components in Your Deployment

This section describes how to secure components in your Instant Messaging deployment.

Overview of Instant Messaging Security

Instant Messaging supports the following levels of security:

The startTLS option enables end-to-end encryption (the communication between client-multiplexor-server is all in encryption form), while legacy SSL enables encryption between the Instant Messenger client up to the multiplexor: the communication between multiplexor and server is in plain text (though in a proprietary protocol). Use startTLS if you require a higher level of security. If you use startTLS, you do not need an alternate means of securing the multiplexor-to-server communication (it will be secure).

Protecting Instant Messaging Server and Multiplexor

Instant Messaging supports TLS (Transport Layer Security) and legacy SSL (Secure Sockets Layer) for secure communications. Instant Messaging uses a startTLS extension to the Transport Layer Security (TLS) 1.0 protocol for client-to-server and server-to-server encrypted communications and for certificate-based authentication between servers. In addition, Instant Messaging supports a legacy implementation of the SSL protocol (version 3.0) for encrypted communications between the Instant Messenger client and the multiplexor.

When planning for SSL for Instant Messaging, keep in mind the following:

The Instant Messaging default installation supports only SASL Plain. If you require a higher level of security, use the Instant Messaging public Service Provider Interface. SASL Plain and jabber:iq:auth are two forms of plain text authentication. That is, in both, the password is sent in the clear (encoded perhaps, but still clear text) and so both are insecure forms of authentication. Nevertheless, this is an issue only if end-to-end encryption (through startTLS for direct socket connection, and HTTPS for httpbind) is not enabled. If end-to-end encryption is enabled, the password is not “seen” in the clear on the network.

Alternatively, if you do not want to transmit passwords in the clear (even if over an encrypted stream), use the Instant Messaging SPI for plugging in authentication mechanism's at the server side through SASLRealm. You can implement custom SASL mechanisms as implementations but you will then need an Instant Messaging client that supports this custom mechanism. The Sun Java System Instant Messaging client supports only SASL Plain, jabber:iq:auth (both insecure).

For more information, see Chapter 12, Securing Instant Messaging Using TLS and Legacy SSL, in Sun Java System Instant Messaging 7.2 Administration Guide.

Providing Instant Messaging Client Access Through a Firewall

The XMPP/HTTP Gateway (httpbind) provides Instant Messaging access to XMPP-based clients, such as HTML based clients, and clients that are behind firewalls that allow HTTP traffic only and don't permit XMPP traffic. The gateway proxies Instant Messaging traffic to the XMPP server on behalf of HTTP clients.

When planning to use the XMPP/HTTP Gateway, keep in mind the following:

Protecting the Instant Messaging Archive

Instant Messaging has the capability to archive instant messages for later retrieval and searching. If you enable the email archive, you need to decide which administrators will receive email containing archived instant messages. You can configure a separate list of administrators to receive polls, news, conference, alerts, or chat sessions. You can also configure Instant Messaging to use the extended RFC 822 header. Doing so allows mail clients to filter messages based on the header content. If you do enable the Portal archive, you can decide which administrators can access the Portal archive database.

For more information, see Chapter 18, Managing Archiving for Instant Messaging, in Sun Java System Instant Messaging 7.2 Administration Guide.

Planning Instant Messaging User Authentication

User authentication enables your users to log in through their Instant Messaging clients to chat and access other features of Instant Messaging.

Instant Messaging and Passwords

User IDs and passwords are stored in your LDAP directory. Password security criteria, such as minimum length, are determined by directory policy requirements. Password security criteria is not part of Instant Messaging administration. See the Directory Server documentation to understand directory server password policies:

http://docs.sun.com/coll/1316.1

Instant Messaging and LDAP

All deployments of Instant Messaging require a directory server. In a deployment without Access Manager, the Instant Messaging server uses the directory server to perform end-user authentication and to search for end users. For various ways to secure the directory, see the Directory Server documentation.

In a deployment with Portal Server, the Instant Messaging server uses the directory used by Portal Server. When installed in an Access Manager deployment environment, the Instant Messaging server uses the directory used by the Access Manager to search for end users, and not for end-user authentication. In an Access Manager deployment, Access Manager performs the authentication.

If you use an LDAP directory to maintain your user namespace, the default configuration makes the following assumptions regarding the schema used by this directory:


Note –

Some user attributes might contain confidential information. Ensure that your directory access control is set up to prevent unauthorized access by non-privileged users.


Instant Messaging and Searching the Directory Anonymously

Instant Messaging needs to be able to search the directory to function correctly. You need to ensure that your directory is configured to be searchable by anonymous users. If your directory is not readable or searchable by anonymous users, you must take configuration additional steps.

For more information, see Chapter 11, Managing Instant Messaging’s LDAP Access Configuration, in Sun Java System Instant Messaging 7.2 Administration Guide.

Planning Instant Message Privacy, Security, and Site Policies

Instant Messaging provides the ability to control access to Instant Messaging features and preserve end-user privacy.

Instant Messaging Site Policies

Site policies specify end-user access to specific functionality in Instant Messaging. When developing your site policies for Instant Messaging, keep in mind the following questions:

For more information, see Chapter 17, Managing Instant Messaging and Presence Policies, in Sun Java System Instant Messaging 7.2 Administration Guide.

Methods of Controlling Instant Messaging End User and Administrator Privileges

Different sites using Instant Messaging server have different needs in terms of enabling and restricting the type of access end users have to the Instant Messaging service. The process of controlling end user and administrator Instant Messaging server features and privileges is referred to as policy management. You choose from two methods of policy management: through access control files or through Sun Java System Access Manager.

If your deployment does not include Access Manager, you must use the access control file method to manage policies. If you are using Access Manager with Instant Messaging, and you have installed the Instant Messaging and Presence services components, you can use either of the policy management methods. Managing policies using Access Manager is a more comprehensive method. One advantage of this method is that it allows you to store all end-user information in the directory.

For more information, see Chapter 17, Managing Instant Messaging and Presence Policies, in Sun Java System Instant Messaging 7.2 Administration Guide.