[
https://issues.apache.org/jira/browse/CXF-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225189#comment-13225189
]
Colm O hEigeartaigh commented on CXF-1636:
------------------------------------------
> Actually, I may have misunderstood your design here. Is it the case that
> caching is indeed configured
> independently in two separate XML file locations, one for the client and one
> for the service, with the same
> setting except that it's false by default for the former and true by default
> for the latter (CXF 2.6
> onwards)?
Yep correct.
> If that's the case, you won't need a RecipientOnly setting as that would just
> confuse things, i.e., give
> the false impression that the server-side config file somehow controls
> caching on the client-side as well.
> In that case, true/false values alone in both files would work.
Ok, so you're happy with the original design? If not specified, it's false for
client and true for recipient. Setting it to false disables it altogether,
setting it to true enables it for both message initiator and recipient.
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
