Puakma: Under the hood

I confess. We don't have a copy of Websphere (or Websfear as it is sometimes known). Dilemma: Customers are testing the Web Booster Single Sign-On (SSO) module with Domino and Websphere - and find it doesn't work.

Aaaaaaarrrrrgh!

It took a deal of patience and time to decipher the Domino Ltpa token and foolishly we assumed that IBM would have a standard format. Bzzzzzt. Wrong. The Domino token is 100% different to a Websphere token (why??? these departments should talk - really!).

To date we are able to pull a Websphere token apart and see what's inside it. Next step (with the help of a few customers) is to work out how each part of the token is generated and be able to verify a token, then create one from scratch. I really enjoy these sorts of puzzles - the challenge is up ;-)

Now it occurs to me some of you out there may not know exactly why decoding these tokens is so important to us. We have some web server acceleration software Puakma Web Booster that has an additional plugin module that allows users to seamlessly access a Domino server without actually entering a username and password. We achieve this by challenging the browser (NTLM authentication in the background) for the workstations Windows NT credentials and using those to find the user in the Domino LDAP directory. Once we have located the user, we make a Ltpa token and tell the browser to use it with every transaction with the Domino server. The Ltpa token contains the canonical username, creation/expiry date of the token and a signed area which confirms the token has not been tampered with. The token is passed as a cookie from the browser to the server. By using Booster for SSO another of those annoying username/password prompts are avoided, which as you know equals happy users. Happy users = happy tech staff.