cxf-issues mailing list archives

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

    [ 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

        

Mime
View raw message