Some Java, JEE and WebSphere stuffs | Something about JEE and WebSphere. Java, JEE and WebSphere tips and tutorials

Configuring TAI in WebSphere Application Server.

Yesterday I posted about how to create a custom Trust Association Interceptor for WAS. Today I will be explaining how to configure the TAI in WAS. In order to configure the TAI in WebSphere Application Server, export the TAI project as a jar file. (Creating and exporting a jar is very easy in RAD. Right click on the project and select Export. From the export wizard window select ‘JAR file’. It will show all the projects available with the one we right clicked as selected. Enter the destination where we want to save our generated jar file and enter a name for the jar file say tai.jar and click on Finish. Our jar file is ready).

Once we completed generation of jar file for TAI, we need to copy the same jar file to WAS_INSTALL_DIR\lib\ext folder. Now we need to make an entry for our TAI inside the admin console. The steps for configuring a TAI in WebSphere are given below.

1. Login to WebSphere admin console.
2. Click on Global Security under Security menu.
3. From the page opened up expand Authentication Mechanisms and click on LTPA
4. The LTPA configuration page opens up. Click on Trust Association links.
5. Select the “Enable trust association” check box. And save the changes.
6. Come back to the same page if you are not there already.
7. Click on Interceptors
8. Click on New
9. Enter the fully qualified name of your TAI inside “Interceptor class name” text box.
10. Save the changes

We are done. Restart the server and our new custom TAI will be ready for use.

If we are implementing an SSO solution using an external authentication provider, we need a Trust Association Interceptor (TAI) to assert the identity to WebSphere Application Server. If our authentication provider is an external tool like WebSEAL or Tivoli Accesses Manager, we need some mechanism to tell WAS that the user is authenticated. So the actual authentication happens in some external tools and by using TAI we would inform WebSphere about the user’s identity.

Today I will explain how to write a custom Trust Association Interceptor (TAI) for WebSphere. Since TAI is used for informing WebSphere Application Server about a user’s identity, first TAI needs to know which user is authenticated. Typically this is done by passing some parameter (like username) to WebSphere Application Server from authentication provider. The TAI which is present in the Application Server reads the parameters from request and returns the username to WAS. WAS then queries the user registry for the existence of the user. However WAS will not validate the password while it queries the user registry.

The first step in developing a custom TAI is to write a class that implements the TrustAssociationInterceptor interface. The TrustAssociationInterceptor interface contains a couple of methods that we need to implement.

The first method that will be executed when calling the TAI is initialize. Any initialization operations can be performed in this method if required. Then TAI would call the isTargetInterceptor method which evaluates the request and returns true if the request is the one that TAI needs to work with.

If the current request is for target interceptor, TAI would call negotiateValidateandEstablishTrust method which actually returns a TAIResult to the WebSphere Application Server. Finally the cleanUp method will be called. The complete code listing for a simple custom Trust Association Interceptor is given below.

The below code which is residing in the WAS expects a parameter named username from authentication provider. If the request contains the username it returns true and creates a trust with WAS.

import java.util.Properties;
 
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;
 
/**
 * A simple custom Trust Association Interceptor.
 */
public class TestInterceptor implements TrustAssociationInterceptor  {
 
    /* Validates the incoming request.
     *
     * (non-Javadoc)
     * @see com.ibm.wsspi.security.tai.TrustAssociationInterceptor#isTargetInterceptor(javax.servlet.http.HttpServletRequest)
     */
    public boolean isTargetInterceptor(HttpServletRequest req) throws WebTrustAssociationException {
        // Lets do some validation on the incoming request
        String username = req.getParameter("username");
 
        // If we got a username the request for TAI only.
        if (username != null)
            return true;
 
        return false;
    }
 
    /* (non-Javadoc)
     * @see com.ibm.wsspi.security.tai.TrustAssociationInterceptor#negotiateValidateandEstablishTrust(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
     */
    public TAIResult negotiateValidateandEstablishTrust(HttpServletRequest req, HttpServletResponse resp) throws WebTrustAssociationFailedException {
       // Validate and establish trust with WebSphere Application Server.
       TAIResult result = null;
 
       String username = req.getParameter("username");
 
       // Create the TAIResult with username we got.
       result = TAIResult.create(HttpServletResponse.SC_OK, username);
 
       // return the TAIResult.
       return result;
 
    }
 
    /* (non-Javadoc)
     * @see com.ibm.wsspi.security.tai.TrustAssociationInterceptor#initialize(java.util.Properties)
     */
    public int initialize(Properties arg0) throws WebTrustAssociationFailedException {
        // The TAI initialization code goes here.
        return 0;
    }
 
