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
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.
- 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.
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.sFor 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.
- Deploying DMZ Secure Proxy Server for Sametime Gateway
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.
- 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.