[
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