    /* (non-Javadoc)
     * @see com.ibm.wsspi.security.tai.TrustAssociationInterceptor#getVersion()
     */
    public String getVersion() {
        // The version of TAI we are using.
        return "1.0";
    }
 
    /* (non-Javadoc)
     * @see com.ibm.wsspi.security.tai.TrustAssociationInterceptor#getType()
     */
    public String getType() {
        // The type of TAI.
        return "Custom TAI 1.0";
    }
 
    /* (non-Javadoc)
     * @see com.ibm.wsspi.security.tai.TrustAssociationInterceptor#cleanup()
     */
    public void cleanup() {
        // The TAI clean up code goes here.
    }
}

Configuring a TAI in WAS will be covered in the next post.

Accessing an HTTPS web service from WAS web client

Calling an HTTPS web service is a hell, if all our configurations are not correct. Accessing or calling a secured or HTTPS web service from a WAS web client, involves some configuration at the WAS side. If we miss these configurations we will get some nice SSL exceptions.

In order to get rid of all these SSL exceptions we need to import the server certificate to WAS trust store. So first extract the server certificate. To extract the server security certificate enter the URL in the browser (I was using IE). The browser will show the security alert pop up. Click on View Certificate

Now click on the Details tab and click on ‘Copy to File’ button

The certificate export wizard will be open. Click on Next button. From the export file format page accept the default values (DER encoded binary X.509 (.CER) will be selected by default) and click on next.

In the next screen enter the location where we want to store our certificate. (I used d:\wps.cer)

Click next and finish. We will be presented with a dialog box saying ‘The export was successful’. OK. We have done with our certificate export. The next step is to import the SSL certificate to server trust file.

For importing the SSL certificate to WebSphere Application Server’s trust store we need to know the location of the trust store file. To check the SSL setting, login to admin console. Click on SSL under security menu. From the SSL configuration repertoires page click on your SSL settings configuration link. Find out the trust file name and path under Trust file section.

If you are using the default settings the trust file name will be DummyServerTrustFile.jks. The default path will be WAS_INSTALL_DIR/profiles/ /etc/

Now go to WAS_INSTALL_DIR/bin directory and execute the iKeyMan.bat file. The IBM Key Management utility will be opened up. Click on ‘Key Database File’ and select open. From the dialog box opened select Key database type as JKS and enter the Server trust file name and path (DummyServerTrustFile.jks in my case).

Click on OK button. You will be prompted to enter the password. If you are using the default server trust file the default password for DummyServerTrustFile.jks is WebAS. Enter the password and click on OK.

Click on Add and select the server SSL certificate file which we extracted using Internet Explorer. (If you are not able to find the add button, select the Signer certificates under Key database content drop down) Click on OK button. You will be prompted to enter a label for the certificate. Enter the label you want for the certificate and click on OK. The server SSL certificate will be added to the WebSphere Application Server trust store. You are done. Close IBM Key Management tool and restart the application server. Now you will be able to access HTTPS web service from within your WebSphere Application Server without any problems.

Application already exists in the configuration repository error when installing new EAR in WAS admin console.

If we can screw up our enterprise application installation properly, we would reach to a state where we cannot go forward and backward. It is a nice state in which if we try to uninstall the application we would get an error message from WebSphere. Whatever may be the reason we will not be able to uninstall the enterprise project using WAS admin console. Then we will try our luck by installing new enterprise application unluckily WAS wouldn’t allow us to do that also. This time WebSphere Application Server would give a nice error message. “Application already exists in the configuration repository”.

The solution to this issue is to manually delete/uninstall the application by editing the configuration file. Do a search for your ear file in the file system and delete all the occurrences of the XXX.ear folder (You can see one .ear directory in your WAS_INSTALL_DIR/profiles//installedApps directory and one in WAS_INSTALL_DIR/profiles//config/cells//applications folder). Once we deleted these entire XXX.ear folders, delete all the contents of temp and wstemp folder. Now go to

WAS_INSTALL_DIR\profiles\<profileName>\config\cells\<cellName>\nodes\<nodeName>\

And edit the file serverindex.xml.

In this file we can see an entry for our application within the tag

 
<deployedApplications>xxx.ear</deployedApplications>

Delete this entry. We are done. Now we can install our application using WebSphere admin console without any issues.

Some times there might be cases like forgetting WebSphere admin console password where we need to disable WebSphere Application Server security by editing configuration files without logging into the WAS admin console. In order to does this go to

WAS_INSTALL_DIR/profiles/<profileName>/config/cells/<cellName>/

and open the file security.xml. Search for a tag name

<security:Security.

This would be the first tag in security.xml file. In this tag we can see an attribute called

enabled="true"

Just change the value to false. Save the file and restart the server. Security will be disabled on the server.