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)

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

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