2 Planning Your Instant Messaging Server Installation

Directory Server

(Required) Instant Messaging Server requires a directory server, such as Oracle Directory Server Enterprise Edition or Oracle Unified Directory for end user authentication and search, and to store conference rooms. Additionally, if you enable conference history persistence, that too is stored in directory server. This directory can either be dedicated for use by Instant Messaging Server, or be shared by other components.

By default, 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) are stored in the directory server. For instructions on configuring the server to use a non-default attribute for user search, see Instant Messaging Server System Administrator's Guide.

By default Instant Messaging Server uses the directory server to store user properties and data, which includes multiuser chat history. Instead of using the directory server to store multiuser chat history, you can use Oracle Database. For more information on storing multiuser chat history in Oracle Database, see Instant Messaging Server System Administrator's Guide.

Web Container

(Optional) You must install a web container for the Instant Messaging Server components described in Table 2-1.

SMTP Server

(Optional) An SMTP messaging server, such as Oracle Communications 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. The SMTP server does not have to reside on the same host as the Instant Messaging Server host.

Calendar Server

(Optional) Oracle Communications Calendar Server is used to notify users of calendar-based events and also users' presence status while in either an event or a to-do.

Protocols Support by Instant Messaging Server

Instant Messaging Server supports the following protocols:

• Extensible Messaging and Presence Protocol(XMPP):

  • XMPP Core Protocols (RFC 3920, RFC 3921)

  • XMPP Extensions

• Short message peer-to-peer protocol (SMPP)

Table 2-2 lists the supported XMPP Extensions.

Planning to Protect Instant Messaging Server

Instant Messaging Server supports Transport Layer Security (TLS). Instant Messaging Server uses a startTLS extension to the TLS 1.0 protocol for client-to-server and server-to-server encrypted communications and for certificate-based authentication between servers.

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

• You can secure the Instant Messaging Server deployment by enabling SSL on the web container port (either Web Server or Application Server) and accessing Instant Messaging Server functionality by using the XMPP/HTTP Gateway (httpbind).

• Set the proper file and directory permissions for the Instant Messaging Server configuration files (im.conf.xml and httpbind.conf in the InstantMessaging_cfg/config directory):

  • Solaris OS:

    /etc/opt/sun/comms/im/default/config/
    

  • Red Had Linux:

    /etc/opt/sun/im/default/config/
    

    Instant Messaging Server runs as the user specified in the iim.conf.xml file. This user needs read access to the file. If you use httpbind, the user that runs the web container should be able to access the Instant Messaging Server directory path and configuration file. When you create additional Instant Messaging server or multiplexor instances manually, you must also ensure that the file and directory permissions are correct. The default installation sets the file and directory permissions. The default instance directory has the following permissions:

    drwx------   5 root     other        512 Oct 16 14:24 default
    

• Take care while enabling Instant Messaging Server monitoring, as this exposes server statistics that could be considered security issues. The default configuration does not enable the monitoring feature. You enable this property through the iim.conf.xml file.

• Enable debug logging only when needed, as this impacts overall system performance. Though passwords are not logged, the protocol communication between users is logged, which could be a potential security issue.

• When you enable startTLS, use a single server certificate for both client-to-server and server-to-server communication.

• An Instant Messaging Server deployment that leverages LDAP needs proper authentication for access.

The Instant Messaging Server 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.

See Instant Messaging Server Security Guide for more information on using TLS.

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.

Planning for Anonymous Directory Server Searching

Instant Messaging Server needs to be able to search the directory to function correctly. If you want, you can configure your directory to be searchable by anonymous users. To configure your directory to be readable or searchable by anonymous users, see the topic on enabling the directory server searches on a specific user in Instant Messaging Server System Administrator's Guide.

Planning Instant Messaging Server Privacy, Security, and Site Policies

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

Planning to Protect the Instant Messaging Archive

Instant Messaging Server has the capability to archive instant messages for later retrieval and searching. If you enable the email archive, you must decide which administrators are to 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 Server to use the extended RFC 822 header. Doing so enables mail clients to filter messages based on the header content.

Planning for a Basic Installation

The basic Instant Messaging Server architecture provides such functionality as presence, roster management, chat, and conferences. To provide this basic functionality, you must install the following components:

