You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Glen Mazza (JIRA)" <ji...@apache.org> on 2008/06/09 06:05:45 UTC
[jira] Created: (CXF-1636) Have WSS4J in/out interceptors require
nonces and timestamps when using UsernameTokens?
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
Reporter: Glen Mazza
Priority: Minor
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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1636) Have WSS4J in/out interceptors require
nonces and timestamps when using UsernameTokens?
Posted by "Glen Mazza (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603559#action_12603559 ]
Glen Mazza commented on CXF-1636:
---------------------------------
>> but perhaps WSS4J is doing the checking/validation that they are not being used more then once.
>Unfortunately, nonce caching isn't implemented (yet) in WSS4J. Feel free to raise an enhancement request in the WSS4J JIRA tho :-)
Hmm. Is nonce caching the responsibility of WSS4J or that of the web services stack (Axis, CXF, etc.) using it?
> 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
> Reporter: Glen Mazza
> Priority: Minor
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1636) Have WSS4J in/out interceptors require
nonces and timestamps when using UsernameTokens?
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603533#action_12603533 ]
Colm O hEigeartaigh commented on CXF-1636:
------------------------------------------
> 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.
-1 to this. Both the nonce and created elements are optional as per the specification (albeit "recommended"), I don't think we should be forcing this behaviour on the average user.
> but perhaps WSS4J is doing the checking/validation that they are not being used more then once.
Unfortunately, nonce caching isn't implemented (yet) in WSS4J. Feel free to raise an enhancement request in the WSS4J JIRA tho :-)
> 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
> Reporter: Glen Mazza
> Priority: Minor
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1636) Have WSS4J in/out interceptors require
nonces and timestamps when using UsernameTokens?
Posted by "Glen Mazza (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603573#action_12603573 ]
Glen Mazza commented on CXF-1636:
---------------------------------
> -1 to this. Both the nonce and created elements are optional as per the specification (albeit "recommended"),
> I don't think we should be forcing this behaviour on the average user.
Colm, are you a CXF committer? I did not find you on the list.
> 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
> Reporter: Glen Mazza
> Priority: Minor
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1636) Have WSS4J in/out interceptors require
nonces and timestamps when using UsernameTokens?
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603576#action_12603576 ]
Colm O hEigeartaigh commented on CXF-1636:
------------------------------------------
> Hmm. Is nonce caching the responsibility of WSS4J or that of the web services stack (Axis, CXF, etc.) using it?
Good point. I guess the implementation should be done in CXF, with some "common" code put into the WSHandler class in WSS4J.
> Colm, are you a CXF committer?
No.
> 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
> Reporter: Glen Mazza
> Priority: Minor
>
> 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.
-
You can reply to this email to add a comment to the issue online.