I'm currently struggling a little with the security layer of a web service I'm writing using WSS4J and CXF.
We obviously do not wish to store plaintext passwords in our backend, but would prefer to persist only salted hashes.
The service specifications, however, are preset by our client (who will be using the service to push a bunch of data our way), down to the use of UsernameTokens with plaintext password (All communication is SSL encrypted)
Now the problem I'm facing is that I cannot seem to find a way to hash the plaintext password from the request security header on our end, match it against our records along with the username and authorise or decline the request.
Every single guide, tutorial or example project I've found so far relies on a CallbackHandler configured as input interceptor, which requires retrieving the correct plaintext password, which is then matched against the supplied credentials directly. Not an option if we only store the hash. A couple of sources I came across that were trying to solve similar problems merely recommended to force the client to do the hashing. But as I stated above, this is not possible in our case. The service specifications are clear on the matter and it's out of our hands.
This particularly interesting sounding thread sadly didn't help me either: How to implement WSS UsernameToken when password on the server is salted and hashed?
Surely there must be another way than a WSS4JInInterceptor/CallbackHandler, one that will allow me to digest the received plaintext password and check it against the salted hash in our database.
Any pointers would really be greatly appreciated. Thanks.