Security planning

When planning an IBM® Sametime® deployment, review the following security features and best practices to ensure that your clients, servers, and data are protected.

Securing the LDAP directory

Secure the LDAP connection on each Sametime WebSphere® component with the TLS protocol to encrypt network traffic. Each Sametime WebSphere component connecting to LDAP must also have a secure LDAP connection. After each Sametime WebSphere component is installed, follow the steps in this documentation to secure the component using an installed SSL root certificate.

Securing the DB2® server

Sametime fully supports SSL connections to the deployment's IBM DB2 server. For more information, see the IBM technote How do I enable SSL encryption for DB2 Connections for WebSphere-based applications and datasources?.

Securing WebSphere Application Servers

Each Sametime server that runs on IBM WebSphere Application Server supports TLS/SSL encryption and is installed using self-signed SSL certificates. In a production environment, you should install SSL certificates from a trusted Certificate Authority for any server that accepts connections from clients (for example, the Sametime Proxy Server, Sametime Meeting Server, Sametime Media Manager components, and the Sametime Advanced Server).

The SSL certificates can then be used to encrypt HTTPS (secure http) and SIPS (secure SIP) traffic. Network deployment installations share a common global-security and SSL configuration, and share the trusted-root certificates by design. Cell installations manage their own global-security and SSL configuration for each server installed as a cell deployment, as the servers have a common trusted-root certificate.

Securing Sametime servers

Sametime System Console
The Sametime System Console is a Web-based application that provides a central location for installing, configuring, administering, and monitoring the Sametime family of products. In an enterprise deployment, the console can be installed on a dedicated computer. This computer also becomes the deployment manager in a clustered environment, managing activity in all server clusters in the Sametime environment. By default, the Sametime System Console redirects to HTTPS once the administrator logs in. The Sametime System Console is secured with a self-signed certificate that does not need to be replaced with a certificate from a trusted Certificate Authority.

You can create additional administrators to administer the Sametime System Console.

Sametime Community Server
A Sametime community is a group of people belonging to the same user registry, such as a corporate directory.

Sametime server applications access the Sametime Community Server directly through trusted IPs. The Community Server authenticates these connections by checking the IP address from which the connection originates and ensuring that the address is listed in the Allowed IPs configuration list (configured in IBM Domino®). A stand-alone Sametime Community Mux frees the Community Server from the burden of managing live client connections. The Sametime Community Mux is dedicated to this task. Configuring a stand-alone Community Mux enables the Community Server to handle a larger number of users and improves its stability.

Users must provide credentials by means of the Sametime client to the Community Server when logging on to Sametime. Sametime Browser Client users present their credentials by means of a Sametime Proxy Server. Credentials are authenticated against user records stored in an LDAP directory using a bind API.

Sametime supports both LTPA and LTPA2 tokens. The LTPA token can be created by IBM Domino or WebSphere Application Server to authenticate users for SSO and contains the name of the user who has been authenticated. When the LTPA token is created, it places the distinguished name of the user in the token by default. This scenario typically occurs in user configurations in which there are multiple directories used by various servers participating in SSO, but it can also be used with a single directory.

There are many cases in which a server component must connect to another, for example, server-to-server, server-to-multiplexer, and server application-to-hub connections. The Community Server authenticates these connections by checking the IP address from which the connection originates and ensuring that the address is listed in the Allowed IPs configuration list (configured in IBM Domino).

Another option for server-server authentication (as well as server-to-multiplexer and server application-to-hub) is to enable TLS between the servers, with mutual authentication and trusted certificate hosts.

Encryption is handled via RC2 with a 128-bit key, and keys are generated by use of Diffie-Hellman for each logical channel in use. There can be many logical channels in use on a single TCP connection. Logical channels are used in the cases of communication from:
  • Client to server
  • Client to client, using the server as an application-layer router, as with instant messaging
  • Server to server, to satisfy the requirements of distributed processing and clustering
In all these scenarios, the data is fully encrypted.

Sametime connections that are TLS-enabled no longer use the Diffie-Hellman and RC2 mechanism for encrypting connection traffic.

