jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "McGinn, John" <John.McG...@mail.thomson.com>
Subject Info regarding WebSphere, Cactus/StrutsUnitTest, & FormAuthentica tion
Date Wed, 09 Mar 2005 20:20:12 GMT
Hi all,
 
After quite sometime and frustration I finally got a secure
ServletTestRedirector to work with WebSphere 5.1 & FormAuthentication so
hopefully what I found will help others in avoiding this frustration.  I
think I saw a few other posts on this subject but no real resolution clearly
posted.
 
The main problem is that the Cactus FormAuthentication will not work
correctly with WebSphere for the following reasons:
1.  FormAuthentication makes 2 requests.  The first request is the main
problem.  It is a hard coded request to ServletTestRedirector (see
getSecureSessionIdCookie) and it is expecting the response to return the
JSESSIONID cookie. 
2.  WebSphere when accessing a secured resource with an UNATHORIZED user
doesn't create the JSESSIONID cookie until you are redirected to the
login.jsp.
3.  FormAuthentication uses the same HttpClientConnectionHelper.connect
method that all the other requests makers user and it prevents redirects.
4.  Thus the jsessionCookie member variable never gets initialized and then
the authenticate method gets an IllegalStateException from BaseWebRequest
when it tries and add it as a cookie to the request.
 
Additionally we are using LTPA and expect a LTPA token to be persisted for
each request or else our filter will assume the session has timed out and
redirect to the login.jsp.
 
So for my solution after getting everything configured as directed in the
How To's (including the Security How To) was to create a new Authentication
class that extends AbstractAuthentication.  I looked at extending
FormAuthentication but too many methods and its data members were private
for it to be of much use.  In my Authentication class I was able to
completely remove the getSecureSessionIdCookie and just call
/j_security_check directly with one request.  This executes our logon filter
and returns a new JSESSIONID and LtpaToken cookie.  I then persist those as
data members and stick them into any subsequent requests.  Here's the stuff
of interest:
 
public void configure(HttpState state, HttpMethod method, WebRequest
request, Configuration config)
{
	//Only authenticate the first time this instance is used.
	if (_jsessionCookie == null || _ltpaTokenCookie == null)
	{
	   authenticate(request, config);
	}

	//Sets the session id cookie and ltpa token cookie for the next
request.
	if (_jsessionCookie != null && _ltpaTokenCookie != null)
	{
		request.addCookie(_jsessionCookie);
		request.addCookie(_ltpaTokenCookie);
	}
}

public void authenticate(WebRequest request, Configuration config)
{
	try
	{
		//Create a helper that will connect to the security check
URL.
		String url = getSecurityCheckURL(config).toString();
		HttpClientConnectionHelper helper = new
HttpClientConnectionHelper(url);

		//Configure a web request with the username and the
password.
		WebRequest webRequest = getSecurityRequest();
		((WebRequestImpl)webRequest).setConfiguration(config);
		webRequest.addParameter(_userNameParamName, getName(),
WebRequest.POST_METHOD);
		webRequest.addParameter(_passwordParamName, getPassword(),
WebRequest.POST_METHOD);

		// Make the connection using the configured web request.
		HttpURLConnection connection = helper.connect(webRequest,
config);

		checkAuthResponse(connection);

		_jsessionCookie = getCookie(connection, _sessionCookieName);
		_ltpaTokenCookie = getCookie(connection, _ltpaCookieName);


	}

	catch (Throwable e)
	{
		_jsessionCookie = null;
		_ltpaTokenCookie = null;
		throw new ChainedRuntimeException("Failed to authenticate
the principal", e);
	}
}

Then of course I use this new Authentication class in my test case's begin
methods.

Hope that helps,

John

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message