IE's Privacy Actions cause intermittant web security exceptions...

[jdepaul]

We have a simple web application deployed on WebSphere 6.1.0.23 (Unix) - the app is secured with Spring 2.0.x security module and the back end is Spring 2.5.3 (just simple MVC).

We've developed a Custom PreAuthentication filter that validates user credentials and performs proper login. During integration testing we discovered that there were intermittent problems with authentication and that sometimes we were mysteriously re-directed to the Login page.

These problems were isolated to only IE (we're using 6.0.2900.x). Turns out that when you explicitly add the external domain name of our site to the site specific actions in IE (Tools > Options > Privacy > Sites > ALLOW our domain), then the web application's security functions perfectly. If the site is not explicitly in the list the security sometimes does NOT work in IE but it always seems to work in FireFox. This is obviously a problem for our users that we'd like to resolve on our end...

We've used the TCP/IP monitor to examine the headers that the browser is issuing in each case and although I can see some small differences between FF and IE but I do not see ANY differences in headers sent by IE when the Privacy settings are in place or when they are NOT in place - these two requests look identical in TCPIP monitor, but the results in our app are vastly different... What we can't figure out is what is different between those requests that our application 'sees' - we can see in the server logs that the request is validated so the login screen is a big mystery to us...

If someone could give some clues in this area I'd appreciate. See attached file for our security configuration...

[Luke Taylor]

What does your custom filter do? How does it authenticate the user. Presumably it's something to do with that, since if the authentication succeeded there you would not end up at the login page...

[jdepaul]

What does your custom filter do? How does it authenticate the user. Presumably it's something to do with that, since if the authentication succeeded there you would not end up at the login page...

Solve the problem - for the benefit of others reading this it had to do with third party cookies NOT being sent to our application from the browser...

Since our application fills in a portion of the page on another website the browser privacy settings were preventing the cookies being sent to our application... So the flow was as follows: the initial request would hit my custom filter and be properly authenticated, the framework would then do a browser re-direct (by default) which hit the remote browser and came back to the application again to redisplay the details, BUT this time without the cookie that represents the link to the Session, and thus it was rejected by the AbstractProcessingFilter and redirected to login page... It would be possible to set the browser settings to 'trust' our site and thus allow the cookie being set but that would require all IE users to do this... So, we ended up using URL re-write to handle the sessions (another thread) and that seems to be working now though we're still testing.

Thanks,
james