Sametime Meeting Server
HTTP-based Sametime Meetings can be used to access the Sametime Meeting Room Center from web browsers or from the Meetings panel in the Sametime Connect Client. The Sametime Meeting Server runs on WebSphere Application Server and provides enhanced audio and video features when used in combination with the Sametime Media Manager. The Meeting Server uses form-based authentication, using WebSphere's built-in authentication handlers. Securing the Meeting Server is a two-step process: configure the server to support TLS encryption, and force all web traffic to use TLS encryption. Both steps must be completed to ensure a secure server infrastructure.
Meeting rooms are password protected, and room owners are provided with control to manage users in their room before, during, and after the meeting. Meeting room passwords are stored as a "hashed" form of the plain-text password. Administrators can enable managed access to rooms so that participants can join a room only when a room manager is present, and managers can eject users from the room at any time. When the last manager for a meeting room leaves the room, other users may remain in the room, but no other new user can join the room. Administrators can turn off managed access so that users can set access to each room based on their needs. This can be done dynamically from within the meeting room, or specified when the user creates the room. When the managed access setting is off, the room is open to anyone at all times (password protection of the meeting room still applies). The new user-ejection feature allows a user to be chosen from the participant list and ejected from the room. There is also a way to eject all users, which can be useful in large meetings (where the participant list is hidden), or at the end of a meeting.
Sametime Proxy Server
The Sametime Proxy Server runs on WebSphere Application Server and requires a Sametime Community Server. The Sametime Proxy Server communicates with the Community Server, Meeting server, and Sametime Unified Telephony server or other TCSPI-enabled server. By default the Sametime Proxy Server supports SSL encryption to secure the HTTP traffic between the Web client and Sametime Proxy Server. Once the server is set up to support TLS encryption, it is recommended that you force HTTP traffic over HTTPS to ensure all client connections will be encrypted. The Sametime Proxy Server does not authenticate the user; instead, it passes the authentication off to the Community Server.
Sametime Advanced Server
The Sametime Advanced Server allows users to create persistent chats, some of which are open to all users (including anonymous users) and other chats that have restricted access. In addition to persistent-chats access control, there is a folder hierarchy that is also restricted with access control. The levels of access control within a folder are manage, write, and read. Users with manage access can do anything to or inside that folder, including create, update, and delete of any chats or folders. Users with write access within a folder can create or delete elements under the current folder but cannot manage the folder itself---or other assets that other users have created. Users with read access can view the folder but cannot edit it in any way.

Chats support two access levels. Owners/managers of a chat can both enter the chat and edit the chat. Readers of the chat can only enter that chat. Read access to a chat is synonymous with visibility, so if a user does not have read access to a chat, then they cannot see that it exists. For Sametime communities, there is a role called Community Creators, and any user who is in this role can create/delete communities. Communities, like chats, have both managers and readers. Only managers of a community can delete the community, and the creator of a community is implicitly a manager. Sametime Advanced Server uses the MQTT protocol to provide a persistent connection for publish/subscribe functionality; MQTT can be secured by SSL.

Sametime Media Manager
The Sametime Media Manager provides audio and video services for chats and meetings. It uses features of WebSphere Application Server including scalability, security, and high availability with clustering. The SIP protocol supports point-to-point and multipoint calls. The Media Manager supports standard audio and video codecs, and works with devices from other audio and video vendors. Components can be configured with TLS encryption to secure the SIP communications used in audio and video sessions.
There are four components that make up the Media Manager:
  • SIP Proxy/Registrar
  • Conference Manager
  • Video MCU
  • Video Manager

Install Media Manager components in the same cell to avoid having to swap certificates.

Authentication:

The Sametime rich client and browser client open a socket connection to the SIP Proxy/Registrar that is configured with security constraints by default. This validates the originator of a request, to make sure it is sent by a Sametime user. Credentials are then sent in a SIP REGISTER request over a TLS secured connection. The SIP Proxy/Registrar determines whether the authenticated user is authorized to modify registrations for the specified address of record. Authentication and authorization without TLS enabled is not supported.

The SIP Proxy/Registrar server supports the following authentication mechanisms:
  • Basic authentication: user name and password
  • LTPA-token-based authentication: both LTPA v1 and LTPA v2 are supported. An LTPA token can be created by IBM Domino or WebSphere Application Server to authenticate users for SSO and contains the name of the authenticated user.
  • Anonymous access: allows participants who are not a part of the organization's directory to join a call and participate in the audio/video session. This is useful for collaborating with clients/partners outside of the organization.
The Community Servers and SIP Proxy/Registrar servers must be configured with the same LDAP repositories, and for LTPA-token-based authentication to work properly, SSO must be configured between Sametime servers.

Media Manager server components register with the SIP Proxy/Registrar server, which authenticates these registrations by checking the IP address and ensuring that the address is in the trusted IPs list (configured in WebSphere Application Server hosting the SIP Proxy/Registrar application). The traffic between LDAP and SIP Proxy/Registrar servers is encrypted by use of SSL. Meeting services allow users to access the integrated audio/video capability from both the Sametime rich client and the Sametime Web client. An anonymous user is able to access audio/video capabilities when accessing an online meeting from the Web; however, the number of anonymous users who can log into the Media Manager is limited.

