This spring has been full of little Seamless Single Signon configurations for me. It's about letting the users access Domino or WebSphere Portal content without making them type a username and password.
Internet Explorer <-> Puakma ESSO <-> Lotus Domino
Internet Explorer <-> Puakma ESSO <-> WebSphere Portal
Internet Explorer <-> Puakma ESSO <-> WebSphere Portal <-> Lotus Domino
Puakma ESSO is an HTTP proxy server that you put between the end user and the Domino (or WebSphere Portal) server.
So, you might have a Domino server that holds your intranet that is made to render in HTML. Lets say Domino's hostname is intranet.company.com. The intranet requires the user to be identified: Anonymous = No Access.
Then we let Puakma have the hostname intra.company.com.
We then ask browser users to go to http:/intra.company.com to see the intranet.
The effect is that the browser now reads the intranet without having to ask the user for password and username. But to Domino the user is identified.
How is this done?
All http requests for the intranet content now go through intra.company.com. So, all requests are done to Puakma ESSO, and Puakma ESSO repeats those requests, asking Domino for the same content.
But - the user needs to be identified. We need the HTTP requests to contain an LTPAtoken in the HTTP header.
The first time the browser requests a resource from Puakma ESSO, Puakma will check if there is a valid LTPAtoken in the header. If there is not, it will issue one and ask the browser to repeat the request. All done in the background - the end user sees nothing.
How does the Puakma ESSO server issue a proper LTPAtoken?
Using NTLM, the Puakma Server and the browser do a handshake - invisible to the end user. The handshake consists in a series of HTTP GETs from the browser and HTTP responses from Puakma server that ends up in the Puakma server having access to the end user's Windows name. Something like DOMAIN\INITIALS.
Puakma ESSO then does a LDAP lookup (usually to LDAP on Domino) using the windows-name as the key. It gets a NotesName back from LDAP. The NotesName is then encrypted by Puakma ESSO using a key that it has been configured to use.
Puakma ESSO now tells the browser to SET the LTPAtoken and re-request the resource.
The browser requests the resource, and now it has a valid LTPAtoken and Puakma will do the request for the user and forward the response to the end user.
I have been configuring maybe about fifteen of these Paukma ESSO servers in the last three years. And it works. And I am pretty sure that it is a lot cheaper than some of the alternatives too.
I can recommend this for Seamless Single Signon.
You can find some information about Puakma ESSO at puakma.net. There is a demo download available here.
If you're in the Nordic region, you can have a look at some information on tech.convergens.dk. In Danish.