SEC-1078: WebSphere2SpringSecurityPropagationInterceptor creates an auth token with null credentials - rejected by pre-auth provider #1329

spring-issuemaster opened this Issue Jan 8, 2009 · 3 comments


None yet

1 participant


Gaetan Pitteloud (Migrated from SEC-1078) said:

WebSphere2SpringSecurityPropagationInterceptor creates a PreAuthenticatedAuthenticationToken request with the was username, and null credentials (line 55 in WebSphere2SpringSecurityPropagationInterceptor).

Such an auth request will be rejected by corresponding provider, (PreAuthenticatedAuthenticationProvider, lines 73-80).

I suggest to change the interceptor and follow what’s in the WebSpherePreAuthenticatedProcessingFilter: the filter return “N/A” as the credentials, which is ok, since the pre-auth provider does not check credential values.

Also, in order to unit test WAS stuff into the package, the WASSecurityHelper should be refactored into a non-static class – at least this would have prevented this bug. You will find attached a proposal for such a refactoring.


Gaetan Pitteloud said:

oops, I found a typo in java file. Please look for the 2nd version.


Gaetan Pitteloud said:

typo fix: method GroupsForCurrentUser() renamed to getGroupsForCurrentUser()


Luke Taylor said:

Thanks a lot for the patch. Rather than retaining WASSecurityHelper as a static class, I've reimplemented it completely as an internally used interface, with a default implementation which does the WAS integration (similar to the approach you had within the static class). I've also added a test for the scenario you describe.

I haven't tested this (and the related refactoring) in websphere so let me know if there are any issues.

@spring-issuemaster spring-issuemaster added this to the 3.0.0 M1 milestone Feb 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment