Sametime photos served up by IHS

Between customer work I have been working on replacing our internal Sametime servers with shiny new 9.0.1 servers using AD instead of Domino LDAP.

The final piece of the puzzle is photos. Anyone who knows Sametime knows that something as simple as a photo is not made simple by the applications. The Sametime Proxy requires an LDAP attribute (PhotoURL) to be used which points STProxy to the image retrieving it for the client. Meetings doesn’t use the same approach, grr. It can use a binary object saved in LDAP or offload the retrieval to a web server like PhotoURL for STProxy but uses a “string” where all photos must be named joe.bloggs@acme.com.jpg. Confusing? Yep.

I was about to roll over and say it’s not possible but it seems that it is possible to cover all use cases.

  1. Notes/Sametime clients using ImagePath URL
  2. STProxy web client using PhotoURL
  3. Meetings off loading to a web server
  4. Stop external access to photos

The nice thing STProxy does is that it will “proxy” the photos so the web browser doesn’t need direct connectivity to the jpgs. That is great because I can put the photos on an internal facing web server. The STProxy then calls the URL specified in the user’s LDAP entry (PhotoURL), caches it locally and then serves it up. Brilliant, I can lock the photos away so that no one can browse them from the internet if they know our email addresses.

You’ll need to update stproxyconfig.xml adding proxyServerURL otherwise it will not work. Don’t forget to sync and restart STProxy.

    <photoCache>
<enabled>true</enabled>
<cacheExpiry>60</cacheExpiry>
<storageLocation>/opt/IBM/phototemp</storageLocation>
<proxyServerURL>https://chat.acme.com</proxyServerURL&gt;
</photoCache>

Ah, the Meeting server doesn’t follow the same logic. Clients (thick or web browser or mobile) need direct access to the photo to render it in the client. This means I’m back to square one….

Let’s jump back a step. How do we get the photos up to a web server?

Photos from Connections

At present our Sametime and Connections servers are using different LDAPs so SSO is not possible and even if it was retrieving photos from Connections via photo.do is not possible for guests because the photos require authentication so using the Connections business card for STProxy and Meetings is a show stopper.

Luckily in the Connections TDISOL there is an AL we can use called dump_photos_to_files. I won’t go into too much details about this but you can copy and paste the AL and then alter it. I altered it to return all user’s email addresses as well as UID and then dump the photos in the format of emailaddress.jpg which is the format needed by the Meeting server.

You may find the email addresses are capitalised. If so you will need to add some JavaScript to the lookup_user process to get it all in lower case

ret.value=conn.getstring(“email”).toLowerCase();

Once you have the photos in the correct format you need to get them from the server running TDI to a web server.

Web server

The logical way to serve the photos is using IHS in front of Connections. To get the files there I needed to scp them from the TDI server to IHS. I had to create ssh-keygens detailed in http://www.linuxproblem.org/art_9.html so I could scp the files wrapped in a shell script. Incidentally , the shell script called the AL and then scp’d the photos to the IHS server. Then add the shell script to cron so it is called on a schedule.

I wanted to lock down access to the photos so that people couldn’t browse to them. This is a little difficult to do but you can use IP ranges for all your internal offices and/or VPNs so that they are allowed to access the photos. The problem is guests who are truly external.

I created a new virtual host in httpd.conf with the following details.

# Sametime photos
<VirtualHost *:80>
ServerName icphotos.acme.com:80
DocumentRoot “/opt/IBM/HTTPServer/photos”
RewriteEngine On
RewriteCond %{HTTP_COOKIE} !LtpaToken2=.*$ [NC]
RewriteCond %{HTTP_COOKIE} !LtpaToken=.*$ [NC]
RewriteCond %{HTTP_COOKIE} !STPluginActivePage=stMeetingroom [NC]
# Old subnets and staff VPN
RewriteCond %{REMOTE_ADDR} !^xxx\.xx\.(x[x-x]|x[x-x])\.([x-x]|[x-x][x-x]|x([x-x][x-x])|x([x-x][x-x]|x[x-x]))$
# UK
RewriteCond %{REMOTE_ADDR} !^xxx\.xx\.(x[x-x]|x[x-x])\.([x-x]|[x-x][x-x]|x([x-x][x-x])|x([x-x][x-x]|x[x-x]))$
# India
RewriteCond %{REMOTE_ADDR} !^xxx\.xx\.(x[x-x]|x[x-x])\.([x-x]|[x-x][x-x]|x([x-x][x-x])|x([x-x][x-x]|x[x-x]))$
# Sametime Proxy
RewriteCond %{REMOTE_ADDR} !^xxx\.xx\.xx\.xxx$ [NC]
RewriteRule ^(.*)$ http://www.acme.com [R,L]
</VirtualHost>

In a nutshell this allows all clients on certain IP range s to access photos. It also allows any web browser whether it is internal or on the internet to access photos IF it has either one of three cookies, LtpaToken/LtpaToken2 which is provided to the browser when someone authenticates or the cookie STPluginActivePage which the browser stores when you enter a meeting room. STPluginActivePage is in the browser whether you are a guest or an authenticated user, you just need to enter a meeting room.

I included both LtpaToken and LtpaToken2. I found the Sametime client was sending only LtpaToken with the HTTP GET for the photos. This may be due to the fact that I allow both LtpaToken and LtpaToken2 in the Domino web SSO configuration document. If you only allow LtpaToken2 then you may find that the client sends LtpaToken2 with the GET.

If you are a web browser outside of the IP ranges and you do not have any of the three cookies then you will be redirected to http://www.acme.com. You could change this to a static html page of your choice.

I’m no whiz when it comes to Apache but I have tested this quite a bit and it seems pretty secure and should cover most bases. Of course it doesn’t stop a meeting guest from guessing email addresses and browsing other people’s photos but since you have invited them to a meeting, provided them with the meeting room password there is an element of familiarity that should stop them from being malicious in this way. If you back this up with changing the meeting room passwords often you should be in a strong position to keep these photos relatively secure.

If anyone has any thoughts on the httpd.conf I am all ears as I would like to tie it down further if it needs it.

UPDATE

I found that my original RewriteCond  for the IP addresses were not working. I was originally using the following method because it seemed nice and easy to just enter the CIDR but reading further the following approach only works with Apache 2.4 and IHS is using 2.2.8. You can find out by running apachectl -V.

RewriteCond expr “-R ‘xxx.xx.xx.0/xx'”

So regex was the only way to go and trying to work it out was going to be a headache. To my rescue came http://jodies.de/ipcalc? to convert the CIDR to all the IP addresses (well the first and last) and then I put these values into http://www.analyticsmarket.com/freetools/ipregex to give me the regex.

Advertisements