Can somebody tell me how can I use spring security 2 on WAS 6.0? Thanks in advance.
Can somebody tell me how can I use spring security 2 on WAS 6.0? Thanks in advance.
Upgrading to WebSphere 6.1.0.17 indeed gives the HTTP 404 (File not found) on both the login and logout processing url.
The IBM fix - specifying the option com.ibm.ws.webcontainer.invokefilterscompatibility - works fine to get them back working, but unfortunately it leads to another defect.
Somehow WebSphere fails to pass the SavedRequestAwareWrapper instance to the JSP if the url has a trailing slash. To give an example; the url "...mysite.com/index.jsp" works well, the url "...mysite.com/" doesn't, although in both cases the same (welcome) page is being called.
In the first scenario, the authenticated principal is available through the request object (instanceof SavedRequestAwareWrapper). In the second scenario I get an unauthenticated request (instanceof com.ibm.ws.webcontainer.srt.SRTServletRequest).
Anyway, instead of setting that web-container option I decided to map a dummy servlet to the filterProcessesUrl I use within spring security, a similar approach as mentioned by Luke Taylor.
<servlet>
<servlet-name>SpringSecurityServlet</servlet-name>
<servlet-class>sample.SpringSecurityServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>SpringSecurityServlet</servlet-name>
<url-pattern>/j_security_login</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>SpringSecurityServlet</servlet-name>
<url-pattern>/j_security_logout</url-pattern>
</servlet-mapping>
These servlet-mappings also allow us to disable the fileServingEnabled flag and to have our HTTP server handle all static content. Perhaps it makes sense for Spring Security to move the login/logout process out of the filters and have them defined as basic servlets. It’s a little bit more to configure in the web.xml, but it allows the web-container to know which urls it should serve. We cannot (yet) expect WebSphere to parse the spring security configuration, right?
Ciao, D.
Yes, it is not uncommon for an IBM "fixpack" to break something else.
In my experience, the IBM folks strongly encourage application (i.e. Java EE) security to be enabled. Therefore I suspect that the test cases they use for internal regression testing just don't focus on situations where security is turned off, leading to more-or-less eternal problems in this realm.
Frankly, it may simply be easier all around to enable Websphere security. IBM argues that the security mechanisms in place are stronger than what you'd get from "doing it yourself," and, since you are using the application server anyways, you may as well make use of what you have. Yes, your portability is somewhat decreased, but you've minimized the damage to simply a different XML file if you need to run on, say, Tomcat for testing / development. This is no different than other parts of a system which may need Websphere-specific configurations (for instance, the WebsphereUowTransactionManager).
I did a PoC here at my company which integrates container authentication into SS2. Not using Java EE security was as simple as flipping a switch.
My WAS6.0 has been packed to become 6.0.2.29 which is the latest pack for WAS6. In addition, I have added the custom properties. For now, I can, at least, execute the sample code of spring security. But, I'm not sure whether it will lead another problem. I will try and see. Thanks for your recommendation.
Hi inkspot23,
Could you give me some details on how you got this work on a cluster environment?
We are facing the situation where we can have this worked in our local environments using WAS 6.1.0.21, but when we deploy to production environment where we have a cluster environment, it does not work. The settings are the same on both environments: (1) Defining the custom property for Web container; (2) The fix pack PK33090 should already be included in WAS 6.1.0.21; (3) Classloaders set to PARENT_FIRST
Thank you very much in advance.
I have a web app that works on tomcat. But it does not work on both Websphere 6.1.0.17 and 6.1.0.21 with com.ibm.ws.webcontainer.invokefilterscompatibility set to true. It complains
Error 404: SRVE0190E: File not found: /j_spring_security_check. I'm not sure how to work around this one. Any help/advice would be much appreciated.
I'm in the same boat: a WAS 6.1.0.21 clustered environment. App & security work fine under Tomcat, do not in WebSphere.
I've set the com.ibm.ws.webcontainer.invokefilterscompatibility customer parameter to true and put a dummy "blank" j_acegi_security_check file in the root of the application.
So it's no longer throwing the file not found exception, but it throws the following error/stack trace:
Error Message: Filter [springSecurityFilterChain]: filter is unavailable.
Error Code: 500
Target Servlet: null
java.lang.NullPointerException
at com.xxx.orderlink.model.MenuFactory.isAuthorized(M enuFactory.java:257)
at com.xxx.orderlink.model.MenuFactory.getSessionMenu Code(MenuFactory.java:124)
at com.xxx.p3.service.security.AuthenticationProcessi ngFilter.initializeMenu(AuthenticationProcessingFi lter.java:128)
at com.xxx.p3.service.security.AuthenticationProcessi ngFilter.onSuccessfulAuthentication(Authentication ProcessingFilter.java:47)
at org.springframework.security.ui.AbstractProcessing Filter.successfulAuthentication(AbstractProcessing Filter.java:367)
at org.springframework.security.ui.AbstractProcessing Filter.doFilterHttp(AbstractProcessingFilter.java: 263)
at org.springframework.security.ui.SpringSecurityFilt er.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy $VirtualFilterChain.doFilter(FilterChainProxy.java :371)
at org.springframework.security.ui.logout.LogoutFilte r.doFilterHttp(LogoutFilter.java:87)
at org.springframework.security.ui.SpringSecurityFilt er.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy $VirtualFilterChain.doFilter(FilterChainProxy.java :371)
at org.springframework.security.ui.SessionFixationPro tectionFilter.doFilterHttp(SessionFixationProtecti onFilter.java:68)
at org.springframework.security.ui.SpringSecurityFilt er.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy $VirtualFilterChain.doFilter(FilterChainProxy.java :371)
at org.springframework.security.context.HttpSessionCo ntextIntegrationFilter.doFilterHttp(HttpSessionCon textIntegrationFilter.java:235)
at org.springframework.security.ui.SpringSecurityFilt er.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy $VirtualFilterChain.doFilter(FilterChainProxy.java :371)
at org.springframework.security.concurrent.Concurrent SessionFilter.doFilterHttp(ConcurrentSessionFilter .java:97)
at org.springframework.security.ui.SpringSecurityFilt er.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy $VirtualFilterChain.doFilter(FilterChainProxy.java :371)
at org.springframework.security.util.FilterChainProxy .doFilter(FilterChainProxy.java:174)
at org.springframework.web.filter.DelegatingFilterPro xy.invokeDelegate(DelegatingFilterProxy.java:183)
at org.springframework.web.filter.DelegatingFilterPro xy.doFilter(DelegatingFilterProxy.java:138)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapp er.doFilter(FilterInstanceWrapper.java:190)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.d oFilter(WebAppFilterChain.java:130)
at org.springframework.orm.jpa.support.OpenEntityMana gerInViewFilter.doFilterInternal(OpenEntityManager InViewFilter.java:112)
at org.springframework.web.filter.OncePerRequestFilte r.doFilter(OncePerRequestFilter.java:75)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapp er.doFilter(FilterInstanceWrapper.java:190)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.d oFilter(WebAppFilterChain.java:130)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain._ doFilter(WebAppFilterChain.java:87)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager .doFilter(WebAppFilterManager.java:832)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager .doFilter(WebAppFilterManager.java:679)
at com.ibm.ws.webcontainer.servlet.FileServletWrapper .handleRequest(FileServletWrapper.java:418)
at com.ibm.ws.wswebcontainer.servlet.StaticFileServle tWrapper.handleRequest(StaticFileServletWrapper.ja va:164)
at com.ibm.ws.webcontainer.extension.DefaultExtension Processor.handleRequest(DefaultExtensionProcessor. java:717)
at com.ibm.ws.wswebcontainer.extension.DefaultExtensi onProcessor.handleRequest(DefaultExtensionProcesso r.java:113)
at com.ibm.ws.webcontainer.webapp.WebApp.handleReques t(WebApp.java:3444)
at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequ est(WebGroup.java:267)
at com.ibm.ws.webcontainer.WebContainer.handleRequest (WebContainer.java:815)
at com.ibm.ws.wswebcontainer.WebContainer.handleReque st(WebContainer.java:1466)
at com.ibm.ws.webcontainer.channel.WCChannelLink.read y(WCChannelLink.java:119)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLi nk.handleDiscrimination(HttpInboundLink.java:458)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLi nk.handleNewInformation(HttpInboundLink.java:387)
at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCa llback.complete(HttpICLReadCallback.java:102)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListe ner.futureCompleted(AioReadCompletionListener.java :165)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallbac k(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletion Actions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture .java:136)
at com.ibm.io.async.ResultHandler.complete(ResultHand ler.java:195)
at com.ibm.io.async.ResultHandler.runEventProcessingL oop(ResultHandler.java:743)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler .java:873)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.j ava:1473)
Are you completely ignoring the first few lines of your own stack trace? The NPE you are getting is happening in your own code. Set a breakpoint and fire up the debugger.
Kent Rancourt
DevOps Engineer
Since the code works fine across multiple versions of Tomcat, I'm not convinced the problem is there.
The NPE is thrown the first time the user object stored in the session is referenced. So the symptom of a null user is just that.
The user object gets inserted into the session by a class that extends org.springframework.security.ui.webapp.Authenticat ionProcessingFilter. That part works (you can see that the onSuccessfulAuthentication method is called). So it ought to be available to the session.
And yet for some reason it isn't, but only on WebSphere.