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 org.springframework.security.ui.preauth.websphere 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.
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.