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.

Solved my custom TAI issue with WAS 7

I’ve previously blogged about the goodness of Trust Association Interceptors in Websphere Application Server (WAS) and how I’ve used it to turn the login procedure for IBM Connections on its head. We recently started upgrading the customer I originally developed this for to IBM Connections 3.0.1 hence they needed an upgrade to WAS 7. After upgrading the WAS servers the custom TAI didn’t work anymore. The TAI loaded just fine but it didn’t generate the needed LtpaToken2 for the visiting user. I cried out for help in the Connections forum. I got a few pointers but none of them helped me.

Fortunately I figured it out tonight.

The issue was that my custom TAI created subjects (a subject is the entity that holds the identity of the authenticated user in WAS) in a custom realm that wasn’t trusted by WAS. The only trusted realm was the one that WAS created for me when I configured Federated Repositories. The solution was to add the custom realm as trusted under Federated Repositories, configure <my realm> and then go to “Trusted authentication realms – inbound”. The entry is at the bottom under “Related Items”. Here I simply added my realm as Trusted, restarted WAS and I was golden!! Again this wasn’t necessary in WAS 6 and actually the option isn’t there at all in ISC.

Now I’m back to thinking that WAS and TAI’s are the best thing since sliced bread! 🙂

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);