cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (Commented) (JIRA)" <>
Subject [jira] [Commented] (CXF-1636) Have WSS4J in/out interceptors require nonces and timestamps when using UsernameTokens?
Date Wed, 07 Mar 2012 17:04:57 GMT


Daniel Kulp commented on CXF-1636:

Two comments:

1) On 2.5.x/2.4.x, I'd also switch to <scope>provided</scope><optional>true</optional>
so users won't have that dependency unexpectedly added.

2) Is the file in src/main/resources/ehcache.xml  normal?    That would go into the root of
the ws-security jar which seems "strange" and problematic.   Is this another
type thing that the first jar on the classpath "wins"?   Is there a better place to put that?
 (I'm not familiar enough with ehcache)

Other than that, looks good to me.

> 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