ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Veithen (JIRA)" <>
Subject [jira] Commented: (WSS-266) Provide better support for pluggable authentication/verification of security tokens
Date Mon, 24 Jan 2011 21:00:44 GMT


Andreas Veithen commented on WSS-266:

What about a use case where you want to delegate authentication to LDAP? In that case you
can't retrieve the password for a given user, so there is no way to let the CallbackHandler
supply the password to WSS4J. The only thing it can do is to validate a (plaintext) password
supplied by WSS4J.

> Provide better support for pluggable authentication/verification of security tokens
> -----------------------------------------------------------------------------------
>                 Key: WSS-266
>                 URL:
>             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:
For additional commands, e-mail:

View raw message