Acegi login failure: redirect gets lost in Websphere v6.1

[wpraet]

Hi,

I still have problems getting Acegi to work as it should in Websphere v6.1 (despite all 'fixes' described here, here and here, which I have applied but only partially improve the situation ).

I use a 'standard' acegi setup, with a sequence of usernamepassword authentication, anonymous authentication and rememberme authentication. The applicationcontext-security.xml of my app is attached to this post.

For the logout I wrote my own Spring controller, doing a session invalidate, a removal of the rememberme cookie and an acegi clearcontext, since the redirect when using /j_acegi_logout in Websphere v6.1 gets lost somewhere.

However, for the login part I would like to keep the setup as I have it now, I don't want to write my own login controller doing the same steps as Acegi already does, simply because Websphere is swallowing the redirects when issued from within a servlet-filter.

Logging in goes fine (i.e. the context is filled correctly, and the redirect goes to the page saved under the ACEGI_SAVED_REQUEST_KEY key) as long as you don't type anything wrong. However, when you throw an exception during login, Acegi should redirect either to a .jsp specified in the exceptionMappings list, either to the 'default' authenticationFailureUrl. And this is were things go wrong in Websphere v6.1. It will perform a cookie cancel, a clearcontext and session invalidate, but then it looses the redirect sent from within the org.acegisecurity.ui.AbstractProcessingFilter, and retries redirecting again to the /j_acegi_security_check URL (for the second time thus, ending in a blank html page displayed to the user), and I have no clue where this is happening, since the URL I specified in the redirect is /login.jsp?login_error=1.

Attached is as well the logging for the same sequence of events -mistyping a username duing login- in Tomcat5.5 (which works fine) and Websphere v6.1.
The empty line in the logfiles is where things start to go wrong in Websphere v6.1.

Did anyone manage to get redirects working fine when throwing acegi AuthenticationExceptions in WASv6.1? Ah, and yes: I'm already running the latest WASv6.1.0.9 FP. It seems that quite some things get broken with each new release of Websphere, even if those worked fine on previous releases. I've been using the SpringFramework on WASv5.1, WASv6.0 and now on WASv6.1, and with each new release things seem to be worse.

Not meaning to be rude, but I wonder what the certification means?

[wpraet]

Just for anyone who wants to know: this issue got fixed in FixPack 6.1.0.11, which was released earlier this week.

[kantorn]

Just for anyone who wants to know: this issue got fixed in FixPack 6.1.0.11, which was released earlier this week.

Hi!

Is it!?

I get "HTTP 404 Not Found" on a brand new 6.1.0.11 install


Acegi log:

