Provide better support for pluggable authentication/verification of security
tokens
-----------------------------------------------------------------------------------
Key: WSS-266
URL: https://issues.apache.org/jira/browse/WSS-266
Project: WSS4J
Issue Type: Improvement
Affects Versions: 1.5.10
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Fix For: 1.6
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
