[
https://issues.apache.org/jira/browse/WSS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990589#comment-12990589
]
Colm O hEigeartaigh commented on WSS-266:
-----------------------------------------
The implementation I ended up with is slightly different from the comment I
made above :-) The UsernameTokenProcessor passes the CallbackHandler and the
UsernameToken instance to the validator (in this case UsernameTokenValidator)
for validation. For the scenario you outlined, it's simply a case of extending
the UsernameTokenValidator and overriding the appropriate method. See this blog
post for more details on the changes:
http://coheigea.blogspot.com/2011/02/usernametoken-processing-changes-in.html
Colm.
> 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]
