[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlrpc-dev
Subject:    [jira] Created: (WSS-266) Provide better support for pluggable
From:       "Colm O hEigeartaigh (JIRA)" <jira () apache ! org>
Date:       2011-01-24 12:45:44
Message-ID: 32416825.152551295873144683.JavaMail.jira () thor
[Download RAW message or body]

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: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]