+

Search Tips   |   Advanced Search

Configure authentication filters

The portal authentication filters are a set of plug-in points. Use them to intercept or extend...

  • portal login
  • logout
  • session timeout
  • request processing

For example to redirect users to a specific URL.


The authentication filter chain concept

The authentication filters in the portal use the same pattern as defined by the J2EE servlet filter facility. A default filter performs the default logic for a particular use case, for example, login. We can chain a set of custom filters to be executed before that default filter. The last element of the chain is the predefined DefaultFilter that makes sure the default logic for the respective use case is executed. After a filter has been executed or if an exception is thrown, each filter returns to the one that has called it, so it is possible to implement a customized exception handling or perform additional operations after having called the successor. This way we can chain a custom set of filters. Each custom filter can perform operations before and after the following element(s) in the chain. We can specify the order and the fully qualified class names of the custom filters by portal configuration properties. The portal provides only the DefaultFilter implementations, and enforces that they are always the last element in the chains; if there are no custom login filters defined, the default filters are the only element.


Available authentication filter chains

The filter chain is applied to six types of events...

    Explicit login Login by user name and password, either through login portlet or the login URL. com.ibm.portal.auth.ExplicitLoginFilter
    Implicit login When a user is already authenticated by WAS, but not yet to Portal. com.ibm.portal.auth.ImplicitLoginFilter.
    Explicit logout The user triggers a logout action directly, for example by clicking the Logout button in the user interface. com.ibm.portal.auth.ExplicitLogoutFilter
    Implicit logout After a session timeout, or if an authenticated user accesses a public page, or if the user navigates to a virtual portal without being member of the associated user realm. com.ibm.portal.auth.ImplicitLogoutFilter
    Session Timeout Called immediately after an idle timeout of the user session occurred. com.ibm.portal.auth.SessionTimeoutFilter
    Session Validation Called for every request before actions are triggered and the page is rendered. com.ibm.portal.auth.SessionValidationFilter

Other than the session timeout filter, each of the previous filters has access to the HTTP request and response objects. A special context object can be used to share information between filters and set redirects that are executed after the filter chain has been processed.


Configure the filter chains

We can specify the order of filters for each filter chain by setting the following properties in the portal WP Authentication Service:

    login.explicit.filterchain colon or semicolon-separated list of FQ class names
    login.implicit.filterchain colon or semicolon-separated list of FQ class names
    logout.explicit.filterchain colon or semicolon-separated list of FQ class names
    logout.implicit.filterchain colon or semicolon-separated list of FQ class names
    sessiontimeout.filterchain colon or semicolon-separated list of FQ class names
    sessionvalidation.filterchain colon or semicolon-separated list of FQ class names

Use the properties to specify only the custom filter elements, as the default filter implementation is added implicitly by the Portal infrastructure. By default no value is set for the properties. In addition, we can set properties in the portal WP Authentication Service according to the following pattern:

    filterchain.properties.FQ class name of the filter implementation.property name

This makes the value of this property available in the filter configuration object of the specified class using the key property name .


Example of a custom authentication filter

The following gives an example of a custom filter plugged into the filter chain for the explicit Portal login. The custom filter holds properties that define particular redirect URLs for particular user IDs and triggers the corresponding redirect if one of those users logged in successfully. To implement such an example...

  1. Implement the com.ibm.portal.auth.ExplicitLoginFilter interface and make the class available to the portal class path by adding the JAR file to the extended classpath directory of the HCL WebSphere Portal application:

      PORTAL_HOME/shared/app

    Implement the methods of the interface... 

      package com.ibm.portal.example;

public class UserRedirectLoginFilter implements ExplicitLoginFilter 
{
     // Hash map to store the mappings from user id to redirect URL        
     private java.util.Map userToRedirectURLs = new java.util.HashMap();

     public void init(SecurityFilterConfig filterConfig)
     throws SecurityFilterInitException 
     {
         // Iterate the list of init parameters and store the mappings of user to redirect urls for         
         (java.util.Iterator it = filterConfig.getInitParameterNames(); it.hasNext(); ) 
         {
             String currentParameter = (String)it.next();
             userToRedirectURLs.put(currentParameter, filterConfig.getInitParameter(currentParameter));
         }
    }

    public void login(HttpServletRequest req, 
                      HttpServletResponse resp, 
                      String userID, 
                      char[] password, 
                      FilterChainContext portalLoginContext, 
                      Subject subject,   
                      String realm, 
                      ExplicitLoginFilterChain chain) throws LoginException, 
                                                             WSSecurityException, 
                                                             PasswordInvalidException, 
                                                             UserIDInvalidException, 
                                                             AuthenticationFailedException, 
                                                             AuthenticationException,
                                                             SystemLoginException, 
                                                             com.ibm.portal.auth.exceptions.LoginException 
     {
       // Call the next element in the filter chain to trigger the default login.
       chain.login(req, resp, userID, password, portalLoginContext, subject, realm);

       // If no exception occured, the login was successful.
       if (userToRedirectURLs.containsKey(userID)) 
       {
           // set the redirect url for the user if we have an entry            
           portalLoginContext.setRedirectURL((String)userToRedirectURLs.get(userID));
       }
    }
    public void destroy() 
    {
     // nothing to do here     
     }
 }

  2. Specify the class name of the custom filter in the WP Authentication Service properties:

      login.explicit.filterchain=com.ibm.portal.example.UserRedirectLoginFilter

  3. To define the redirect URLs for individual user IDs, specify your custom set of properties for this class accordingly. Example: 
    filterchain.properties.com.ibm.portal.example.UserRedirectLoginFilter.alice=/wps/myportal/pageA
filterchain.properties.com.ibm.portal.example.UserRedirectLoginFilter.bob=/wps/myportal/pageB

  4. Restart the portal.
The new filter for the explicit login is now available. Users defined in the properties will be redirected to the specified URL after logging in through the login portlet or login URL.


Parent Configure portal behavior