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 (Issue Comment Edited) (JIRA)" <ji...@apache.org> on 2012/03/08 14:03:57 UTC
[jira] [Issue Comment Edited] (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=13225158#comment-13225158 ]
Colm O hEigeartaigh edited comment on CXF-1636 at 3/8/12 1:03 PM:
------------------------------------------------------------------
Thanks for the comments!
> 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.
Agreed.
> Is the file in src/main/resources/ehcache.xml normal?
According to http://www.ehcache.org/documentation/user-guide/configuration:
"Ehcache looks for a file called ehcache.xml in the top level of the classpath. Failing that it looks for ehcache-failsafe.xml in the classpath. ehcache-failsafe.xml is packaged in the Ehcache jar and should always be found."
What I *could* do is to rename that file to ehcache-failsafe.xml. The problem with this though is that a warning will be logged for anything downstream from the security module that doesn't explicitly specify an ehcache.xml file. Is this acceptable? I could update all systests + demos to include the file.
> There is still a way to explicitly set that value that causes it to act as the default, right?
Good point Glen. I could change the boolean properties so that in addition to true/false you can specify "RecipientOnly"?
> Also, is there a use case for caching on the client side?
Probably not a common use-case for caching UsernameToken nonces - that's why I want to disable it by default. It can be enabled by setting the property to true. I don't see a use-case for providing an "InitiatorOnly" configuration option.
> if you wish I think it would be acceptable to activate it by default with a note in the release notes of
> this change for 2.4/2.5.
I'm a bit nervous about this suggestion, as it's introducing a new dependency and changed behaviour on a minor upgrade.
Colm.
was (Author: coheigea):
Thanks for the comments!
> 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.
Agreed.
> Is the file in src/main/resources/ehcache.xml normal?
According to http://www.ehcache.org/documentation/user-guide/configuration:
"Ehcache looks for a file called ehcache.xml in the top level of the classpath. Failing that it looks for ehcache-failsafe.xml in the classpath. ehcache-failsafe.xml is packaged in the Ehcache jar and should always be found."
What I *could* do is to rename that file to ehcache-failsafe.xml. The problem with this though is that a warning will be printed out for anything downstream from the security module that doesn't explicitly specify an ehcache.xml file. Is this acceptable? I could update all systests + demos to include the file.
> There is still a way to explicitly set that value that causes it to act as the default, right?
Good point Glen. I could change the boolean properties so that in addition to true/false you can specify "RecipientOnly"?
> Also, is there a use case for caching on the client side?
Probably not a common use-case for caching UsernameToken nonces - that's why I want to disable it by default. It can be enabled by setting the property to true. I don't see a use-case for providing an "InitiatorOnly" configuration option.
> if you wish I think it would be acceptable to activate it by default with a note in the release notes of
> this change for 2.4/2.5.
I'm a bit nervous about this suggestion, as it's introducing a new dependency and changed behaviour on a minor upgrade.
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