Recently, I was asked to assist with an integration of an existing suite of JEE web applications with an Oracle single sign-on solution being rolled out across a large organisation.
The IBM WebSphere platform that was used for running existing web applications was somewhat outdated (WAS v6.1) and there was no possibility of an upgrade. To make things even more difficult, the applications in question used a home grown single sign-on solution with little documentation.
The project brief was simple. Develop a proof of concept solution to demonstrate to management that their current assets can be migrated to the new single sign-on platform without major (or preferably any) changes to the above mentioned applications.
Oracle’s OAM is a sophisticated, modern and complex offering. Among many things it supports and uses SAML to pass user identity and authorisation assertions to endpoint applications. WebSphere also supports SAML but only from version 7 and I was working with version 6, which of course doesn’t.
IBM also has its own single sign-on solution that integrates well with WebSphere (naturally) - WebSEAL. WebSEAL is a reverse proxy which proxies all requests and responses to an application, which is not accessible any other way. User authentication and corse-grained access control is thus centralised at this point.
When the HTTP request eventually gets to the WebSphere application server running the endpoint application, that request carries an encrypted lightweight third party authentication (LTPA) token which identifies the authenticated user. Since the token is encrypted, the WebSphere application server and WebSEAL must establish trust before hand so that WebSphere can decrypt contents of the LTPA token. This of course all happens in the background with the applications getting user identity and roles via the standard JEE mechanism (i.e. via HttpServletRequest interface).
So, given this environment our challenge was to integrate the incoming authentication/authorisation SAML token with WebSphere’s LTPA mechanism. Since the authentication of the user was happening externally to the WebSphere eco-system, the usual JAAS approach was inappropriate as it did not offer the single sign-on solution that was required. That is, we could not use the incoming SAML token in any way.
After a brief search on the Internet and having considered all our options we have settled on WebSphere’s Trust Association Interface (TAI) solution. TAI is not a well-known approach but in this case it was a perfect match for our requirements. Instead of re-authenticating the user (which is what JAAS could offer), TAI allows WebSphere to use existing user identity information obtained externally (in this case the SAML token obtained via OAM) to establish an authenticated session. Once the session is established, WebSphere can then track it via its standard LTPA mechanism.
I won’t dwell too much on the nitty-gritty details of how to implement and configure the TAI interceptor, as there is an excellent resource from IBM that deals with just that, see http://www.ibm.com/developerworks/websphere/techjournal/0508_benantar/05… . Instead, the purpose of this blog is simply to document this approach as it applied to my specific situation, i.e. asserting user identity authenticated by Oracle’s OAM.
So, here is the use case I was working with. Before a user can access the WebSphere hosted application she is redirected to the Oracle’s single sign-on form (for now lets ignore how this redirect actually happens, we will deal with that later). The critical piece of information that is provided to the OAM with this redirect is the return URL back to the application (this is passed in via a request parameter).
The user authenticates herself via the OAM form and is then redirected back to the WebSphere application. This redirect request contains a HTTP attribute that contains an encrypted SAML token produced by OAM and which verifies the user’s identity and her privileges.
Before the redirected request reaches the application, the WebSphere server will intercept it and pass it to its authorisation mechanism, which we will extend using a custom TAI module. The negotiateValidateandEstablishTrust method does the magic of retrieving the SAML token, extracting user information and setting-up the WebSphere’s authenticated session using its TAIResult API.
e.g.
One neat trick we ended up using in cases when the incoming request did not have a SAML token or it was invalid, was to reply with a browser redirect response (i.e. 303) to the OAM gateway.
e.g.
Obviously, there is lot more that could be said on the subject but hopefully this blog together with the IBM link provided can help you with integrating TAI-based single sign-on solutions into your legacy WebSphere applications (if not, drop us an email or comment below).