Why would you want to protect your Sametime installation with ISAM WebSeal ?

The Sametime Proxy is used to supply chat and online awareness functionality in web applications , and to support the Sametime Mobile application.

  • Enhance security by adding a security reverse proxy (SSL , central authentication)
  • Handle Single Sign on with your other web applications (eg. WebSphere Portal or IBM Connections)
  • Do SSL offloading : move the overrhead of decrypting/encrypting SSL traffic to your revere proxy

Sametime versions

This document is valid for Sametime 8.5.2IFR1 and 9.0

Sametime mobile

Sametime Mobile is the mobile application available since 8.5.2 , that users can download directly from the Google or Apple appstores.

Sametime Mobile on Android : https://play.google.com/store/apps/details?id=com.ibm.android.sametime Sametime Mobile on iOS : https://itunes.apple.com/us/app/ibm-sametime/id472303810

The current version is around 9.0 - even if you use Sametime 8.5.2IFR1 on your servers.

Sametime Proxy 8.5.2IFR1

To surface the Sametime chat components to your users through WebSeal, specifically for the Sametime Proxy component, there’s some things you need to know

  • you need WebSeal LTPA Transparent Path junctions or Virtual Host junctions
  • for authentication with the sametime webclient components , you can use Form Based Authentication or even stronger methods (certificates,…)
  • the mobile application only supports Basics Authentication
  • the business card setup is a bit fiddly and limits what you can do
  • you can use WebSeal load balanced junctions to load balance multiple ST Proxy servers, or you can use a load balancer.
  • you cannot use the same hostname on WebSeal for your Sametime Meeting servers and for your Sametime Proxies (may be fixed in Sametime 9.0)
  • your Sametime environment needs to use the same LDAP as your TAM does. OK, not strictly true, but you do need to have the same structure for your users : the DN for a particular user in TAM needs to be identical to the DN of the user in your LDAP. This means, if the user is known as uid=user1,ou=department,o=yourcompany on TAM, he needs to have the same DN on your Sametime LDAP. This also means you may have restrictions on what LDAP you can use . I’m not going to go in detail about this here, contact me is you need more information.
  • Consult this wiki on how to configure WebSeal : http://www-10.lotus.com/ldd/stwiki.nsf/dx/Configuring_IBM_Tivoli_Access_Manager__WebSEAL_transparent_junctions_to_work_with_an_IBM_Sametime_environment. Unfortunately, the wiki is incomplete.

Setup

There’s 2 parts in the setup : the setup for the Saemtime webclient (http://yourserver.com/stwebclient/index.jsp) and the setup for the mobile client. There does not need to be SSO between them, since they really serve separate purposes.

Sametime webclient

You will need to create the following Transparent Path junctions on your WebSeal instance that supports Form Based authentication (or stronger)

/stwebclient
/stwebapi (it depends if you need this here - see below)
/stwebav
/stbaseapi
/stmobile

See the link above on the details on how to create these junctions. You must use LTPA junctions, TAI is not supported.

Sametime Mobile

You will need to create the following Transparent Path junctions on your WebSeal instance that supports Basic Authentication :

/stwebapi
/stmobile (not really necessary)

Put everything together

Now there are a couple of potential issues here : you need the same junction to be available both on the Form Based and the BA instance.

Options

  • different hostnames : if you use a separate hostname for your Mobile application (Basic Instance) and your ST WebClients, the technical problem is solved. You don’t need SSO between the 2.
    Your mobile clients need to enter mobile.yourcompany.com to access the BA junctions, to access the sametime webclient in a browser, you need proxy.yourcompany.com. Since you’d probably don’t want your users to access the webclient directly but rather in context of other webapplications (for instance, online awareness in your iNotes inbox), you only need to communicate the mobile url.
    The downside is that you need a separate SSL certificate for the 2.

  • single hostname : to my knowledge, you cannot make Basic Authentication and Forms based authentication work in a single instance in WebSeal (correct me if I’m wrong).
    To make the setup work , you will need a solution in front of WebSeal that can direct your trafic to the correct instance based on URI patterns (see the junctions) or something else (for instance the user-agent )

URI Pattern

BA Instance           /stwebapi and /stmobile  
Form based instance    /stwebclient, /stwebav and /stbaseapi

Unfortunately, the webclient also uses /stwebapi. So you will need an SSO mechanism between your Form based instance and your BA instance. You can use WebSeal solutions like failover cookies or e-communities for single sign on.

User-agent or other mechanism

BA Instance           /stwebapi and /stmobile  
Form based instance    /stwebapi, /stmobile, /stwebclient, /stwebav and /stbaseapi

In a setup like this, you do not need Single Sign on between the 2 instances, or at least not for default functionality. So this solution seems the most interesting, but there’s a catch. See the next chapter.

Business Card for the Mobile app : Photos behind a url that requires authentication

A big difference with traditional (pre - 8.5.2IFR1) Sametime deployments is the new Mobile app. This profoundly changes the way you want to provide access to your Sametime (chat) environment.
Because if you want photos with your business cards, you need to make them available through an url that does not require authentication …. something you may not want to do : you would need to put the pictures of your employees on the internet … unprotected … this may even not be allowed by privacy laws in your region !

BTW, you MUST use the PhotoURL field in LDAP here, there’s no way to use a Domino database for your ST Proxy users photos.

Fortunately , there is a solution (in fact, there are several, based on what version of Sametime you’re using)

Sametime 8.5.2

The mobile application does not forward cookies to the PhotoURL url, but it does forward the BA header. So you can create a separate junction on your Basic Authentication WebSeal instance to serve your photos :
For instance, if your photos are on a webserver , in a directory named /photos , you can create a Transparent Path junction on the BA instance (/photos), apply an ACL so you need to authenticate.
Then , if your mobile hostname is “mobile.yourcompany.com” (the BA instance’s hostname), you need to set a PhotoURL on all your user’s ldap records something like this “https://mobile.yourcompany.com/photos/.jpg” .
This way, your photos are protected and still accessible for your Mobile App users.
Now here’s the catch mentioned in the section “User-agent or other mechanism” : if you also want those photos in the ST WebClient, you WILL need single sign on between the BA instance and the Form Based instance - otherwise you will be prompted with an ugly Basic Authentication prompt.

Sametime 9.0

There’s an undocumented feature in Sametime 9.0 Proxy that allows you to serve the photos through the STProxy server:
From the SSC -> Servers -> STProxy, scroll down to the end of the configuration page and tick the box “enable user photo cache”. The proxy will download the photos from url in the PhotoURL field, and it still needs to be unauthenticated.
But the URL does not have to be made available on the internet - it’s just your STProxy that needs to be able to connect to that URL.