Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Wed, 7 Mar 2012 17:20:57 +0000 (UTC)
From: "Glen Mazza (Commented) (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: 
 <1187140541.34847.1331140857783.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CXF-1636) Have WSS4J in/out interceptors
 require nonces and timestamps when using UsernameTokens?
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CXF-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224512#comment-13224512 ] 

Glen Mazza commented on CXF-1636:
---------------------------------

Colm, one concern I have (but may be misunderstanding) is the caching setting: "By default, it's true for a recipient, and false for an initiator. If set to false, no caching is done, if set to true, caching is enabled for both recipients and initiators."  There is still a way to explicitly set that value that causes it to act as the default, right?  I.e., we're not having a situation where if you omit a value, condition "A" exists, set it to "true', condition "B", and false, condition "C"--there is a way to programatically set condition "A" other than by omitting the value, correct?

Also, is there a use case for caching on the client side?


> Have WSS4J in/out interceptors require nonces and timestamps when using UsernameTokens?
> ---------------------------------------------------------------------------------------
>
>                 Key: CXF-1636
>                 URL: https://issues.apache.org/jira/browse/CXF-1636
>             Project: CXF
>          Issue Type: Improvement
>          Components: WS-* Components
>            Reporter: Glen Mazza
>            Assignee: Colm O hEigeartaigh
>            Priority: Minor
>         Attachments: cxf-1636.patch
>
>
> Our WSS4J In/Out interceptors[1][2] do not appear to be requiring UsernameTokens to have timestamps and nonces.  From [3], lines 176-190, these are used to prevent replay attacks (i.e., an intruder just copying the entire soap header, encrypted or not, and reusing it for another request).  
> To fix this problem, this blog sample[4] created a separate interceptor that will reject any UsernameToken that does not have both a timestamp and a nonce.  Perhaps we should update our WSS4J in/out interceptors to require both of these, so external users don't need to do this.
> A question though--I'm unsure where the nonce-checking is being done--our WSS4J interceptors seem to be ignoring them, but perhaps WSS4J is doing the checking/validation that they are not being used more then once.
> Glen
> [1] http://tinyurl.com/4cgg9b
> [2] http://tinyurl.com/48h6an
> [3] http://tinyurl.com/65n78j
> [4] http://depressedprogrammer.wordpress.com/2007/07/31/cxf-ws-security-using-jsr-181-interceptor-annotations-xfire-migration/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira