Tag: tai

To complete my series posts on writing Trust Association Interceptors (TAI’s) for Websphere Application Server I wanted to show a real-life example. Not a good example necessarily but an example never the less… 🙂

The below example is a very simple TAI that simply does the following:

1. The initialize() method reads a cookie name from the configuration done in the Websphere Application Server ISC. It illustrates how you can configure a TAI externally without having to hard code it.
2. The isTargetInterceptor() method looks at the request and sees if a cookie with the configured name is available. If yes it continues to process the request and if not it aborts processing (from the TAI point of view).
3. The negotiateValidateandEstablishTrust() method does the actual work by simply telling WAS that the username of user is the value from the cookie.

As you see writing a TAI is very simple but extremely powerful. Imagine what could be done if you did SSO between Websphere Application Server and Lotus Domino.

import java.util.Properties;

import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import com.ibm.websphere.security.WebTrustAssociationException;
import com.ibm.websphere.security.WebTrustAssociationFailedException;
import com.ibm.wsspi.security.tai.TAIResult;
import com.ibm.wsspi.security.tai.TrustAssociationInterceptor;

public class ExampleTAI implements TrustAssociationInterceptor {
   // declarations
   private String cookie = null;

   @Override
   public void cleanup() {
   }

   @Override
   public String getType() {
      return String.format("Example TAI %s", this.getVersion());
   }

   @Override
   public String getVersion() {
      return "1.0";
   }

   @Override
   public int initialize(Properties props)
      throws WebTrustAssociationFailedException {
      System.out.println("ExampleTAI.initialize()");

      // read properties from configuration in WAS
      this.cookie = props.getProperty("cookieName");

      // return 0 to indicate success
      return 0;
   }

   @Override
   public boolean isTargetInterceptor(
      HttpServletRequest req)
      throws WebTrustAssociationException {
      System.out.println("ExampleTAI.isTargetInterceptor()");
      for (Cookie c : req.getCookies()) {
         if (c.getName().equals(this.cookie)) return true;
      }
      return false;
   }

   @Override
   public TAIResult negotiateValidateandEstablishTrust(
      HttpServletRequest req,
      HttpServletResponse res)
      throws WebTrustAssociationFailedException {
      System.out.println("ExampleTAI.negotiate...()");
      for (Cookie c : req.getCookies()) {
         if (c.getName().equals(this.cookie)) {
            // send 200 to signal we're okay
            return TAIResult.create(HttpServletResponse.SC_OK,
                c.getValue());
         }
      }

      // not authenticated
      return TAIResult.create(HttpServletResponse.SC_UNAUTHORIZED);
   }

}

Trust Association Interceptors (or TAI’s) for Websphere Application Server is quickly becoming my new favorite technology. They just might be best thing since sliced bread and the reason why why you want to embrace Websphere Application Server. And so quickly.

I have discussed TAI’s and why they’re important in an earlier blog post.

One thing to know however is when developing them you need to have the necessary stuff in place. For TAI’s these are the JAR required on the class path and they are:

• <WASHOME>runtimescom.ibm.ws.webservices.thinclient_6.1.0.jar
• <WASHOME>libbootstrap.jar
• <WASHOME>libcom.ibm.ws.runtime.jar
• <WASHOME>libj2ee.jar

After that it’s a matter of creating a new class and implementing the com.ibm.wsspi.security.tai.TrustAssociationInterceptor interface which only contains two methods:

• public boolean isTargetInterceptor (HttpServletRequest req)
  “The isTargetInterceptor method determines whether the request originated with the proxy server that is associated with the interceptor. The implementation code must examine the incoming request object and determine if the proxy server that forwards the request is a valid proxy server for this interceptor. The result of this method determines whether the interceptor processes the request.”
• public TAIResult negotiateValidateandEstablishTrust (HttpServletRequest req, HttpServletResponse res)
  “The negotiateValidateandEstablishTrust method determines whether to trust the proxy server from which the request originated. The implementation code must authenticate the proxy server. The authentication mechanism is proxy-server specific. For example, in the product implementation for the WebSEAL server, this method retrieves the basic authentication information from the HTTP header and validates the information against the user registry that WebSphere Application Serve uses. If the credentials are not valid, the code creates the WebTrustAssociationException exception, which indicates that the proxy server is not trusted and the request is denied. If the credentials are valid, the code returns a TAIResult result, which indicates the status of the request processing with the client identity (Subject and principal name) to use for authorizing the Web resource.”

In short isTargetInterceptor is called to determine if a given request matches a given TAI and if it returns true negotiateValidateandEstablishTrust is called to determine if this TAI could authenticate the user and that the username (“Subject”) is. Very easy.

It’s important to note that “authenticate” could mean whatever you decide it means. That is you could actually do some work to authenticate the request but you could just as well simply decide that the user is authenticated and that the username is “John Doe123”. Whether the authentication is done based on “real authentication”, based on a cookie being set or something else is entirely up to you. That’s why it’s so powerful.

Once deemed authenticated by negotiateValidateandEstablishTrust a valid LtpaToken/LtpaToken2 is generated and the user is granted access into the Kingdom.

Infocenter:
Trust association interceptor support for Subject creation

Websphere Application Server is a beast. A big beast. But it’s a beast that good (even great?!) on a lot of levels and it’s definitely not as bad as you might think and it comes with a lot of goodness and loads of functionality. One of the real cool things about Websphere Application Server is the ability you have to extend the core application server (which is something that is hard – becoming easier but still hard – with Lotus Domino). The extendibility I want to mention today is Trust Association Interceptors – or TAI for short.

A Trust Association Interceptor is an exciting piece of technology that has been part of Websphere Application Server for quite a while and a technology that is becoming my new best friend. It’s objective is to sit between an incoming request and the application server runtime and let you manage the authentication state of incoming requests. Think DSAPI filters to manage authentication if you will except that TAI’s are written in Java and much easier to write, test, debug and deploy.

If you have a reverse proxy such as WebSEAL the way you make it work with Websphere Application server today is by installing a TAI into the application server. It’s also the way that SPNEGO support is added. As with many Java technologies you could just as well write your own – and it’s dead easy. It’s even well documented in the IBM Infocenter. So why would you want to do so? Well imagine if you’re installing IBM Connections and have an existing SSO solution you want to reuse to authentication. Writing a TAI lets you do that with a minimal hazzle.

I’ll post about how you actually go ahead and write a Trust Association Interceptor later.