02.09.06
Credential Overload or My Life with Single Signon.
A plaque has struck the modern man: were the world, but a peaceful and secure place, theft and fraud mere words, alas! Born from distrust and dishonesty this ailment spreads at a pace unheard of, causing grief and anger no longer just to amnesiacs. From credit cards to badges, intranets to web banks, whenever a new door is opened, venues pursued that beast of safety rears its grimy head: another combination code to remember, yet another arbitrary string of letters and digits. Better not write it down lest it be stolen! Better change it from time to time lest it be broken! What chance I ask stand the modern man of remembering them all?
The cure for the condition is single signon (SSO), a magic mechanism that grants access to all your trusted assets. A universal “Open Sesame”!
Recently SSO has become an integral part of my life or at least designing SSO solutions has. First I have had the good fortune to assist in the design of a federated identity management solution, which can be used within the Danish Health Care domain. Based on the Security Assertion Markup Language version 2.0 (SAML), the solution defines a new profile for use with SOAP over HTTP within this particular domain of use. The design was carried out through an online TWiki installation allowing us an easy way to add and revision content. If you read Danish go and check out the SOSI website and the technical design there.
On another note I have been investigating various solutions to providing seamless access between web applications running in Pocket Internet Explorer on PDAs, SSO again. It turns out that there are quite a few possibilities here ranging from screen scraping clients that punch credentials into arbitrary user interfaces on the client to web centric shared cookie solutions, 3rd party or custom built. Of particular interest to the J2EE community are solutions that extend application server authentication logic with support for SSO.
In my particular setup the server is a WebSphere 6.0, which sports an extension known as Trust Association Interceptor or TAI for short. This extension can be leveraged to intercept all requests for protected web resources and authenticate the user via a custom scheme. This scheme could utilize an SSO session cookie provided as part of the request, allowing the TAI to support single signon with other applications in the same domain.
Another nifty SSO implementation bases its authentication mechanism on the Filter concept from the Servlet Specification. A dedicated Filter intercepts all requests to a set of URL patterns as configured in web.xml and authenticates the user via an SSO token or redirects to a login page. The difference here is that the authentication mechanism doesn’t hook into the J2EE security. In other words: where the TAI will make the WebSphere server create a J2EE authenticated Principal, which will be used to authorize access to other resources e.g. EJBs, the Filter method will not. On the other hand, this solution is portable across application server platforms and not WebSphere specific.
Great! I have designed and outlined single signon on PDAs and across federations of web service providers … I still have to remember at least 3 different credit card codes, 2 badge combinations, numerous passwords, my social security number, and a plethora of other credentials which I seem to have forgotten at the moment.
I need some single signon in my life!
View Kåre Kjelstrøm's profile
