lekkimworld.comwas

File not found when using IBM Connections Media Gallery

Tue, 21 Feb 2012 18:58:08 GMT

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

Fri, 10 Feb 2012 13:52:50 GMT

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

Wed, 07 Dec 2011 20:54:40 GMT

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:\ibm\websphere\appserver\bin\manageprofiles.bat -create -templatePath ..\profileTemplates\management -profileName dmgr -profilePath d:\wasprofiles\dmgr -cellName LCCell01 -nodeName dmgrNode -serverType DEPLOYMENT_MANAGER

Application server:
c:\ibm\websphere\appserver\bin\manageprofiles.bat -create -templatePath ..\profileTemplates\default -profileName AppSrv01 -profilePath d:\wasprofiles\appsrv01 -nodeName appNode01

IBM Connections wsadmin cheat sheet

Wed, 05 Oct 2011 19:45:02 GMT

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

Wed, 21 Sep 2011 19:03:13 GMT

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

Mon, 19 Sep 2011 05:07:29 GMT

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

Fri, 10 Jun 2011 12:06:58 GMT

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:

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

}

Developing TAI's for Websphere Application Server

Wed, 08 Jun 2011 11:22:25 GMT

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>\runtimes\com.ibm.ws.webservices.thinclient_6.1.0.jar
<WASHOME>\lib\bootstrap.jar
<WASHOME>\lib\com.ibm.ws.runtime.jar
<WASHOME>\lib\j2ee.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