You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Colm O hEigeartaigh (Commented) (JIRA)" <ji...@apache.org> on 2012/03/07 17:48:59 UTC
[jira] [Commented] (CXF-1636) Have WSS4J in/out interceptors
require nonces and timestamps when using UsernameTokens?
[ https://issues.apache.org/jira/browse/CXF-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224496#comment-13224496 ]
Colm O hEigeartaigh commented on CXF-1636:
------------------------------------------
See attached for a proposed patch for this issue.
Basically, WSS4J 1.6.5 defines a ReplayCache interface, and ships with a HashSet based implementation. This interface is used to cache UsernameToken nonces, and also a combination of Timestamp Created Strings with message Signatures. No caching is done by default in WSS4J.
I've decided to use a ReplayCache implementation based on EhCache in CXF. It is simple to use and Apache licensed. It uses a default configuration which holds 50000 Elements in memory for 60 minutes, and will overflow to disk. This can be changed by specifying another configuration file. Even though the eh-cache is specified as a compile time dependency in the security module, it can be excluded and CXF falls back to using the HashSet implementation in WSS4J.
There are four configuration values available:
a) A boolean switch to cache nonces. 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.
b) Ditto for caching Timestamp Created Strings.
c) A tag that is used to store/retrieve a ReplayCache instance for nonces.
d) Ditto for Timestamps.
What I am thinking of doing is to disable replay caching altogether for 2.5.x and 2.4.x, for backwards compatibility, but to merge this patch so that someone can enable it if they want. On trunk I will preserve the behaviour defined above. The user could always disable caching, if they didn't want to use ehcache, or plug in their own ReplayCache implementation based on something else.
Thoughts?
Colm.
> 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