+

Search Tips   |   Advanced Search

Develop a custom interceptor for trust associations


We can define the interceptor class method that you want to use. WAS supports two trust association interceptor interfaces: com.ibm.wsspi.security.TrustAssociationInterceptor and com.ibm.wsspi.security.tai.TrustAssociationInterceptor.

For a third party reverse proxy server other than Tivoli WebSEAL, provide an implementation class for WAS interceptor interface for the proxy server. This article describes the com.ibm.wsspi.security.TrustAssociationInterceptor.java interface that implement.

The Trust Association Interceptor (TAI) interface (com.ibm.wsspi.security.tai.TrustAssociationInterceptor) supports several new features and is different from the existing com.ibm.wsspi.security.TrustAssociationInterceptor interface.

 

  1. Define the interceptor class method. WAS provides the interceptor Java interface, com.ibm.wsspi.security.TrustAssociationInterceptor, which defines the following methods:

    • public boolean isTargetInterceptor(HttpServletRequest req) creates WebTrustAssociationException;.

      The isTargetInterceptor method determines whether the request originated with the proxy server associated with the interceptor. The implementation code must examine the incoming request object and determine if the proxy server forwarding the request is a valid proxy server for this interceptor. The result of this method determines whether the interceptor processes the request or not.

    • public void validateEstablishedTrust (HttpServletRequest req) creates WebTrustAssociationException;.

      The validateEstablishedTrust method determines if the proxy server from which the request originated is trusted or not. This method is called after the isTargetInterceptor method. The implementation code must authenticate the proxy server. The authentication mechanism is proxy-server specific. For example, in WAS implementation for the WebSEAL server, this method retrieves the basic authentication information from the HTTP header and validates the information against the user registry used by WAS. If the credentials are invalid, the code creates the WebTrustAssociationException, indicating that the proxy server is not trusted and the request is to be denied.

    • public String getAuthenticatedUsername(HttpServletRequest req) creates WebTrustAssociationException;.

      The getAuthenticatedUsername method is called after trust is established between the proxy server and WAS. WAS ND v7.0 has accepted the proxy server authentication of the request and must now authorize the request. To authorize the request, the name of the original requestor must be subjected to an authorization policy to determine if the requestor has the necessary privilege. The implementation code for this method must extract the user name from the HTTP request header and determine if that user is entitled to the requested resource. For example, in WAS implementation for the WebSEAL server, the method looks for an iv-user attribute in the HTTP request header and extracts the user ID associated with it for authorization.

  2. Set the interceptor. To make an interceptor configurable, the interceptor must extend com.ibm.wsspi.security.WebSphereBaseTrustAssociationInterceptor. Implement the following methods:

    public int init (java.util.Properties props);

    The init(Properties) method accepts a java.util.Properties object, which contains the set of properties required to initialize the interceptor. All the properties set for an interceptor (by using the Custom Properties link for that interceptor or using scripting) is sent to this method. The interceptor then can use these properties to initialize itself. For example, in WAS implementation for the WebSEAL server, this method reads the hosts and ports so that a request coming in can be verified to originate from trusted hosts and ports. A return value of 0 implies that the interceptor initialization is successful. Any other value implies that the initialization is not successful and the interceptor is ignored.

    Applicability of the following list If a previous implementation of the trust association interceptor returns a different error status we can either change your implementation to match the expectations or make one of the following changes:

    • Add the com.ibm.wsspi.security.trustassociation.initStatus property in the trust association interceptor custom properties. Set the property to the value that indicates that the interceptor is successfully initialized. All of the other possible values imply failure. In case of failure, the corresponding trust association interceptor is not used.

    • Add the com.ibm.wsspi.security.trustassociation.ignoreInitStatus property in the trust association interceptor custom properties. Set the value of this property to true, which tells WAS to ignore the status of this method. If we add this property to the custom properties, WAS does not check the return status, which is similar to previous versions of WAS.

    public void cleanup ();

    This method is called when the appserver is stopped. It is used to prepare the interceptor for termination.

    public void setVersion (String s);

    This method is optional. The method is used to set the version and is for informational purpose only. The default value is Unspecified.
    You must configure the following methods implemented by the custom interceptor implementation. This listing only shows the methods and does not include any implementation. 

    ******************************************************************** 
