Last week, I spent a day at a customer up in New Jersey. They are currently deploying a pilot of Lotus Connections 2.5. One of the most important things for them is to be able to mash up Lotus Connections with their existing intranet applications via their portal (powered by WebSphere Portal, of course).
To simplify sign on for all their employees, they use WebSEAL and SPNEGO to provide single sign on for all web applications. This way, an employee logs on to their workstation in the morning, and they are never prompted to log on again to other web applications.
As we deployed the Lotus Connections 2.5 Portlet, we ran into an issue. The portlet wasn't built to support an SSO solution in the middle (it mostly depends on WebSphere SSO which is based on something called LTPA token). At this point, I had to figure out how to change the portlet to support WebSEAL, so I went on and downloaded the source code for the portlet (isn't it nice when they make the source code available?)
It turns out, that it wasn't that hard; I was able to do it in less than 30 minutes. Here's what I did:
- Import the code into WebSphere Portlet Factory
- Edit WEB-INF/models/lcaccelerator/services/BlogProvider
- Look for getAllBlogsRest
- Expand Advanced options
- Notice how there's HTTP Cookies and Forward HTTP Cookies. Given the developers are using HTTP Cookies to forward the LTPA cookie, let's go with that. As seen here:
- Now, let's create the actual method. What I did was copy/pasted the src/com/ibm/lconn/lcaccelerator/utils/LTPAUtil class and renamed it to WebSealUtil class.
- At the same time, I renamed getLtpaCookie to getWebSealCookie and I changed the implementation to:
- Note that I'm getting a cookie called PD-CC. Not sure if that's what it's always called in WebSEAL, but that was the name in this case.
- Re-packaging and sending to the portal server fixed the Blogs portlet. Then repeat the above steps for the Dogear and Activities provider
Enjoy!