Skip to main content

Digital Transformation

Full login filter testing for local developer environments

A majority of enterprise portal implementations utilize some kind of external authentication mechanism. To meet the ever demanding requirements in these same environment the need rises to execute custom code during login process.  Starting in WebSphere Portal 6.1 opened up this capability with the Implicit and Explicit loginfilters. (http://www.ibm.com/developerworks/websphere/library/techarticles/0905_buchwald/0905_buchwald.html)

Many environments do not require different code in the implicit vs explicit login filters or only one filter is utilized; however this is not always the situation.  Below are two examples where there is a need for both filters and possibly the execution of different code depending on the method of authenticating for portal.

  • Network SSO via an implementation of SPNEGO.  In most browsers users will be authenticated to Portal and will execute the implicit login filter.  In the event that a user accesses the portal with a Safari browser the users can login with the login portlet service and execute the explicit login filter.  In the situation the code in both filters may be the same. 
  • Internal and Externally accessible environment with only the external traffic authenticating against an external mechanism such as WebSeal.  All internal traffic, in this example, can have the requirement to execute different code for internal traffic vs external traffic. 

To properly test the implicit login filter the Developer’s local environment will need to have a local Trusted Association Interceptor (TAI) configured in order to recreate the production environments.  In breaking down the way in which users access a TAI enabled Portal environment there are 2 primary flows.  These flows both start with an unauthenticated user requesting a secured resource.

  1. User is redirected to a login page and returns with ample information in the request to pass TAI validation Form Based TAI
  2. User’s initial request contains the necessary information to pass TAI validation.  Possible examples of this would be if the user is coming from WebSEAL, or the user’s browser may already contain the proper security tokens from a SSO implementation (i.e. Ping) Cookie Based TAI

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Charles Mahoney

More from this Author

Follow Us
TwitterLinkedinFacebookYoutubeInstagram