cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colm O hEigeartaigh (Commented) (JIRA)" <>
Subject [jira] [Commented] (CXF-1636) Have WSS4J in/out interceptors require nonces and timestamps when using UsernameTokens?
Date Thu, 08 Mar 2012 13:03:57 GMT


Colm O hEigeartaigh commented on CXF-1636:

> Actually, I may have misunderstood your design here. Is it the case that caching is indeed
> independently in two separate XML file locations, one for the client and one for the
service, with the same 
> setting except that it's false by default for the former and true by default for the
latter (CXF 2.6 
> onwards)?

Yep correct. 

> If that's the case, you won't need a RecipientOnly setting as that would just confuse
things, i.e., give 
> the false impression that the server-side config file somehow controls caching on the
client-side as well. 
> In that case, true/false values alone in both files would work.

Ok, so you're happy with the original design? If not specified, it's false for client and
true for recipient. Setting it to false disables it altogether, setting it to true enables
it for both message initiator and recipient.

> Have WSS4J in/out interceptors require nonces and timestamps when using UsernameTokens?
> ---------------------------------------------------------------------------------------
>                 Key: CXF-1636
>                 URL:
>             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
> 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]
> [2]
> [3]
> [4]

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message