Sun Java Communications Suite 5 Deployment Planning Guide

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:

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.