WebSphere Liberty support missing in spring-security-web

[mtransier]

Spring-security-web provides a filter called WebSpherePreAuthenticatedProcessingFilter that should allow to use the authentication information provided by WebSphere. However, this code was designed to run on traditional WebSphere and does not work on WebSphere Liberty. The reason is that traditional WebSphere provides access to the UserRepository through JNDI while WebSphere Liberty has an API for that (Security public APIs). The same issue has already been spotted by other Liberty users before: javax.naming.NameNotFoundException: UserRegistry

Since we need to support WebSphere Liberty in our project, we would need to fix that part of spring-security-web. OASP-2.2 uses version 4.0,4, and I already double-checked that the current release 4.2.1 does not provide a fix. The respective file is DefaultWASUsernameAndGroupsExtractor.java.

Assuming we will be able to fix this, what should be the best approach to do so: push it back to spring-security, create an own version of spring-security, or anything else?
Besides that: is there a reason why OASP is not yet using the current release of spring-security?

[mtransier]

For now, I created an own version of spring-security that solves this issue with WebSphere Liberty.

[hohwille]

If you could fix that it would be awesome if you could provide the fix as PR to spring-security-web or as diff so someone else can do that for you.

[hohwille]

Any update on this one? Can we get your fix and integrate that?

[mtransier]

Sorry for the huge delay in responding to your request. The attached patch file contains my fix. The fix is not clean since it introduces a dependency to the Liberty API. So one of the following two things have to be done:

• Remove the dependency by dynamically loading the method at runtime and calling it (similar to the removed part in the patch does it for another class).

• Fix the dependency. When I created the fix, the build was based on Maven, now they seem to have switched to Gradle and I was not yet able to test the build using the required Liberty dependency.

Patch (diff file): patch.txt

[hohwille]

I am still unsure about our JEE app server strategy. To be honest all app servers are dead and betting on them is a dead end causing technical dept. Versions of Java (8,9,10,11,...) as well as libraries and frameworks are evolving faster and faster. A (classic) JEE app server is a jail that wont let you catch up and will end in a security disaster over time. There might be a future with MicroProfiles but if you ask me the future belongs to spring-boot, docker and stuff like that. Finally its the time to convince your customers to go away from all the 1990 solutions.
Of course projects and customers can do what ever they want. Also we do have a big and open community. If people from that community provide solutions for (better) integrating with app servers like WebSphere or whatever, this is great and they can create alternative-* pages in the documentation wiki to share their experience, etc.

However, to communicate an honest expectation: do not expect support from the key players of OASP/devonfw on this topic.

[mtransier]

I provided the patch following your request ... not expecting anything.