Announcement Announcement Module
Collapse
No announcement yet.
Spring Security 2 not working with WebSphere? Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Security 2 not working with WebSphere?

    Recently SpringSource was engaged with my company and helped us to create a PoC to demonstrate how Spring Security can address many of our strategic security needs. (And to give them a plug- they are great to work with.) Ordinarily, our development, test, and production environments are WebSphere 6 or 6.1, but to accelerate development of the PoC, we used Tomcat. The time has come for me to port this over to WAS 6.1 and I'm encountering some odd behavior. I am hoping someone can shed some light on this.

    Fundamentally, we are using the basic steps outlined in countless "What's new in Spring Security 2?" articles, with some slight modifications.

    In web.xml, the following filter is defined and mapped:

    Code:
    <filter>
      <filter-name>_filterChainProxy</filter-name>
      <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
    </filter>
    <filter-mapping>
      <filter-name>_filterChainProxy</filter-name>
      <url-pattern>/*</url-pattern>
    </filter-mapping>
    And in my application context, I have the following:

    Code:
    <?xml version="1.0" encoding="UTF-8"?>
    
    <bean:beans xmlns="http://www.springframework.org/schema/security"
      xmlns:bean="http://www.springframework.org/schema/beans"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
      http://www.springframework.org/schema/security
      http://www.springframework.org/schema/security/spring-security-2.0.xsd">
    
      <http auto-config="true">
        <intercept-url pattern="/employees**" access="ROLE_EMPLOYEE"/>
        <intercept-url pattern="/employeeAwards**" access="ROLE_EMPLOYEE"/>
        <intercept-url pattern="/admin/**" access="ROLE_ADMINISTRATOR"/>
        <intercept-url pattern="/**" access="ROLE_ANONYMOUS,ROLE_EMPLOYEE"/>
        <form-login login-page="/login" authentication-failure-url="/login?login_error=1" />
        <logout logout-success-url="/login"/>
      </http>
    
      <bean:bean id="loggerListener" class="org.springframework.security.event.authentication.LoggerListener"/>
    
    </bean:beans>
    Now, my understanding may be flawed (hard to know because this next part seems poorly documented), but shouldn't the filter chain that's created by <http auto-config="true"> support login by responding to to POSTs to http://{server}:{port}/{context root}/j_spring_security_check?

    This is working just fine in Tomcat, but in WebSphere 6.1, I get the following error when attempting to login:

    Code:
    Error 404: SRVE0190E: File not found: /j_spring_security_check
    Unfortunately, I see no clues in the logs as to what may have gone wrong.

    To be clear, I haven't done anything but port this from Tomcat to WebSphere, all else has remained unchanged save for downgrading from servlet spec 2.4 to 2.5, but I believe Spring Security filters are 2.3 filters anyway, so I do not see how that should matter.

    One further note on version: when I started seeing this problem we were using a nightly snapshot of Spring Security 2 from some point in February. In trying to correct the issue, I have upgraded to RC1 and am still experiencing the same behavior.

    Can anyone shed any light on this? Have I perhaps uncovered some bizarre incompatibility with WebSphere?

  • #2
    If you search the forum and Jira there are previous discussions relating to Websphere and j_acegi_security_check (or j_spring_security_check) not being found. Websphere has a history of problems of this kind and there are various patches to address them.

    It's almost certainly not a problem related to any of the 2.0 development. I would try installing the sample war from the latest Acegi distribution and see if you get the same problem. If you do then investigate your websphere patch levels.

    Comment


    • #3
      Luke,

      Thanks for the speedy reply. I've done a fair amount of Googling over the past few days as I've tried to solve this problem. I find very few instance of "j_spring_security_check" online. Looking for "j_acegi_security_check" instead hadn't occurred to me since I guess I'd incorrectly assumed the problem was new in Spring Security (due to my having successfully used Acegi with WAS in the past).

      Hopefully expanding my search a bit now leads me to some answers.

      Thanks again!

      Comment


      • #4
        This information is available elsewhere, but to minimize the misery for anyone viewing this thread, the issue can be resolved as follows:

        1. WAS must be at fixpack 6.1.0.11 or higher.

        2. A custom property must be set on the web container so WAS will play nicely with filters that decide to commit a response instead of passing responsibility along to the next filter in the chain. com.ibm.ws.webcontainer.invokefilterscompatibility = true

        More info on the bug and the fix available here:

        http://www-1.ibm.com/support/docview...id=swg24014758

        Set this property in the WebSphere admin console using directions available here:

        http://www-1.ibm.com/support/docview...id=swg21284395

        Comment


        • #5
          Thank you!! This was driving me crazy. Worked beautifully.

          Regards,
          Angel

          Comment


          • #6
            Interestingly, if you enable Websphere Administrative Security on 6.1 (you don't have to enable application security) and you use /j_security_check as the login URL, this problem goes away without having to set the web container custom property. I suppose this is because the web container is smart enough to know that this URL is not referring to a static file in this context.

            Comment


            • #7
              Oh dear, not this old chestnut again. Been there, done that.

              Seems that WAS does not work even with the fix installed on the bodge custom property set. This is on version BASE 6.1.0.13 cf130745.06 of WAS.

              Guess it's time to install another fix pack.

              Why oh why do I have to deploy on Websphere ?

              Comment


              • #8
                As another potential fix for this recurring problem with websphere - would it work to use a login processing URL which looks as if it would be handled by a servlet mapping in your web.xml (e.g. /j_spring_security_check.htm or /j_spring_security_check.do), but would in fact be intercepted by the AuthenticationProceesingFilter as normal?

                Or does websphere have something else up its sleeve that would prevent this working?

                Comment


                • #9
                  Paul,

                  Are you sure you are setting the custom property on the Web Container, not the JVM? Mine is working on 6.1.0.15 (though who knows if they fixed the fix in that version.)

                  Luke, I would think that would work, but I haven't tried it yet.

                  Comment


                  • #10
                    Thanks krancour (security fix)

                    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.

                    Comment


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

                      Comment


                      • #12
                        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.

                        Comment


                        • #13
                          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.

                          Comment


                          • #14
                            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.

                            Comment


                            • #15
                              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.

                              Comment

                              Working...
                              X