[
https://issues.apache.org/jira/browse/WSS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed WSS-266.
-----------------------------------
> 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.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