import java.util.*;
 import javax.servlet.http.HttpServletRequest;
 import com.ibm.websphere.security.*;
 public class myTAIImpl extends WebSphereBaseTrustAssociationInterceptor
      implements TrustAssociationInterceptor
{

      public myTAIImpl ()
      {
      }


      public boolean isTargetInterceptor (HttpServletRequest req)
          throws WebTrustAssociationException
      {

           
//return true if this is the target interceptor, else return false.
      }


      public TAIResult negotiateValidateandEstablishTrust (HttpServletRequest req, HttpServletResponse res)
           throws WebTrustAssociationFailedException
      {
           
//validate the request and establish trust.
           
//create and return the TAIResult public int initialize (Properties props)
      {
           
//initialize the implementation. If successful return 0, else return 1.
      }

     public String getVersion()
     {
         
//Return version
     }  
  
    public String getType()
     {
         
//Return type
     }  

      public void cleanup ()
      {
           
//Cleanup code.

      }
        

}

    If the init(Properties) method is implemented as described previously in the custom interceptor, this note does not apply to the implementation, and we can move on to the next step. Previous versions of...

    com.ibm.wsspi.security.WebSphereBaseTrustAssociationInterceptor

    ...include the public int init (String propsfile) method. This method is no longer required since the interceptor properties are not read from a file. The properties are now entered in the admin console Custom Properties link of the interceptor using the admin console or scripts. These properties then are made available to the implementation in the init(Properties) method. However, for backward compatibility, the init(String) method still is supported.

    The init(String) method is called by the default implementation of init(Properties) as shown in the following example. 

    // Default implementation of init(Properties props) method. A Custom
   
// implementation should override this.
   public int init (java.util.Properties props)
   {
      String type = 
       props.getProperty("com.ibm.wsspi.security.trustassociation.types");
      String classfile=
       props.getProperty("com.ibm.wsspi.security.trustassociation."
       +type+".config");
      if (classfile != null &&
         classfile.length() > 0 ) {
         return init(classfile);
      } else {
         return -1;
      }
   }

    Change the implementation to implement the init(Properties) method instead of relying on init(String propsfile) method. As shown in the previous example, this default implementation reads the properties to load the property file. The com.ibm.wsspi.security.trustassociation.types property gets the file containing the properties by concatenating .config to its value.

    The init(String) method still works to use it instead of implementing the init(Properties) method. The only requirement is that the file name containing the custom trust association properties should now be entered using the Custom Properties link of the interceptor in the admin console or by using scripts. We can enter the property using either of the following methods. The first method is used for backward compatibility with previous versions of WAS.

    Method 1:

    The same property names used in the previous release are used to obtain the file name. The file name is obtained by concatenating the .config to the com.ibm.wsspi.security.trustassociation.types property value. If the file name is called myTAI.properties and is located in...

    APP_ROOT/properties

    ...set the following properties:

    • com.ibm.wsspi.security.trustassociation.types = myTAItype

    • com.ibm.wsspi.security.trustassociation.myTAItype.config = APP_ROOT/properties/myTAI.properties

    Method 2:

    We can set the com.ibm.wsspi.security.trustassociation.initPropsFile property in the trust association custom properties to the location of the file. For example, set the following property: 

    • com.ibm.wsspi.security.trustassociation.initPropsFile=

      APP_ROOT/properties/myTAI.properties

    Type the previous code as one continuous line.

    The location of the properties file is fully qualified (for example, APP_ROOT/properties/myTAI.properties). Because the location can be different in an ND environment, use variables such as ${USER_INSTALL_ROOT} to refer to the WAS installation directory. For example, if the file name is called myTAI.properties and it is located in...

    APP_ROOT/properties

    ... then set the following properties:

  3. Compile the implementation once we have implemented it. For example, APP_ROOT/java/bin/javac -classpath install_root/plugins/com.ibm.ws.runtime.jar;<install_root>/lib/j2ee.jar myTAIImpl.java

    1. Copy the class file to a location in the class path, preferably...

      APP_ROOT/lib/ext

      This file needs to be copied to each node class path and each cell class path.

      The classes need to be copied to the APP_ROOT/lib/ext directory because the directory is referenced at the beginning of the startup.

      For the most part, compilation is dependant on this directory being loaded first using the bootstrap.

    2. Restart all the servers.

  4. Delete the default WebSEAL interceptor in the admin console and click New to add the custom interceptor. Verify that the class name is dot separated and appears in the class path.

  5. Click the Custom Properties link to add additional properties that are required to initialize the custom interceptor.

    These properties are passed to the init(Properties) method of the implementation when it extends the com.ibm.wsspi.security.WebSphereBaseTrustAssociationInterceptor as described in the previous step.

  6. Save and synchronize (if applicable) the configuration.

  7. Restart the servers for the custom interceptor to take effect.

 

Example

Refer to the Security: Resources for Learning article for a reference to an example of a custom interceptor.


Trust association interceptor support for Subject creation

 

Related concepts


Single sign-on for authentication using LTPA cookies
Web component security

 

Related tasks


Develop a custom trust association interceptor

 

Related


Directory conventions