• Instant Messaging server and one or more Instant Messaging multiplexors

• Directory server

In the basic architecture:

• The directory server provides user entries for authentication and lookup.

• Clients always connect to the Instant Messaging server through an Instant Messaging multiplexor.

Planning for Email Notification Architecture and Calendar Alerts

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

Figure 2-2 shows an Instant Messaging Server deployment that supports email notification to offline users.

An Instant Messaging Server architecture that supports email notification provides the same functionality as Basic Instant Messaging Architecture. To provide this functionality, you must include the components listed in "Planning for a Basic Installation". To support email alerts, you also install an SMTP server such as Oracle Communications Messaging Server.

Figure 2-2 Instant Messaging Architecture with Email Notification

Description of ''Figure 2-2 Instant Messaging Architecture with Email Notification''

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

Authentication flow in this architecture is the same as in a basic deployment.

In this example:

• The directory server provides user entries for authentication and lookup.

• The Instant Messaging server forwards messages intended for offline users to the SMTP server. The SMTP server then sends the message as an email to the user's mailbox.

• Clients always connect to the Instant Messaging server through an Instant Messaging multiplexor.

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

Figure 2-3 Instant Messaging Architecture with Calendar Alerts

Description of ''Figure 2-3 Instant Messaging Architecture with Calendar Alerts''

In this example:

• The directory server provides user entries for authentication and lookup.

• Java Message Service (JMS) sends notifications of calendar events to the Instant Messaging server which then forwards the notification on to the appropriate end user.

• Clients always connect to the Instant Messaging server through an Instant Messaging multiplexor.

Planning for High Availability

You can use server pooling to provide high availability (HA) for your Instant Messaging Server deployment. Server pools provide redundancy so that if one server in the pool fails, affected clients can reconnect and continue their sessions through another server in the pool with a minimum of inconvenience. Additionally, if you set up your deployment with load balancers, users can immediately reconnect and be directed by a load balancer to another node in the pool. For more information, see the topic on scaling Instant Messaging Server by using server pooling in Instant Messaging Server System Administrator's Guide.

You can also configure an Instant Messaging multiplexor with a list of Instant Messaging Server hosts for failover. For more information, see the topic on multiplexor failover in Instant Messaging Server System Administrator's 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 do not permit XMPP traffic. The gateway proxies Instant Messaging Server traffic to the XMPP server on behalf of HTTP clients.

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

• Use port 5222 at the Gateway if the Gateway is communicating to the server through a multiplexor. Also, use port server port 5269 if no multiplexor is involved. You can specify port 5222 or 5269 in the httpbind.conf file.

• The XMPP/HTTP gateway supports startTLS. When you enable startTLS on the server, all communications is encrypted.

• Do not expose the Instant Messaging server to direct access. In a typical deployment scenario, locate the multiplexor in the DMZ, and open the multiplexor to server communication port (45222 usually) in the second firewall.

Using Load Balancing

Instant Messaging Server supports the use of load balancers located in front of the Instant Messaging multiplexors.

Planning Backup Strategies

Backing up and restoring data is one of the most important administrative tasks for your Instant Messaging Server deployment. You must implement a backup and restore policy for your Instant Messaging Server deployment to ensure that data is not lost if the system crashes, hardware fails, or information is accidentally deleted.

You must back up the following Instant Messaging Server information:

• Configuration Information

• Instant Messaging end user data

The configuration information is stored in the configuration directory (InstantMessaging_cfg). The Instant Messaging data is stored in the database directory (InstantMessaging_database).

For more information on backing up your Instant Messaging Server deployment, see Instant Messaging Server System Administrator's Guide.

Physical Deployment Example: Multiplexors on Separate Hosts

Figure 2-4 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 Instant Messaging Server across multiple systems.

Figure 2-4 Instant Messaging Multiplexors Installed on Separate Hosts

Description of ''Figure 2-4 Instant Messaging Multiplexors Installed on Separate Hosts''

Physical Deployment Example: Multiple Instant Messaging Hosts

Figure 2-5 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 2-5 Multiple Instant Messaging Server Hosts

Description of ''Figure 2-5 Multiple Instant Messaging Server Hosts''