Sametime Bandwidth Manager
The Sametime Bandwidth Manager controls the bandwidth used in audio and video calls that are handled by the Media Manager. The Bandwidth Manager client is built into the Sametime Connect Client, Sametime Browser Client, and Embedded Client, so its features are installed automatically. Sametime Bandwidth Manager can use TLS encryption for security. In WebSphere Application Server, the TLS functionality requires a certificate issued by a valid Certificate Authority (CA) for any production environment. Because the Bandwidth Manager exchanges information with the Sametime Media Manager, you must import a copy of the certificate to the Media Manager cell's default trust store to ensure that communication from the Bandwidth Manager is accepted.
Sametime Gateway
Sametime Gateway Server runs on WebSphere Application Server and is a platform for sharing presence and real-time collaboration with external instant-messaging communities. It supports the standard Extensible Messaging and Presence Protocol (XMPP) and can be configured using TCP, TLS, Simple Authentication and Security Layer (SASL), or dial-back security protocols.s
For an added layer of security, consider deploying Gateway servers using a dual DMZ configuration. For more information see the following guides, located in the Sametime wiki:
  • Deploying DMZ Secure Proxy Server for Sametime Gateway

    Unlike a traditional proxy server, the DMZ Secure Proxy is designed for use outside the corporate firewall and incorporates a higher level of security to protect your deployment. For example, the DMZ Secure Proxy Server does not include an application server or a web container; limiting the software on the server helps protect it from unauthorized access. External users can access only the DMZ Secure Proxy Server, which requests for data to the Sametime Gateway servers, which in turn connect to the Sametime Community Servers on the corporate intranet before routing data back to the users.

    Note: The IBM WebSphere DMZ SIP Proxy Server has been stabilized in the WebSphere Application Server 8.5.5.x stream -- this feature is supported, but no more new features or significant changes can be added. Beginning with WebSphere Application Server Version 9, the DMZ SIP Proxy Server is deprecated and will not be supported for use in Sametime Gateway deployments.
  • Deploying a DMZ XMPP proxy server for Sametime Gateway

    The DMZ XMPP proxy server is the same J2EE application that Sametime Gateway uses for the conventional XMPP server. The difference is how you deploy it: you deploy the DMZ XMPP server in a different cell from Sametime Gateway, and you set up a firewall between the Gateway servers and the DMZ XMPP proxy server. The use of a separate cell and an additional firewall provide added security to your deployment.

Other components

Sametime TURN Server
The IBM Sametime TURN Server enables Sametime clients to send audio/video communications across a NAT or firewall when direct peer-to-peer communications are not possible. The TURN Server implements the TURN (RFC 5766) and STUN (RFC 5389) protocols and performs two main functions:
  • Assists the client (using ICE, RFC 5245) in finding its public address
  • Provides an extension, or relay, to the client.
The client uses the TURN Server as a relay to send packets to these peers and to receive packets from the peers when peer-to-peer communication is not possible. Sametime clients connect to the TURN Server using UDP or TCP. The TURN Server keeps a list of permissions that consist of an IP address and an associated time-to-expiry. While permission exists, all peers using the IP address in the permission list are allowed to send data to the client.
IBM SIP Edge Proxy Server
The IBM SIP Edge Proxy Server is deployed in the DMZ where Internet-based clients can connect to it. The SIP Edge Proxy Server then tunnels through the firewall and connects to the internal Media Manager. Using the SIP Edge Proxy Server enhances your deployment security in the following ways:
  • It maintains a persistent connection with the client.
  • It supports the use of TLS encryption for SIP traffic.
  • It forwards all incoming requests to the internally deployed Sametime SIP Proxy/Registrar for authentication.
Mobile clients
Android and iOS clients use the Sametime Proxy Web client and have specially designed web pages.
Connect client
The Connect client offers integrated meeting capability along with audio/video call options and uses the IBM Expeditor accounts framework to provide authentication.
FIPS 140-2 support
Sametime supports the US government-defined security requirements for cryptographic modules known as Federal Information Processing Standard (FIPS) 140-2. All data transferred between Sametime clients and the Sametime server is protected with the FIPS 140-2- certified SSL cipher suite. Communications between mobile MQTT clients and the Sametime Proxy Server are protected by SSL, which uses FIPS-approved ciphers.
Microsoft™ Office Integration
Microsoft Office Integration features interact with the Sametime client through the STHelper COM object. STHelper exposes a simple API to its consumer and resolves requests when an email is selected in Microsoft Outlook or when the Chat button is invoked from the Outlook toolbar. STHelper uses a TCP/IP publish/subscribe bus (the MicroBroker) to communicate with Office and SharePoint components.

Single sign-on authentication mechanisms used in Sametime

Single sign-on enables a user to log in once and access multiple servers without being challenged again. When a user logs in, the Community Server generates an LTPA token and shares it within the Sametime deployment so that the user is not prompted to log in again during the same session. When possible, all applications such as IBM Sametime and IBM Connections should share the same LTPA keyset and LDAP configuration to simply access for users.

SPNEGO
If your deployment uses Microsoft Active Directory, you can configure SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) to provide single sign-on (SSO) authentication.
WebSEAL
IBM Security Access Manager WebSEAL is a high performance, multi-threaded Web server that applies a fine-grained security policy to the protected Web object space. WebSEAL can provide single sign-on solutions and incorporate back-end Web application server resources into its security policy. Requests passing through WebSEAL are evaluated by the Security Access Manager to determine whether the user is authorized to access the requested service or data.
SiteMinder
Sametime supports the use of Computer Associate's SiteMinder application for policy-based authentication and single sign-on.