Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 26

Thread: Spring Security 2 not working with WebSphere?

  1. #11
    Join Date
    Jul 2008
    Posts
    2

    Unhappy

    Can somebody tell me how can I use spring security 2 on WAS 6.0? Thanks in advance.

  2. #12
    Join Date
    Sep 2004
    Posts
    602

    Default

    Quote Originally Posted by raymond.lau View Post
    Can somebody tell me how can I use spring security 2 on WAS 6.0? Thanks in advance.
    Configure it as per the manual, check it works in Tomcat, deploy it in WAS. That is all you have to do in theory, apart from making sure your WAS is patched to the max. Also make sure you have PARENT_LAST on classloaders.

  3. #13
    Join Date
    Jul 2008
    Location
    Antwerp, Belgium
    Posts
    1

    Default

    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.

  4. #14
    Join Date
    Jul 2005
    Posts
    105

    Default

    Quote Originally Posted by diedrikk View Post
    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.
    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.

  5. #15
    Join Date
    Jul 2008
    Posts
    2

    Default

    Quote Originally Posted by Paul Newport View Post
    Configure it as per the manual, check it works in Tomcat, deploy it in WAS. That is all you have to do in theory, apart from making sure your WAS is patched to the max. Also make sure you have PARENT_LAST on classloaders.
    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.

  6. #16
    Join Date
    Apr 2006
    Posts
    5

    Default

    Quote Originally Posted by inkspot23 View Post
    The instructions and links worked for our cluster and j_security session issue. Our version is 6.1.0.15 and it worked. Thanks for the followup.
    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.

  7. #17
    Join Date
    Mar 2009
    Posts
    2

    Default

    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.

  8. #18

    Default Spring Security also not working on WebSphere

    Quote Originally Posted by nsjxu View Post
    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)

  9. #19
    Join Date
    Sep 2006
    Location
    Hartford, CT
    Posts
    145

    Default

    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

  10. #20

    Default

    Quote Originally Posted by krancour View Post
    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.
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •