The customer had previously reported ICE-3707 but has noticed a similar security issue with Websphere 6.1 and JAAS after upgrading to 1.8. They had to comment out the isInstance check in the BridgeExternalContext classes detectAuthorization() method.

Ideally, they would like us to implement a generic or pluggable AuthenticationVerifier as the the issue with WebSphere 6.1 is that the request does not properly process the isUserInRole method for cached requests.

Here are some more details:

This issue has again arisen in 1.8 because we are doing an isInstance check against a Java security principal object. In 1.7.2 the customer used the following custom class based on ACEgi to get around this. Here is the method in the BridgeFacesContext:

protected Authorization detectAuthorization(final Principal principal) {
Log.debug("overriding detectAuthorization for JAAS.");
if (AuthenticationClass != null /*&& (null == principal || AuthenticationClass.isInstance(principal))*/) {
return SpringAuthenticationClass == null ? AcegiAuthWrapper.getVerifier(principal, sessionMap) : SpringAuthWrapper.getVerifier(principal, sessionMap);
} else {
return defaultAuthorization;
}
}

The code is commented out because the principal is not null, but the isInstance of the Acegi AuthenticationClass is returning false based on our "modified" acegi class. WebSphere has a pool of HttpRequests, and the BlockingServlet can't use the principal from the initial request because it has been pushed back into the pool.

Here is the code that they specifically changed:

AuthenticationClass.isInstance(principal)) <- the principal (in WebSphere) is never a instance of AuthenticationClass because the customer is creating their our own Acegi based authentication classes.