| Oracle® Communications Instant Messaging Server Installation and Configuration Guide Release 9.0.2 E53651-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Instant Messaging Server Installation and Configuration Guide Release 9.0.2 E53651-01 |
|
|
PDF · Mobi · ePub |
This chapter provides information about planning your Oracle Communications Instant Messaging Server installation. It also describes the Instant Messaging Server logical and physical architectures.
Note:
As of Instant Messaging Server 9.0.2, support for Access Manager has been removed.Instant Messaging Server enables secure, real-time communication and collaboration, combining presence awareness with instant messaging capabilities such as chat, conferences, 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 Server ensures the integrity of communications through its multiple authentication mechanisms and Secure Sockets Layer (SSL) connections. For more information about Instant Messaging Server, see Oracle White Paper—Oracle Communications Instant Messaging Server at:
http://www.oracle.com/us/industries/communications/oracle-instant-messaging-wp-1449642.pdf
Instant Messaging Server consists of the following internal core components that must integrate and inter-operate with external services to provide an instant messaging environment.
Instant Messaging Server. The Instant Messaging server component provides core services required for real time communications such as the presence engine, message handling and routing, roster management, security and authorization. The Instant Messaging server supports the connection of an Instant Messaging multiplexer that concentrates connections over one socket.
Instant Messaging Multiplexor. The Instant Messaging multiplexer adds scalability to the Instant Messaging environment. You can install multiple multiplexers as needed, depending on your configuration. As the user population grows beyond what is easily supported by a single Instant Messaging server, you can deploy additional servers to which you can connect additional multiplexers.
Access, Communication, and Transfer Protocols. These protocols, such as LDAP, HTTP, TCP/IP, and SMTP, can be found in "Instant Messaging Server Supported Standards".
Instant Messaging API. Enables you to create custom Instant Messaging clients.
Instant Messaging Server provides the following gateways to enable connectivity to other systems:
XMPP/HTTP Gateway. Enables Instant Messaging Server to provide access to HTTP-based clients, such as HTML-based clients, and clients behind firewalls that allow HTTP traffic, but do not permit XMPP traffic. The gateway proxies instant messaging traffic to the XMPP server on behalf of HTTP clients.
SMS Gateway. Enables Instant Messaging Server to deliver chat messages and alerts in the form of SMS to offline users.
SIP Gateway. Instant Messaging Server implements a SIP/SIMPLE (Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions/Session Initiation Protocol) gateway, enabling federation and translation between the two protocols, and interoperation between XMPP and SIP/SIMPLE servers.
Facebook Gateway. Enables Instant Messaging Server users to interact with the Facebook Instant Messaging Service.
The software components discussed in this section work with Instant Messaging Server, but are installed separately. See "Planning Your Instant Messaging Server Installation" for more information on how these components interact with Instant Messaging Server.
(Required) Instant Messaging Server uses an LDAP server, such as Directory Server, for end user authentication and search. If you do not have an LDAP directory already installed, you must install one. This directory can either be dedicated for use by Instant Messaging Server, or be shared by other components.
The Instant Messaging server does not store the Instant Messenger end-user authentication information. This information is stored in the LDAP server.
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 Server 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 Instant Messaging Server System Administrator's Guide.
Note:
Because a proper Directory Server implementation is instrumental to a successful Instant Messaging Server deployment, see the Directory Server documentation at:http://www.oracle.com/technetwork/documentation/legacy-sun-identity-mgmt-193462.html
(Optional) You may need to install a web container, such as Web Server or GlassFish Server. You can also use any open standard web server (for example, Apache).
Instant Messaging Server 8 and previous versions require a web container to serve the Instant Messenger resources. The Instant Messenger resource files include:
The index.html file, provided by Instant Messenger, or a home page with a link to invoke Instant Messenger
Instant Messenger jar files (messenger.jar, imres.jar, imbrand.jar, imdesktop.jar, imnet.jar, and imjni.jar)
The Instant Messenger Online Help
You must install Instant Messenger resources on the same host where the web container is installed. 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 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.
This section lists national, international, industry, and de-facto standards related to electronic messaging and for which support is claimed by Oracle Communications Instant Messaging Server. Most of these are Internet standards, published by the RFC Editor and approved by the Internet Engineering Task Force (IETF). Standards for documents from other sources are noted.
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-1 shows the supported XMPP Extensions.
Table 2-1 Supported XMPP Extensions
| Number | Name | Comments |
|---|---|---|
|
XEP-0004 |
Data Forms |
No comments |
|
XEP-0016 |
Privacy Lists |
No comments |
|
XEP-0022 |
Message Events |
No comments |
|
XEP-0030 |
Service Discovery |
No comments |
|
XEP-0045 |
Multi-User Chat |
No comments |
|
XEP-0047 |
In-Band Bytestreams |
No comments |
|
XEP-0048 |
Bookmarks |
No comments |
|
XEP-0049 |
Private XML Storage |
No comments |
|
XEP-0054 |
vcard-temp |
No comments |
|
XEP-0055 |
Jabber Search |
No comments |
|
XEP-0065 |
SOCKS5 Bytestreams |
No comments |
|
XEP-0066 |
Out of Band Data |
Implemented by Client |
|
XEP-0071 |
XHTML-IM |
Implemented by Client |
|
XEP-0077 |
In-Band Registration |
No comments |
|
XEP-0078 |
Non-SASL Authentication |
No comments |
|
XEP-0079 |
Advanced Message Processing |
No comments |
|
XEP-0085 |
Chat State Notifications |
Implemented by Client |
|
XEP-0092 |
Software Version |
No comments |
|
XEP-0095 |
Stream Initiation |
No comments |
|
XEP-0096 |
SI File Transfer |
No comments |
|
XEP-0100 |
Gateway Interaction |
No comments |
|
XEP-0106 |
JID Escaping |
No comments |
|
XEP-0114 |
Jabber Component Protocol |
No comments |
|
XEP-0124 |
Bidirectional-streams Over Synchronous HTTP (BOSH) |
No comments |
|
XEP-0126 |
Invisibility |
No comments |
|
XEP-0153 |
vCard-Based Avatars |
No comments |
|
XEP-0160 |
Best Practices for Handling Offline Messages |
No comments |
|
XEP-0166 |
Jingle |
Implemented by Client |
|
XEP-0167 |
Jingle RTP Sessions |
Implemented by Client |
|
XEP-0177 |
Jingle Raw UDP Transport Method |
Implemented by Client |
|
XEP-0191 |
Simple Communications Blocking |
No comments |
|
XEP-0206 |
XMPP Over BOSH |
No comments |
|
XEP-0107 |
User Mood |
No comments |
|
XEP-0108 |
User Activity |
No comments |
|
XEP-0118 |
User Tune |
No comments |
|
XEP-0163 |
Personal Eventing Protocol |
No comments |
|
XEP-0060 |
Publish-Subscribe |
Partially implemented |
|
XEP-0199 |
XMPP Ping |
No comments |
Figure 2-1 shows the Instant Messaging Server software architecture.
Figure 2-1 Instant Messaging Server Software Architecture
For Instant Messaging Server 9, clients send messages to the multiplexor, which forwards the messages to the Instant Messaging server. However, in Instant Messaging Server 8 and previous versions, a 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.
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, Directory Server can contain user information such as contact lists and subscriptions.
In this basic configuration, Instant Messaging Server 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.
New users are created by adding user entries to Directory Server. 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 Directory Server. You can then assign services to the user. For more information about new user registration for Instant Messaging Server, see the topic on administering end users in Instant Messaging Server System Administrator's Guide.
You administer Instant Messaging Server components through a set of command-line interfaces and text-based configuration files.
Note:
Typical Instant Messaging Server deployments are not installed on a single machine. They also have additional features like multiplexing and high availability enabled. See "Planning Your Instant Messaging Server Installation" for more information.This section contains the following planning topics you must consider before installing Instant Messaging Server:
Planning Instant Messaging Server Privacy, Security, and Site Policies
Planning for Email Notification (Calendar Alert) Architecture
Instant Messaging Server supports Transport Layer Security (TLS). (Support for legacy SSL was removed in Instant Messaging Server 9.0.2.) 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. The Instant Messaging client supports only SASL Plain, jabber:iq:auth (both insecure).
See Instant Messaging Server Security Guide for more information on using TLS.
User authentication enables your users to log in through their Instant Messaging clients to chat and access other features of Instant Messaging.
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 Server administration. See the Directory Server documentation to understand directory server password policies.
All Instant Messaging Server deployments require a 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.
The default Instant Messaging Server configuration makes the following assumptions regarding the schema used by this directory:
End user entries are identified by the inetOrgPerson object class.
Group entries are identified by the groupOfUniqueNames or groupofURLs object class.
Instant Messenger user ID attribute of an end user is provided by the uid attribute (from inetOrgPerson objectclass).
The email address of an end user is provided by the mail attribute.
The display name of an end user or group is provided by the cn attribute.
The list of members of a group is provided by the uniqueMember attribute (groupOfUniqueNames object class).
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 Server 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 Instant Messaging Server Security Guide.
Instant Messaging Server provides the ability to control access to Instant Messaging Server features and preserve end-user privacy.
Site policies specify end-user access to specific functionality in Instant Messaging Server. When developing your site policies for Instant Messaging Server, keep in mind the following questions:
Can users access the presence status of other end users?
Can users send alerts to other end users?
Do you want users to save properties on the server?
Who do you want to be able to create and manage conference rooms?
Who do you want to be able to create and manage news channels?
For more information, see Instant Messaging Server Security Guide.
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 can manage policies to adjust end-user privileges in the following areas: news channel management, conference room management, the ability to change preferences in the User Settings dialog, and ability to send alerts. It also enables specific end users to be assigned as system administrators.
For more information, see Instant Messaging Server Security Guide.
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.
The basic Instant Messaging Server architecture provides such functionality as presence, roster management, chat, news alerts, and conferences. To provide this basic functionality, you need to install the following components:
Instant Messaging server and one or more Instant Messaging multiplexors:
LDAP server such as Directory Server
In the basic architecture:
The LDAP server provides user entries for authentication and lookup.
The clients download the Instant Messaging resources from either a web server or Application Server
Clients always connect to the Instant Messaging server through an Instant Messaging multiplexor.
Figure 2-2 shows the interaction of the software components in the authentication process of a basic architecture of Instant Messaging Server. The focus is on the flow of authentication requests. An explanation of the steps in this process follows the figure.
Figure 2-2 Flow of Authentication Requests in a Basic Instant Messaging Server Architecture
The authentication process in a basic architecture works as follows:
End user accesses the Instant Messenger applet URL from a browser and chooses a method to invoke the client.
The browser invokes Java Web Start or the Java plugin.
Java Web Start or the Java plugin downloads the necessary Instant Messenger resource files and starts Instant Messenger.
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.
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.
Figure 2-3 shows an Instant Messaging Server deployment that supports email notification to offline users, as well as Instant Messaging based notification of calendar events to users.
An Instant Messaging Server 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 "Planning for a Basic Installation". To support email alerts, you also install an SMTP server such as Oracle Communications Messaging Server. To support calendar alerts, you also install Oracle Communications Calendar Server.
Figure 2-3 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. See "Authentication in a Basic Architecture" for more information.
In this example:
The LDAP 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.
The clients download the Instant Messaging resources from a web server (or application server).
Clients always connect to the Instant Messaging server through an Instant Messaging multiplexor.
Figure 2-4 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-4 Instant Messaging Architecture with Calendar Alerts
In this example:
The LDAP server provides user entries for authentication and lookup.
The Event Notification Server (ENS) sends notifications of calendar events to the Instant Messaging server which then forwards the notification on to the appropriate end user.
The clients download the Instant Messaging resources from a web server (or application server).
Clients always connect to the Instant Messaging server through an Instant Messaging multiplexor.
To deploy Instant Messaging Server and enable all the features listed in this section, you must first install the following components prior to installing Instant Messaging Server:
Directory Server
Web Server
Calendar Server
Messaging Server
This section contains the following system-level planning topics you must consider before installing Instant Messaging Server:
Configuring Instant Messaging Server for high availability (HA) provides monitoring and recovery from software and hardware failures. The HA feature is implemented as a failover data service and not as a scalable service. This feature is supported only on the Oracle Solaris operating system.
For more information, see the topic on configuring Instant Messaging Server for HA in Instant Messaging Server System Administrator's Guide.
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 and legacy SSL. If you want legacy SSL support, enable SSL on the Web Server port. If you want startTLS support, enable startTLS on the server and 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.
Instant Messaging Server 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.
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
Instant Messenger resources
The configuration information is stored in the configuration directory (InstantMessaging_cfg). The Instant Messaging data is stored in the database directory (InstantMessaging_database).
The Instant Messenger resources must be backed up if they have been customized. The location of the Instant Messenger resources are provided during installation.
For more information on backing up your Instant Messaging Server deployment, see Instant Messaging Server System Administrator's Guide.
This section explains variations to the deployment scenario described in "Planning for a Basic Installation". For example, you can install the various required servers and components in the following physical configurations, or any combination of each example:
Figure 2-5 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 2-5 Separate Web Server and Instant Messaging Hosts
Figure 2-6 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-6 Instant Messaging Multiplexors Installed on Separate Hosts
Note:
The multiplexor can be resource-intensive, so putting it on a separate host can improve the overall performance of the system.Figure 2-7 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-7 Multiple Instant Messaging Server Hosts
In conjunction with the TLS protocol, Instant Messaging Server provides client-to-server and server-to-server encrypted communications as well as certificate-based authentication between servers. For information about secure installation and configuration of Instant Messaging Server, see Instant Messaging Server Security Guide.
|
 Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
