[
https://issues.apache.org/jira/browse/CXF-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225182#comment-13225182
]
Glen Mazza commented on CXF-1636:
---------------------------------
>> 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"?
That would be fine, as long as there are three explicit settings, whatever they
are called.
But this raises another question: Why is there just one setting in one config
file that controls *both* the client and the service caching? I would think
the client would have its own configuration file (say cxf.xml) where it
dictates whether or not it wants its nonces/timestamps cached client-side (a
boolean setting defaulting to "false"), and the service configuration file (say
cxf-servlet.xml) would have the same configuration option (same boolean except
default to true, at least for CXF 2.6->). It seems strange to have the
service-side config file determine whether or not the client will be caching
its nonces/timestamps on its own end (that's what the client config file is
for), and in the normally separated architecture between the client and web
service provider, I can't see how that would work.
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)? 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.
> 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
