Planning for single sign-on (SSO)

Configure servers for single sign-on (SSO) as a convenience to users running the Sametime® browser client. With SSO configured, users who log in once to any server in the DNS domain do not have to log in again when they access any other server running on Domino® or WebSphere® Application Server. Enabling SSO between the servers also helps the Sametime Connect Client as well. If the Sametime Community Server is in the SSO domain, the component services can re-use the token from the Sametime Connect Client to login to other services.

The idea behind HTTP single sign-on is to avoid prompting the user multiple times for security credentials within a given trust domain. In a single sign-on (SSO) scenario, an HTTP cookie is used to propagate a user's authentication information to web servers, relieving the user from entering authentication information for every new client-server session (assuming basic authentication).

A best practice is to install and configure all IBM® Domino and IBM Sametime servers and then enable single sign-on for all of them. After the installation of all servers, you can configure SSO. If SSO has already been configured on your environment, verify with the WebSphere administrator which LTPA key was used. To enable single sign-on, you must enable the IBM LTPA capabilities, included in both WebSphere Application Server and IBM Domino. The WebSphere LTPA token generated by WebSphere Application Server is imported into Domino, and this token can be used for all servers within the Domino domain. All servers participating in single sign-on must be in the same Internet domain. To enable single sign-on across multiple Domino domains, import the same WebSphere LTPA token into those Domino domains.

The Sametime Community Server installation creates a Domino SSO key. You must replace the Domino SSO key with a WebSphere LTPA key to allow the Sametime Community Server running on Domino and the other servers running on WebSphere Application Server to have an identical key for token validation and generation. If Sametime servers running on WebSphere Application Server are managed by different Sametime System Console, you must export the LTPA key from one of the servers (the Sametime Media Manager SIP Proxy/Registrar, Sametime Meeting Server, or Sametime Advanced Server).

The Sametime Community Server supports Security Assertion Markup Language (SAML) single sign-on. When this feature is enabled, the Community Server can validate SAML assertions that are generated by a SAML identity provider (idP). This allows a client to authenticate by password to the idP, receive a SAML assertion, and then use that assertion to log in to Sametime, without having to re-enter the password. The Community Server can validate either SAML or LTPA (Lightweight Third-Party Authentication) tokens, but it can only generate LTPA tokens.

SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) is one authentication type for single sign-on (SSO). Sametime and WebSphere Application Server can use a token-based SSO feature that uses SPNEGO. This feature requires the integration of several distinct components that when completed, allows users to log in and authenticate only once at their desktop and thereafter automatically authenticate with the Sametime Community Server. SPNEGO works with the Microsoft™ Active Directory only.

IBM Security Access Manager WebSEAL is the resource manager responsible for managing and protecting Sametime Web-based information. WebSEAL is a high performance, multi-threaded Web server that applies fine-grained security policy to the Security Access Manager protected Web object space. WebSEAL can provide single sign-on solutions and incorporate back-end Web application server resources into its security policy. WebSEAL normally acts as a reverse Web proxy by receiving HTTP/HTTPS requests from the Sametime Browser Client or browser-based meetings client and delivering content from its own Web server or from junctioned back-end Web application servers. Requests passing through WebSEAL are evaluated by the Security Access Manager to determine whether the user is authorized. WebSEAL provides SSO capabilities.

CA Single Sign-On Sametime also works with Computer Associate's Single Sign-On for policy-based authentication and single sign-on.