[
https://issues.apache.org/jira/browse/CXF-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224512#comment-13224512
]
Glen Mazza commented on CXF-1636:
---------------------------------
Colm, one concern I have (but may be misunderstanding) is the caching setting:
"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." There is still a way to explicitly set that value
that causes it to act as the default, right? I.e., we're not having a
situation where if you omit a value, condition "A" exists, set it to "true',
condition "B", and false, condition "C"--there is a way to programatically set
condition "A" other than by omitting the value, correct?
Also, is there a use case for caching on the client side?
> 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
