WebSphere custom TAI – Doing SSO the right way

WebSphere TAI – Doing SSO the right way

Hi all,

one thing on my “to do blog posts” list is to write something about WebSphere TAI. A great way to introduce Single-Sign On between different systems.

What is TAI?

WebSphere TAI means “Trust Association Interceptor”

WebSphere TAI is a well-known and proven security concept in WebSphere stable for a long time. It allows to set up custom advanced (pseudo) SSO scenarios. And the clue is it is extremely easy to code and use.

The base idea is that the TAI code is called whenever a web user is challenged to login.

In many cases not only one TAI is configured. In this case it is up to the TAI developer to make sure that only one of them handles the request. If no TAI handles the request the default login page raises.

Where is a TAI used?

You might have already realized that also standard installations of IBM Connections or WebSphere Portal use Trust Association Interceptors to allow Single-Sign-On using various methods such as:

  • SPNEGO (deprecated)
  • SAML
  • custom …

Example SAML TAI configuration:


How does it work?

Sample flow how a TAI authentication may be implemented (there are also other possibilities and ways)

Bildschirmfoto 2016-09-05 um 19.48.15

1.The user calls a website and authenticates on the given login-form

2.The authentication service checks the LDAP if the given credentials are valid

3.A Cookie (authentication Token) is generated that may contain:

  1. username
  2. timestamp of request
  3. a shared secret

and other security relevant information. The content of this cookie is encoded. The cookie is sent to the configured WebSphere Application Server with the activated TAI

4. The deployed TAI received this token and evaluated if the request is trustable:

  1. Where does the request come from (X-Forwarded-For information in request) – does the request come from the authentication proxy? If not the request is not valid!
  2. Does the timestamp match?
  3. Does the shared secret match?

If all of the above conditions match, the TAI trusts and logs in the user.

There are many other possibilities how to implement a TAI!!! Note that the Cookie that contains sensitive information will never leave the “company network”. The cookie is not sent to the client. It is only visible between authentication proxy and WebSphere Application Server (this may not work with every authentication service…)

How to install and activate?

The installation and activation is quite simple. In our example the TAI only consists of a jar file that needs to be placed in the “…/WebSphere/AppServer/lib/ext” folder of the WebSphere nodes. After a restart of the server, the jar file is loaded.

Now you need to activate the TAI or let`s say tell WebSphere Application Server to use the TAI.

“Global Security” – “Web and SIP Security” – “Trust Association”


Make sure “Enable trust association” is checked. Then click on Interceptors


Click on “New…”


And enter the mandatory custom properties (this heavily depends on how you code your TAI and what additional functions you use there):


Those values need to match the values, ips … you specified on you logon device!

Restart the server and check if it works

Some code samples

From a developer perspective a TAI implments an interface with two methods.

public boolean isTargetInterceptor(HttpServletRequest request) {
boolean doHandleRequest = checkToken(request);
return doHandleRequest;

This method is called before a user is challenged to login. Typically this method is implemented in the way that a token a Cookie a request parameter or something else is in the request from which the user can be identified.
It returns true if the parameter is in the request otherwise returns false.

If this method returned true, a second method is called later in the login process.

public TAIResult negotiateValidateandEstablishTrust(HttpServletRequest request, HttpServletResponse response)
throws WebTrustAssociationFailedException {

String userId = myTokenHandler.getUserId(request);
if (userId == null) {
return redirectToLoginPage(request, response);
else {
Subject subject = createSubjectForUserId(userId);

This method then identifies the user using the given request data for example against a remote repository. After this a user subject is created and the request is forwarded to the original target URL. And voila the user is authenticated.
There are several options to achieve this for example read the subject from the underlying user repository modify additional user attributes add the user to an additional group. In this simple example we created the user subject for our own:

private Subject createSubjectForUserId(String userId) throws Exception {

Subject subject = new Subject();
Principal principal = new UsernamePrincipal(userid);
return subject;

Note that implementing a custom TAI is a powerful thing you have to be careful not to break the security of an environment.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.