You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by "Ever A. Olano (JIRA)" <ji...@apache.org> on 2006/12/19 01:54:21 UTC
[jira] Created: (WSS-66) Possible security hole when PasswordDigest
is used by client.
Possible security hole when PasswordDigest is used by client.
-------------------------------------------------------------
Key: WSS-66
URL: http://issues.apache.org/jira/browse/WSS-66
Project: WSS4J
Issue Type: Bug
Environment: Any
Reporter: Ever A. Olano
Assigned To: Davanum Srinivas
Hello. I am trying to implement UsernameToken verification on the server side and discovered what could be a security hole in the way the code determines whether to verify the PasswordDigest.
According to the Username Token Profile 1.0 spec, the nonce and timestamp are OPTIONAL. However, in UsernameTokenProcessor.java, you verify the password digest only if both nonce and timestamp are non-null:
if (nonce != null && createdTime != null) {
String passDigest = UsernameToken.doPasswordDigest(nonce, createdTime, origPassword);
if (!passDigest.equals(password)) {
throw new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);
}
}
So, if a client sends in PasswordDigest without a nonce or a timestamp, you will set the usage to USERNAME_TOKEN, so the password callback handler will simply set the password (since it's not expected to validate it itself). Then, coming back to UsernameTokenProcessor, the code sees that one of nonce and createdTime is null so it doesn't do the validation.
In other words, unless I missed something in the code, a client can send in any bogus password, use PasswordDigest, NOT send in a nonce or a timestamp, and it will validate just fine.
I'm sorry I can't test that scenario at this time as I haven't found a way to turn off either the nonce or timestamp from .NET WSE 2.0, the toolkit I'm testing with at this point.
Thanks,
Ever
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-66) Possible security hole when
PasswordDigest is used by client.
Posted by "Fred Dushin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12588073#action_12588073 ]
Fred Dushin commented on WSS-66:
--------------------------------
Patch applied.
> Possible security hole when PasswordDigest is used by client.
> -------------------------------------------------------------
>
> Key: WSS-66
> URL: https://issues.apache.org/jira/browse/WSS-66
> Project: WSS4J
> Issue Type: Bug
> Environment: Any
> Reporter: Ever A. Olano
> Attachments: wss-66.diff, wss4j_wss66_revised.patch
>
>
> Hello. I am trying to implement UsernameToken verification on the server side and discovered what could be a security hole in the way the code determines whether to verify the PasswordDigest.
> According to the Username Token Profile 1.0 spec, the nonce and timestamp are OPTIONAL. However, in UsernameTokenProcessor.java, you verify the password digest only if both nonce and timestamp are non-null:
> if (nonce != null && createdTime != null) {
> String passDigest = UsernameToken.doPasswordDigest(nonce, createdTime, origPassword);
> if (!passDigest.equals(password)) {
> throw new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);
> }
> }
> So, if a client sends in PasswordDigest without a nonce or a timestamp, you will set the usage to USERNAME_TOKEN, so the password callback handler will simply set the password (since it's not expected to validate it itself). Then, coming back to UsernameTokenProcessor, the code sees that one of nonce and createdTime is null so it doesn't do the validation.
> In other words, unless I missed something in the code, a client can send in any bogus password, use PasswordDigest, NOT send in a nonce or a timestamp, and it will validate just fine.
> I'm sorry I can't test that scenario at this time as I haven't found a way to turn off either the nonce or timestamp from .NET WSE 2.0, the toolkit I'm testing with at this point.
> Thanks,
> Ever
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Updated: (WSS-66) Possible security hole when PasswordDigest
is used by client.
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh updated WSS-66:
-----------------------------------
Attachment: wss4j_wss66_revised.patch
Please see the attached for a (revised) patch for this problem. The original patch has two issues:
1) No tests are included
2) The patch assumes that the processor should reject a UsernameToken if it is missing either a Nonce or a Created element, but not if both are missing. As this is a separate issue to the JIRA task in hand, it is more suitable that a separate JIRA be created for this. In the meantime, it's better to stick with the status quo, which incidentally conforms to the "recommended" approach in the 1.1 spec - which is to reject an incoming UsernameToken with digested password unless it has both Nonce and Created elements.
The revised patch fixes the (major) security hole in question + adds tests.
> Possible security hole when PasswordDigest is used by client.
> -------------------------------------------------------------
>
> Key: WSS-66
> URL: https://issues.apache.org/jira/browse/WSS-66
> Project: WSS4J
> Issue Type: Bug
> Environment: Any
> Reporter: Ever A. Olano
> Attachments: wss-66.diff, wss4j_wss66_revised.patch
>
>
> Hello. I am trying to implement UsernameToken verification on the server side and discovered what could be a security hole in the way the code determines whether to verify the PasswordDigest.
> According to the Username Token Profile 1.0 spec, the nonce and timestamp are OPTIONAL. However, in UsernameTokenProcessor.java, you verify the password digest only if both nonce and timestamp are non-null:
> if (nonce != null && createdTime != null) {
> String passDigest = UsernameToken.doPasswordDigest(nonce, createdTime, origPassword);
> if (!passDigest.equals(password)) {
> throw new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);
> }
> }
> So, if a client sends in PasswordDigest without a nonce or a timestamp, you will set the usage to USERNAME_TOKEN, so the password callback handler will simply set the password (since it's not expected to validate it itself). Then, coming back to UsernameTokenProcessor, the code sees that one of nonce and createdTime is null so it doesn't do the validation.
> In other words, unless I missed something in the code, a client can send in any bogus password, use PasswordDigest, NOT send in a nonce or a timestamp, and it will validate just fine.
> I'm sorry I can't test that scenario at this time as I haven't found a way to turn off either the nonce or timestamp from .NET WSE 2.0, the toolkit I'm testing with at this point.
> Thanks,
> Ever
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Updated: (WSS-66) Possible security hole when PasswordDigest
is used by client.
Posted by "Steve LeGault (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Steve LeGault updated WSS-66:
-----------------------------
Attachment: (was: wss-66.diff)
> Possible security hole when PasswordDigest is used by client.
> -------------------------------------------------------------
>
> Key: WSS-66
> URL: https://issues.apache.org/jira/browse/WSS-66
> Project: WSS4J
> Issue Type: Bug
> Environment: Any
> Reporter: Ever A. Olano
>
> Hello. I am trying to implement UsernameToken verification on the server side and discovered what could be a security hole in the way the code determines whether to verify the PasswordDigest.
> According to the Username Token Profile 1.0 spec, the nonce and timestamp are OPTIONAL. However, in UsernameTokenProcessor.java, you verify the password digest only if both nonce and timestamp are non-null:
> if (nonce != null && createdTime != null) {
> String passDigest = UsernameToken.doPasswordDigest(nonce, createdTime, origPassword);
> if (!passDigest.equals(password)) {
> throw new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);
> }
> }
> So, if a client sends in PasswordDigest without a nonce or a timestamp, you will set the usage to USERNAME_TOKEN, so the password callback handler will simply set the password (since it's not expected to validate it itself). Then, coming back to UsernameTokenProcessor, the code sees that one of nonce and createdTime is null so it doesn't do the validation.
> In other words, unless I missed something in the code, a client can send in any bogus password, use PasswordDigest, NOT send in a nonce or a timestamp, and it will validate just fine.
> I'm sorry I can't test that scenario at this time as I haven't found a way to turn off either the nonce or timestamp from .NET WSE 2.0, the toolkit I'm testing with at this point.
> Thanks,
> Ever
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Updated: (WSS-66) Possible security hole when PasswordDigest
is used by client.
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Davanum Srinivas updated WSS-66:
--------------------------------
Assignee: (was: Davanum Srinivas)
> Possible security hole when PasswordDigest is used by client.
> -------------------------------------------------------------
>
> Key: WSS-66
> URL: https://issues.apache.org/jira/browse/WSS-66
> Project: WSS4J
> Issue Type: Bug
> Environment: Any
> Reporter: Ever A. Olano
>
> Hello. I am trying to implement UsernameToken verification on the server side and discovered what could be a security hole in the way the code determines whether to verify the PasswordDigest.
> According to the Username Token Profile 1.0 spec, the nonce and timestamp are OPTIONAL. However, in UsernameTokenProcessor.java, you verify the password digest only if both nonce and timestamp are non-null:
> if (nonce != null && createdTime != null) {
> String passDigest = UsernameToken.doPasswordDigest(nonce, createdTime, origPassword);
> if (!passDigest.equals(password)) {
> throw new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);
> }
> }
> So, if a client sends in PasswordDigest without a nonce or a timestamp, you will set the usage to USERNAME_TOKEN, so the password callback handler will simply set the password (since it's not expected to validate it itself). Then, coming back to UsernameTokenProcessor, the code sees that one of nonce and createdTime is null so it doesn't do the validation.
> In other words, unless I missed something in the code, a client can send in any bogus password, use PasswordDigest, NOT send in a nonce or a timestamp, and it will validate just fine.
> I'm sorry I can't test that scenario at this time as I haven't found a way to turn off either the nonce or timestamp from .NET WSE 2.0, the toolkit I'm testing with at this point.
> Thanks,
> Ever
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Assigned: (WSS-66) Possible security hole when
PasswordDigest is used by client.
Posted by "Fred Dushin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fred Dushin reassigned WSS-66:
------------------------------
Assignee: Fred Dushin
> Possible security hole when PasswordDigest is used by client.
> -------------------------------------------------------------
>
> Key: WSS-66
> URL: https://issues.apache.org/jira/browse/WSS-66
> Project: WSS4J
> Issue Type: Bug
> Environment: Any
> Reporter: Ever A. Olano
> Assignee: Fred Dushin
> Attachments: wss-66.diff, wss4j_wss66_revised.patch
>
>
> Hello. I am trying to implement UsernameToken verification on the server side and discovered what could be a security hole in the way the code determines whether to verify the PasswordDigest.
> According to the Username Token Profile 1.0 spec, the nonce and timestamp are OPTIONAL. However, in UsernameTokenProcessor.java, you verify the password digest only if both nonce and timestamp are non-null:
> if (nonce != null && createdTime != null) {
> String passDigest = UsernameToken.doPasswordDigest(nonce, createdTime, origPassword);
> if (!passDigest.equals(password)) {
> throw new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);
> }
> }
> So, if a client sends in PasswordDigest without a nonce or a timestamp, you will set the usage to USERNAME_TOKEN, so the password callback handler will simply set the password (since it's not expected to validate it itself). Then, coming back to UsernameTokenProcessor, the code sees that one of nonce and createdTime is null so it doesn't do the validation.
> In other words, unless I missed something in the code, a client can send in any bogus password, use PasswordDigest, NOT send in a nonce or a timestamp, and it will validate just fine.
> I'm sorry I can't test that scenario at this time as I haven't found a way to turn off either the nonce or timestamp from .NET WSE 2.0, the toolkit I'm testing with at this point.
> Thanks,
> Ever
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-66) Possible security hole when
PasswordDigest is used by client.
Posted by "Dmitry (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505234 ]
Dmitry commented on WSS-66:
---------------------------
This issue seems to make the whole UsernameToken thing useless in case of PasswordDigest.
I used the following XML to test it
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:UsernameToken>
<wsse:Username>Bert</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">B5twk47KwSrjeg==</wsse:Password>
<wsse:Nonce/>
<wsu:Created>2003-07-16T01:24:32Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
Given that SOAP header, wss4j doesn't verify the password and sets up a valid principal. Thanks to line # 117 of org.apache.ws.security.processor.UsernameTokenProcessor:
if (nonce != null && createdTime != null) {
> Possible security hole when PasswordDigest is used by client.
> -------------------------------------------------------------
>
> Key: WSS-66
> URL: https://issues.apache.org/jira/browse/WSS-66
> Project: WSS4J
> Issue Type: Bug
> Environment: Any
> Reporter: Ever A. Olano
> Assignee: Davanum Srinivas
>
> Hello. I am trying to implement UsernameToken verification on the server side and discovered what could be a security hole in the way the code determines whether to verify the PasswordDigest.
> According to the Username Token Profile 1.0 spec, the nonce and timestamp are OPTIONAL. However, in UsernameTokenProcessor.java, you verify the password digest only if both nonce and timestamp are non-null:
> if (nonce != null && createdTime != null) {
> String passDigest = UsernameToken.doPasswordDigest(nonce, createdTime, origPassword);
> if (!passDigest.equals(password)) {
> throw new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);
> }
> }
> So, if a client sends in PasswordDigest without a nonce or a timestamp, you will set the usage to USERNAME_TOKEN, so the password callback handler will simply set the password (since it's not expected to validate it itself). Then, coming back to UsernameTokenProcessor, the code sees that one of nonce and createdTime is null so it doesn't do the validation.
> In other words, unless I missed something in the code, a client can send in any bogus password, use PasswordDigest, NOT send in a nonce or a timestamp, and it will validate just fine.
> I'm sorry I can't test that scenario at this time as I haven't found a way to turn off either the nonce or timestamp from .NET WSE 2.0, the toolkit I'm testing with at this point.
> Thanks,
> Ever
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Updated: (WSS-66) Possible security hole when PasswordDigest
is used by client.
Posted by "Steve LeGault (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Steve LeGault updated WSS-66:
-----------------------------
Attachment: wss-66.diff
I believe I have a fix for this issue which also fixes the ability to generate a UsernameToken without Nonce/Created elements. Attached is the diff.
On the receive side, UsernameTokenProcessor will throw an exception if only one of Nonce or created is present in the header. If neither nonce or created are present, then the digest is performed on just the password. If both are present, then the digest is performed on password + nonce + created (as before).
On the generation side, users of UsernameToken class add the nonce and created based on configuration (specifically the MessageContext parameters WSHandlerConstants.ADD_UT_ELEMENTS) - this diff differentiates the case of "straight PasswordDigest" and "PasswordDigest with Nonce/created elements" (previously PasswordDigest always generated Nonce/Created regardless of config)
I tested this with SoapUI and it behaves as intended.
I'm a newbie with no commit privleges - so either I can go through the excercise to get commit privleges or someone with commit priveleges can commit the patch.
> Possible security hole when PasswordDigest is used by client.
> -------------------------------------------------------------
>
> Key: WSS-66
> URL: https://issues.apache.org/jira/browse/WSS-66
> Project: WSS4J
> Issue Type: Bug
> Environment: Any
> Reporter: Ever A. Olano
> Attachments: wss-66.diff
>
>
> Hello. I am trying to implement UsernameToken verification on the server side and discovered what could be a security hole in the way the code determines whether to verify the PasswordDigest.
> According to the Username Token Profile 1.0 spec, the nonce and timestamp are OPTIONAL. However, in UsernameTokenProcessor.java, you verify the password digest only if both nonce and timestamp are non-null:
> if (nonce != null && createdTime != null) {
> String passDigest = UsernameToken.doPasswordDigest(nonce, createdTime, origPassword);
> if (!passDigest.equals(password)) {
> throw new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);
> }
> }
> So, if a client sends in PasswordDigest without a nonce or a timestamp, you will set the usage to USERNAME_TOKEN, so the password callback handler will simply set the password (since it's not expected to validate it itself). Then, coming back to UsernameTokenProcessor, the code sees that one of nonce and createdTime is null so it doesn't do the validation.
> In other words, unless I missed something in the code, a client can send in any bogus password, use PasswordDigest, NOT send in a nonce or a timestamp, and it will validate just fine.
> I'm sorry I can't test that scenario at this time as I haven't found a way to turn off either the nonce or timestamp from .NET WSE 2.0, the toolkit I'm testing with at this point.
> Thanks,
> Ever
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Resolved: (WSS-66) Possible security hole when
PasswordDigest is used by client.
Posted by "Fred Dushin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fred Dushin resolved WSS-66.
----------------------------
Resolution: Fixed
> Possible security hole when PasswordDigest is used by client.
> -------------------------------------------------------------
>
> Key: WSS-66
> URL: https://issues.apache.org/jira/browse/WSS-66
> Project: WSS4J
> Issue Type: Bug
> Environment: Any
> Reporter: Ever A. Olano
> Assignee: Fred Dushin
> Attachments: wss-66.diff, wss4j_wss66_revised.patch
>
>
> Hello. I am trying to implement UsernameToken verification on the server side and discovered what could be a security hole in the way the code determines whether to verify the PasswordDigest.
> According to the Username Token Profile 1.0 spec, the nonce and timestamp are OPTIONAL. However, in UsernameTokenProcessor.java, you verify the password digest only if both nonce and timestamp are non-null:
> if (nonce != null && createdTime != null) {
> String passDigest = UsernameToken.doPasswordDigest(nonce, createdTime, origPassword);
> if (!passDigest.equals(password)) {
> throw new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);
> }
> }
> So, if a client sends in PasswordDigest without a nonce or a timestamp, you will set the usage to USERNAME_TOKEN, so the password callback handler will simply set the password (since it's not expected to validate it itself). Then, coming back to UsernameTokenProcessor, the code sees that one of nonce and createdTime is null so it doesn't do the validation.
> In other words, unless I missed something in the code, a client can send in any bogus password, use PasswordDigest, NOT send in a nonce or a timestamp, and it will validate just fine.
> I'm sorry I can't test that scenario at this time as I haven't found a way to turn off either the nonce or timestamp from .NET WSE 2.0, the toolkit I'm testing with at this point.
> Thanks,
> Ever
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Updated: (WSS-66) Possible security hole when PasswordDigest
is used by client.
Posted by "Steve LeGault (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Steve LeGault updated WSS-66:
-----------------------------
Attachment: wss-66.diff
Updated diff - missed ordering of setting nonce/created before setPassword called.
> Possible security hole when PasswordDigest is used by client.
> -------------------------------------------------------------
>
> Key: WSS-66
> URL: https://issues.apache.org/jira/browse/WSS-66
> Project: WSS4J
> Issue Type: Bug
> Environment: Any
> Reporter: Ever A. Olano
> Attachments: wss-66.diff
>
>
> Hello. I am trying to implement UsernameToken verification on the server side and discovered what could be a security hole in the way the code determines whether to verify the PasswordDigest.
> According to the Username Token Profile 1.0 spec, the nonce and timestamp are OPTIONAL. However, in UsernameTokenProcessor.java, you verify the password digest only if both nonce and timestamp are non-null:
> if (nonce != null && createdTime != null) {
> String passDigest = UsernameToken.doPasswordDigest(nonce, createdTime, origPassword);
> if (!passDigest.equals(password)) {
> throw new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);
> }
> }
> So, if a client sends in PasswordDigest without a nonce or a timestamp, you will set the usage to USERNAME_TOKEN, so the password callback handler will simply set the password (since it's not expected to validate it itself). Then, coming back to UsernameTokenProcessor, the code sees that one of nonce and createdTime is null so it doesn't do the validation.
> In other words, unless I missed something in the code, a client can send in any bogus password, use PasswordDigest, NOT send in a nonce or a timestamp, and it will validate just fine.
> I'm sorry I can't test that scenario at this time as I haven't found a way to turn off either the nonce or timestamp from .NET WSE 2.0, the toolkit I'm testing with at this point.
> Thanks,
> Ever
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org