[2007-10-18 11:18:07,839] DEBUG org.acegisecurity.context.HttpSessionContextIntegrationFilter New SecurityContext instance will be associated with SecurityContextHolder 
[2007-10-18 11:18:07,849] DEBUG org.acegisecurity.util.FilterChainProxy / at position 2 of 6 in additional filter chain; firing Filter: 'org.acegisecurity.ui.webapp.AuthenticationProcessingFilter@64166416' 
[2007-10-18 11:18:07,849] DEBUG org.acegisecurity.util.FilterChainProxy / at position 3 of 6 in additional filter chain; firing Filter: 'org.acegisecurity.ui.rememberme.RememberMeProcessingFilter@153c153c' 
[2007-10-18 11:18:07,849] DEBUG org.acegisecurity.util.FilterChainProxy / at position 4 of 6 in additional filter chain; firing Filter: 'org.acegisecurity.providers.anonymous.AnonymousProcessingFilter@4ae24ae2' 
[2007-10-18 11:18:07,849] DEBUG org.acegisecurity.providers.anonymous.AnonymousProcessingFilter Populated SecurityContextHolder with anonymous token: 'org.acegisecurity.providers.anonymous.AnonymousAuthenticationToken@52a3eba1: Username: anonymous; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@3bcc: RemoteIpAddress: 193.10.23.36; SessionId: null; Granted Authorities: ROLE_ANONYMOUS' 
[2007-10-18 11:18:07,849] DEBUG org.acegisecurity.util.FilterChainProxy / at position 5 of 6 in additional filter chain; firing Filter: 'org.acegisecurity.ui.ExceptionTranslationFilter@7700770' 
[2007-10-18 11:18:07,849] DEBUG org.acegisecurity.util.FilterChainProxy / at position 6 of 6 in additional filter chain; firing Filter: 'org.acegisecurity.intercept.web.FilterSecurityInterceptor@5a345a34' 
[2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Converted URL to lowercase, from: '/'; to: '/' 
[2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Candidate is: '/'; pattern is /secret/*; matched=false 
[2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Candidate is: '/'; pattern is /login.do; matched=false 
[2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Candidate is: '/'; pattern is /pics/*; matched=false 
[2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Candidate is: '/'; pattern is /theme/*; matched=false 
[2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Candidate is: '/'; pattern is /service/dump.do*; matched=false 
[2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Candidate is: '/'; pattern is /**; matched=true 
[2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.AbstractSecurityInterceptor Secure object: FilterInvocation: URL: /; ConfigAttributes: [ROLE_ANONYMOUS, ROLE_STUDY] 
[2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.AbstractSecurityInterceptor Previously Authenticated: org.acegisecurity.providers.anonymous.AnonymousAuthenticationToken@52a3eba1: Username: anonymous; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@3bcc: RemoteIpAddress: 193.10.23.36; SessionId: null; Granted Authorities: ROLE_ANONYMOUS 
[2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.AbstractSecurityInterceptor Authorization successful 
[2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.AbstractSecurityInterceptor RunAsManager did not change Authentication object 
[2007-10-18 11:18:07,849] DEBUG org.acegisecurity.util.FilterChainProxy / reached end of additional filter chain; proceeding with original chain 
[2007-10-18 11:18:08,310] DEBUG org.acegisecurity.context.HttpSessionContextIntegrationFilter SecurityContext stored to HttpSession: 'org.acegisecurity.context.SecurityContextImpl@52a3eba1: Authentication: org.acegisecurity.providers.anonymous.AnonymousAuthenticationToken@52a3eba1: Username: anonymous; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@3bcc: RemoteIpAddress: 193.10.23.36; SessionId: null; Granted Authorities: ROLE_ANONYMOUS' 
[2007-10-18 11:18:08,310] DEBUG org.acegisecurity.ui.ExceptionTranslationFilter Chain processed normally 
[2007-10-18 11:18:08,310] DEBUG org.acegisecurity.context.HttpSessionContextIntegrationFilter SecurityContextHolder now cleared, as request processing completed 
[2007-10-18 11:18:08,330] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Converted URL to lowercase, from: '/login.do'; to: '/login.do' 
[2007-10-18 11:18:08,330] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Candidate is: '/login.do'; pattern is /**; matched=true 
[2007-10-18 11:18:08,330] DEBUG org.acegisecurity.util.FilterChainProxy /login.do at position 1 of 6 in additional filter chain; firing Filter: 'org.acegisecurity.context.HttpSessionContextIntegrationFilter@8d408d4' 
[2007-10-18 11:18:08,330] DEBUG org.acegisecurity.context.HttpSessionContextIntegrationFilter Obtained a valid SecurityContext from ACEGI_SECURITY_CONTEXT to associate with SecurityContextHolder: 'org.acegisecurity.context.SecurityContextImpl@52a3eba1: Authentication: org.acegisecurity.providers.anonymous.AnonymousAuthenticationToken@52a3eba1: Username: anonymous; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@3bcc: RemoteIpAddress: 193.10.23.36; SessionId: null; Granted Authorities: ROLE_ANONYMOUS' 
[2007-10-18 11:18:08,330] DEBUG org.acegisecurity.util.FilterChainProxy /login.do at position 2 of 6 in additional filter chain; firing Filter: 'org.acegisecurity.ui.webapp.AuthenticationProcessingFilter@64166416' 
[2007-10-18 11:18:08,330] DEBUG org.acegisecurity.util.FilterChainProxy /login.do at position 3 of 6 in additional filter chain; firing Filter: 'org.acegisecurity.ui.rememberme.RememberMeProcessingFilter@153c153c' 
[2007-10-18 11:18:08,330] DEBUG org.acegisecurity.ui.rememberme.RememberMeProcessingFilter SecurityContextHolder not populated with remember-me token, as it already contained: 'org.acegisecurity.providers.anonymous.AnonymousAuthenticationToken@52a3eba1: Username: anonymous; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@3bcc: RemoteIpAddress: 193.10.23.36; SessionId: null; Granted Authorities: ROLE_ANONYMOUS' 
[2007-10-18 11:18:08,330] DEBUG org.acegisecurity.util.FilterChainProxy /login.do at position 4 of 6 in additional filter chain; firing Filter: 'org.acegisecurity.providers.anonymous.AnonymousProcessingFilter@4ae24ae2' 
[2007-10-18 11:18:08,330] DEBUG org.acegisecurity.providers.anonymous.AnonymousProcessingFilter SecurityContextHolder not populated with anonymous token, as it already contained: 'org.acegisecurity.providers.anonymous.AnonymousAuthenticationToken@52a3eba1: Username: anonymous; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@3bcc: RemoteIpAddress: 193.10.23.36; SessionId: null; Granted Authorities: ROLE_ANONYMOUS' 
[2007-10-18 11:18:08,330] DEBUG org.acegisecurity.util.FilterChainProxy /login.do at position 5 of 6 in additional filter chain; firing Filter: 'org.acegisecurity.ui.ExceptionTranslationFilter@7700770' 
[2007-10-18 11:18:08,330] DEBUG org.acegisecurity.util.FilterChainProxy /login.do at position 6 of 6 in additional filter chain; firing Filter: 'org.acegisecurity.intercept.web.FilterSecurityInterceptor@5a345a34' 
[2007-10-18 11:18:08,330] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Converted URL to lowercase, from: '/login.do'; to: '/login.do' 
[2007-10-18 11:18:08,330] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Candidate is: '/login.do'; pattern is /secret/*; matched=false 
[2007-10-18 11:18:08,330] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Candidate is: '/login.do'; pattern is /login.do; matched=true 
[2007-10-18 11:18:08,330] DEBUG org.acegisecurity.intercept.AbstractSecurityInterceptor Secure object: FilterInvocation: URL: /login.do; ConfigAttributes: [ROLE_ANONYMOUS] 
[2007-10-18 11:18:08,330] DEBUG org.acegisecurity.intercept.AbstractSecurityInterceptor Previously Authenticated: org.acegisecurity.providers.anonymous.AnonymousAuthenticationToken@52a3eba1: Username: anonymous; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@3bcc: RemoteIpAddress: 193.10.23.36; SessionId: null; Granted Authorities: ROLE_ANONYMOUS 
[2007-10-18 11:18:08,330] DEBUG org.acegisecurity.intercept.AbstractSecurityInterceptor Authorization successful 
[2007-10-18 11:18:08,330] DEBUG org.acegisecurity.intercept.AbstractSecurityInterceptor RunAsManager did not change Authentication object 
[2007-10-18 11:18:08,330] DEBUG org.acegisecurity.util.FilterChainProxy /login.do reached end of additional filter chain; proceeding with original chain 
[2007-10-18 11:18:08,340] DEBUG org.ki.biobank.elsa.web.MultiactionController Show login invoked 
[2007-10-18 11:18:08,490] DEBUG org.acegisecurity.ui.ExceptionTranslationFilter Chain processed normally 
[2007-10-18 11:18:08,490] DEBUG org.acegisecurity.context.HttpSessionContextIntegrationFilter SecurityContextHolder now cleared, as request processing completed

Very grateful for nay ideas at all.....

[wpraet]

Hi there,

did you set the

com.ibm.ws.webcontainer.invokefilterscompatibility

property in the webcontainer to 'true'?

[kantorn]

Yes, I did. Still no cigar.

Hi,
Not meaning to be rude, but I wonder what the certification means?

Your're not beeing rude, I think it's a very reasonable question......

[kantorn]

Seems like I have to ditch Spring Security.
Very sad.

[Marten Deinum]

Not meaning to be rude, but I wonder what the certification means?

Spring FRAMEWORK is certified for Websphere not ACEGI Security, don't mix things up.

Also you might have some problems in your setup.

Why do you process jsp by acegi? it can be very well that requests to *.jsp get cut off before even being processed.

Also making your jsp's publicly available isn't wise, I would put them in /WEB-INF/jsp and configure everything to pass through the dispatcher servlet (i.e. *.do etc). Use a ViewResolver to retrieve the correct jsp.

Also I'm not sure if you need to or if it is wise to include the acegi urls in your security or even ommit certain filters from those chains!

In your configuration

<property name="authenticationFailureUrl" value="login.jsp?login_error=1"/>
<property name="useRelativeContext" value="true"/>

You use a relative path you might want to try an absolute path, else it might get appended to /j_acegi_security_check or something, which could also screw up things.

Just a few thoughts at first glance at your configuration.

[kantorn]

Spring FRAMEWORK is certified for Websphere not ACEGI Security, don't mix things up.

Also you might have some problems in your setup.

Why do you process jsp by acegi? it can be very well that requests to *.jsp get cut off before even being processed.

Also making your jsp's publicly available isn't wise, I would put them in /WEB-INF/jsp and configure everything to pass through the dispatcher servlet (i.e. *.do etc). Use a ViewResolver to retrieve the correct jsp.

Also I'm not sure if you need to or if it is wise to include the acegi urls in your security or even ommit certain filters from those chains!

In your configuration

<property name="authenticationFailureUrl" value="login.jsp?login_error=1"/>
<property name="useRelativeContext" value="true"/>

You use a relative path you might want to try an absolute path, else it might get appended to /j_acegi_security_check or something, which could also screw up things.

Just a few thoughts at first glance at your configuration.

Thanks for answering.

I have my JSPs in WEB-INF/jsp, and they are dispatched using a ViewResolver.

No, the relative/not relative approach doesn't make things better.

Also I'm not sure if you need to or if it is wise to include the acegi urls in your security or even ommit certain filters from those chains!

I don't quite understand, could you clarify by an example?

Thanks!

[Luke Taylor]

Seems like I have to ditch Spring Security.
Very sad.

Can't you ditch websphere instead .

[kantorn]

Can't you ditch websphere instead .

Believe me; if I could I would!!!



I mean, what is with these products not adhering to the most basic of Java EE specs!? And still people pay for it, a lot!

Can I implement a controller of my own simulationg the behaviour of the login filter?