[WSS-266] Provide better support for pluggable authentication/verification of security tokens

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.5.10
• Fix Version/s: 1.6
• Assignee: Colm O hEigeartaigh
• Reporter: Colm O hEigeartaigh
• Created: 24/Jan/11 12:45
• Updated: 08/Feb/11 16:05
• Resolved: 08/Feb/11 16:05

Description

The way WSS4J currently processes an inbound security header is to iterate through the security header, and to store the processing results for later verification. It defers two pieces of validation to third-party WSHandler implementations:

• Timestamp verification
• Certificate trust validation

There are a couple of problems with approach. Firstly, it is not consistent, as WSS4J performs validation on certain tokens (e.g. Username Tokens) when processing the security header, and does not validate other tokens, such as Timestamps. CXF has to resort to a hack to stop WSS4J processing a Username Token, for certain cases. Secondly, it assumes that calling code will know that Timestamps/certs must be validated, which is a potential security hole. Thirdly, WSS4J will continue to process the rest of the security header even if the Timestamp is invalid, or the certificate non-trusted, which could lead to denial-of-service attacks.

WSS4J 1.6-SNAPSHOT has moved timestamp verification, and certificate trust validation, back into the processing of the security header, so this solves the problem above. What remains to be done though, is to make it easier to plug in a way to perform custom validation of security tokens as WSS4J is processing them. This is probably not such an important issue for Timestamp validation, as for the other two.

As part of this task, I'm thinking of changing the way the CallbackHandler implementation works in WSS4J. Currently, it supplies passwords for some cases, and is expected to verify passwords for other cases. It would be better to let the CallbackHandler implementations solely supply the password for the processors. A new "Validator" interface would then validate the token using the parsing done by the processor, and the password supplied by the callback. This would allow the end-user to plug in different validators. WSS4J would supply some default validators, so the default behaviour remains the same.