Websphere Application Server training curriculums FREE


I just found out via Twitter that loads of Websphere Application Training is available for free online on the IBM Education Assistant. At the page you’ll find stuff for both WAS 8 and 8.5 – nothing for 7.x though which is the version that most IBM Collaboration Solution software runs on though.

Watch the names when doing SSO between WAS and Domino

This morning I helped a customer because they couldn’t make the beta of the OnTime Group Calendar for IBM Connections work and it turned out to be a Single-Sign-On issue. For the OnTime widgets to work we require SSO between Websphere Application Server and Domino which is trivial to set up. Simply export the SSO keys from Websphere using the Integrated Solution Console (ISC) and import them into the SSO document in Domino Directory. In Websphere Application Server terms this is called cross-cell SSO and is very easy to set up.

After doing this SSO still didn’t work and right of the bat I suspected the good ol’ “multiple O= identifier” issue. The issue is when you incorrectly configure federated repositories and a username is reported by ISC with an extra organization identifier e.g. I would be “CN=Mikkel Flindt Heisterberg,o=IntraVision,o=IntraVision” and not simply “CN=Mikkel Flindt Heisterberg,o=IntraVision” the latter of course being correct. While WAS (and IBM Connections) will work just fine with that type of configuration is can cause SSO not to work correctly or only work when the user authenticates to Domino first the problem being that the DN that WAS sticks into the LtpaToken isn’t valid in Domino.

Verifying the names is easy using “Users and Group/Manage Users” in the left hand menu in ISC.

After reconfiguring federated repositories and restarting Websphere Application Server SSO functioned and the customer was back to using the OnTime Group Calendar widgets.

File not found when using IBM Connections Media Gallery

At a customer users were reporting that the media gallery in IBM Connections did not work. The error they were seeing was aneror message in the UI telling them that the file they just selected from their file system did not exist. Very strange. After diagnosing the issue it was caused by the media gallery not having been set up correctly as the default file types wasn’t imported into the configuration. Why these defaults are not set automatically is the topic for another day.

There are two templates which determine the file types you can upload
by default. You should also have these in your AppSrv01 profiles, or your
nodes, etc. The step is done by following the instructions in the info center.

Disabling HTTPS communication between IHS WAS Plugin and WAS servers

Many people believe that you have to have multiple servers to run IBM Connections – this simply isn’t true! There’s no reason why you cannot run everything of the same server which is what we do here at the office. When you do that, if all servers are inside the firewall – or if you simply doesn’t care about the security that it provides – you can disable the IHS WAS Plugin from communicating with the WAS server using SSL. A benefit from this is among other things that you do not have to care about certificates between the IHS WAS Plugin and the WAS server which simplifies installation and management.

Any way… For a while I’ve doing this configuration change manually directly in plugin-cfg.xml (by commenting the HTTPS transport out) until it bit us the other day. So I finally decided to find a proper, correct, solution. And of course there is a way to do this and it’s very well documented in IBM Technote 1452735. So if you want to make that change go ahead and do it – I did and it’s working flawlessly.

WAS profile creation on Windows Server 2008 64 bit

When installing Connections on Windows 2008 Server 64 bit the profile management tool doesn’t work so profile creation is done using manageprofiles.bat/sh. The syntax is hard to remember so here it is for future reference.

Deployment manager:
c:ibmwebsphereappserverbinmanageprofiles.bat -create -templatePath ..profileTemplatesmanagement -profileName dmgr -profilePath d:wasprofilesdmgr -cellName LCCell01 -nodeName dmgrNode -serverType DEPLOYMENT_MANAGER

Application server:
c:ibmwebsphereappserverbinmanageprofiles.bat -create -templatePath ..profileTemplatesdefault -profileName AppSrv01 -profilePath d:wasprofilesappsrv01 -nodeName appNode01

IBM Connections wsadmin cheat sheet

Starting with IBM Connections 3 the Websphere wsadmin command is even more important as the only way to deploy Connections is using Websphere Application Server Network Deployment or ND for short. The wsadmin command is used to check out the Connections configuration files and check them back in after modification. Because some commands require different configuration services to be loaded I have started compiling a cheat-sheet of some of the commands one use all the time. I have created a page for them. Expect the list to grow over time.

Of course the Info centers and wikis also list the commands.

Make the Integrated Solutions Console (ISC) accessible on standard ports

When you install Websphere Application Server (WAS) either standalone or as a network deployment (ND) you normally install the Integrated Solutions Console (ISC) as well to allow you to configure and manage the server. By default the ISC is available on ports 9060/9443 and it not normally mapped onto an IBM HTTP Server (IHS) for access on ports 80/443. This makes it a real hazzle to access it so I normally change WAS to make ISC available on ports 80/443 on servers where port 80/443 isn’t used. Doing so is really easy and only require a few changes. Below I have outlines the required changes.

In the left-hand menu go to “Environment / Virtual hosts” and select “admin_host” in the list. On the right select “Host Aliases”, click “New” and add an entry for port 80 and one for port 443.

Now in the left-hand menu go to “System Administration / Deployment manager” and select “Ports”. Now change the port for “WC_adminhost” from 9060 to 80 and “WC_adminhost_secure” from 9443 to 443.

Now save the configuration and restart the server or Deployment Manager running the ISC. When you access the ISC again it will be on http://hostname/ibm/console instead of http://hostname:9060/ibm/console.

And as Stephan always says – YMMV…

A TAI code example

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;

   public void cleanup() {

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

   public String getVersion() {
      return "1.0";

   public int initialize(Properties props)
      throws WebTrustAssociationFailedException {

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

      // return 0 to indicate success
      return 0;

   public boolean isTargetInterceptor(
      HttpServletRequest req)
      throws WebTrustAssociationException {
      for (Cookie c : req.getCookies()) {
         if (c.getName().equals(this.cookie)) return true;
      return false;

   public TAIResult negotiateValidateandEstablishTrust(
      HttpServletRequest req,
      HttpServletResponse res)
      throws WebTrustAssociationFailedException {
      for (Cookie c : req.getCookies()) {
         if (c.getName().equals(this.cookie)) {
            // send 200 to signal we're okay
            return TAIResult.create(HttpServletResponse.SC_OK,

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


Developing TAI’s for Websphere Application Server

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.

Trust association interceptor support for Subject creation