Spring Security 2 not working with WebSphere?

[krancour]

The NPE is thrown the first time the user object stored in the session is referenced.

So is it the UserDetails object itself that is null? That's not clear from your description.

Also...

The HttpSessionContextIntegrationFilter has sole responsibility for retrieving any SecurityContext that's been cached in the HttpSession and then poking that into the SecurityContextHolder (which is essentially a threadbound container for your SecurityContext, which in turn contains an Authentication object, which in turn contains the UserDetails object).

When the NPE occurs in your code, how exactly are you accessing the UserDetails object? Are you grabbing it directly from the session yourself, or taking it from the SecurityContextHolder?

Can you post the code for the component that's throwing the NPE? That would help a lot.

[GojiraDeMonstah]

After authenticating w/Spring Security, there is some legacy code that does a JNDI lookup. That lookup was failing immediately after the user was authenticated. I was thrown off by the filter unavailable error message - looking at the WAS logs uncovered the real problem.

Apologies if this is O/T but here is the fix I made to my lookup to work with both Tomcat 6.0.16 and WAS 6.1.0.21:

try{
				// assume we're running on WebSphere
				java.util.Properties parms = new java.util.Properties();
				parms.setProperty(Context.INITIAL_CONTEXT_FACTORY,
	                        "com.ibm.websphere.naming.WsnInitialContextFactory");
				
				Context ctx = new InitialContext(parms);
				DataSource ds = (DataSource) ctx.lookup("java:comp/env/jdbc/myApp");
				return ds.getConnection();
			}
			// if we're not running on WebSphere, catch the exception
			// and do the lookup Tomcat style
	        catch(NoInitialContextException e){
	        	Context initContext = new InitialContext();
	        	Context envContext = (Context) initContext.lookup("java:/comp/env");
	        	DataSource ds = (DataSource) envContext.lookup("jdbc/myApp");
	        	return ds.getConnection();
	        }

[krancour]

Not to belabor the issue, but you should consider using Spring to do the JNDI lookup. Then deploying to one server or another is just a config change and your code doesn't become coupled to your environment in any way.

Try this:

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:jee="http://www.springframework.org/schema/jee"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
                           http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
                           http://www.springframework.org/schema/jee
                           http://www.springframework.org/schema/jee/spring-jee-2.5.xsd">

<jee:jndi-lookup id="dataSource" jndi-name="/jdbc/database" resource-ref="true"/>

</beans>

[Jwileman]

I had exactly the same problem as people on this forum had: the 404 error-code whenever trying to login/logout of an application using Spring security. The error only occurred on WAS for me, but the same code worked fine on Tomcat, confirming this ISN'T a Spring security problem. The information provided by people in this thread was very useful in getting the problem fixed. Our WAS server was already at fixpack level 21, but the Websphere people in my company implemented the web container setting as suggested in this thread, and the problem magically disappeared.

Thanks

[fiddlerpianist]

I had exactly the same problem as people on this forum had: the 404 error-code whenever trying to login/logout of an application using Spring security. The error only occurred on WAS for me, but the same code worked fine on Tomcat, confirming this ISN'T a Spring security problem. The information provided by people in this thread was very useful in getting the problem fixed. Our WAS server was already at fixpack level 21, but the Websphere people in my company implemented the web container setting as suggested in this thread, and the problem magically disappeared.

Allegedly this is a WebSphere "optimization." Without the web container property set, WebSphere thinks that anything not mapped in a servlet-mapping section of the web.xml is static content, so it "optimizes" this call by not even attempting to send it down the filter chain.

This used to work with WAS 5.x, in fact. Why is it that an optimization which breaks backward compatibility needs to be actively turned off with a web container setting? Why not require the optimization to be turned on with a setting instead? I'm sure that IBM has their reasons, but they are a mystery to me.

Just to re-iterate something I said earlier in this thread... another thing you can do if you don't want to go the web container property route is to enable administrative security and map the login URL to j_security_check (instead of j_spring_security check) and your logout URL to ibm_security_logout. When administrative security is enabled, WAS is smart enough to realize that these URLs are "special" and not static content.

[bbacsu]

I am running WAS 7 and tried setting the web container custom property, as suggested, but still getting this error. Wondering if anyone has found a solution for WebSphere 7.0.0.7