Page 1 of 3 123 LastLast
Results 1 to 10 of 26

Thread: Spring Security 2 not working with WebSphere?

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

    Default 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?
    Kent Rancourt
    DevOps Engineer

  2. #2
    Luke Taylor is offline Senior Member Acegi Security System TeamSpring Team
    Join Date
    Aug 2004
    Location
    Glasgow, Scotland
    Posts
    3,449

    Default

    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.

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

    Default

    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!
    Kent Rancourt
    DevOps Engineer

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

    Default

    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
    Kent Rancourt
    DevOps Engineer

  5. #5

    Default

    Thank you!! This was driving me crazy. Worked beautifully.

    Regards,
    Angel

  6. #6
    Join Date
    Jul 2005
    Posts
    105

    Default

    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.

  7. #7
    Join Date
    Sep 2004
    Posts
    602

    Default

    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 ?

  8. #8
    Luke Taylor is offline Senior Member Acegi Security System TeamSpring Team
    Join Date
    Aug 2004
    Location
    Glasgow, Scotland
    Posts
    3,449

    Default

    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?

  9. #9
    Join Date
    Jul 2005
    Posts
    105

    Default

    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.

  10. #10
    Join Date
    Jul 2008
    Posts
    1

    Talking 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.

Posting Permissions

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