You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by "Paul Richardson (Created) (JIRA)" <ji...@apache.org> on 2011/10/20 12:52:10 UTC
[jira] [Created] (WSS-321) Cannot configure for no password element
expected using Spring configuration
Cannot configure for no password element expected using Spring configuration
----------------------------------------------------------------------------
Key: WSS-321
URL: https://issues.apache.org/jira/browse/WSS-321
Project: WSS4J
Issue Type: Bug
Components: WSS4J Core, WSS4J Handlers
Affects Versions: 1.6.3
Environment: Ubuntu 10.04. ServiceMix 4.
Reporter: Paul Richardson
Assignee: Colm O hEigeartaigh
We don't wish to have a Password element in the inbound SOAP request.
WSSecurityUtil.decodeAction() parses the actions that are put in the Spring xml file. We have "UsernameToken", so decodeAction sets the internal representation of the expected WS Security elements to a list with the single value: WSConstants.UT(0x01).
When a SOAP message arrives, UsernameTokenProcessor.handleToken() is called which sets the expected action to WSConstants.UT_NOPASSWORD (0x2000) because there is no password element.Thus when WSHandler.checkReceiverResultsAnyOrder() which checks that the list of expected actions and received actions are the same, it fails and the debug output is 'Security processing failed (actions mismatch)".
Yes, we could override the Processor to get around this, but we were hoping to take advantage of the recent changes which meant that we just needed to implement our own Validator.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
[jira] [Resolved] (WSS-321) Cannot configure for no password
element expected using Spring configuration
Posted by "Colm O hEigeartaigh (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh resolved WSS-321.
-------------------------------------
Resolution: Fixed
> Cannot configure for no password element expected using Spring configuration
> ----------------------------------------------------------------------------
>
> Key: WSS-321
> URL: https://issues.apache.org/jira/browse/WSS-321
> Project: WSS4J
> Issue Type: Bug
> Components: WSS4J Core, WSS4J Handlers
> Affects Versions: 1.6.3
> Environment: Ubuntu 10.04. ServiceMix 4.
> Reporter: Paul Richardson
> Assignee: Colm O hEigeartaigh
> Fix For: 1.6.4
>
>
> We don't wish to have a Password element in the inbound SOAP request.
> WSSecurityUtil.decodeAction() parses the actions that are put in the Spring xml file. We have "UsernameToken", so decodeAction sets the internal representation of the expected WS Security elements to a list with the single value: WSConstants.UT(0x01).
> When a SOAP message arrives, UsernameTokenProcessor.handleToken() is called which sets the expected action to WSConstants.UT_NOPASSWORD (0x2000) because there is no password element.Thus when WSHandler.checkReceiverResultsAnyOrder() which checks that the list of expected actions and received actions are the same, it fails and the debug output is 'Security processing failed (actions mismatch)".
> Yes, we could override the Processor to get around this, but we were hoping to take advantage of the recent changes which meant that we just needed to implement our own Validator.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
[jira] [Updated] (WSS-321) Cannot configure for no password element
expected using Spring configuration
Posted by "Colm O hEigeartaigh (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh updated WSS-321:
------------------------------------
Fix Version/s: 1.6.4
> Cannot configure for no password element expected using Spring configuration
> ----------------------------------------------------------------------------
>
> Key: WSS-321
> URL: https://issues.apache.org/jira/browse/WSS-321
> Project: WSS4J
> Issue Type: Bug
> Components: WSS4J Core, WSS4J Handlers
> Affects Versions: 1.6.3
> Environment: Ubuntu 10.04. ServiceMix 4.
> Reporter: Paul Richardson
> Assignee: Colm O hEigeartaigh
> Fix For: 1.6.4
>
>
> We don't wish to have a Password element in the inbound SOAP request.
> WSSecurityUtil.decodeAction() parses the actions that are put in the Spring xml file. We have "UsernameToken", so decodeAction sets the internal representation of the expected WS Security elements to a list with the single value: WSConstants.UT(0x01).
> When a SOAP message arrives, UsernameTokenProcessor.handleToken() is called which sets the expected action to WSConstants.UT_NOPASSWORD (0x2000) because there is no password element.Thus when WSHandler.checkReceiverResultsAnyOrder() which checks that the list of expected actions and received actions are the same, it fails and the debug output is 'Security processing failed (actions mismatch)".
> Yes, we could override the Processor to get around this, but we were hoping to take advantage of the recent changes which meant that we just needed to implement our own Validator.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
[jira] [Closed] (WSS-321) Cannot configure for no password element
expected using Spring configuration
Posted by "Colm O hEigeartaigh (Closed) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh closed WSS-321.
-----------------------------------
> Cannot configure for no password element expected using Spring configuration
> ----------------------------------------------------------------------------
>
> Key: WSS-321
> URL: https://issues.apache.org/jira/browse/WSS-321
> Project: WSS4J
> Issue Type: Bug
> Components: WSS4J Core, WSS4J Handlers
> Affects Versions: 1.6.3
> Environment: Ubuntu 10.04. ServiceMix 4.
> Reporter: Paul Richardson
> Assignee: Colm O hEigeartaigh
> Fix For: 1.6.4
>
>
> We don't wish to have a Password element in the inbound SOAP request.
> WSSecurityUtil.decodeAction() parses the actions that are put in the Spring xml file. We have "UsernameToken", so decodeAction sets the internal representation of the expected WS Security elements to a list with the single value: WSConstants.UT(0x01).
> When a SOAP message arrives, UsernameTokenProcessor.handleToken() is called which sets the expected action to WSConstants.UT_NOPASSWORD (0x2000) because there is no password element.Thus when WSHandler.checkReceiverResultsAnyOrder() which checks that the list of expected actions and received actions are the same, it fails and the debug output is 'Security processing failed (actions mismatch)".
> Yes, we could override the Processor to get around this, but we were hoping to take advantage of the recent changes which meant that we just needed to implement our own Validator.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
[jira] [Commented] (WSS-321) Cannot configure for no password
element expected using Spring configuration
Posted by "Colm O hEigeartaigh (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132550#comment-13132550 ]
Colm O hEigeartaigh commented on WSS-321:
-----------------------------------------
I've added a WSHandlerConstants.USERNAME_TOKEN_NO_PASSWORD ("UsernameTokenNoPassword") action that can be used on the receiving side for this use-case.
Colm.
> Cannot configure for no password element expected using Spring configuration
> ----------------------------------------------------------------------------
>
> Key: WSS-321
> URL: https://issues.apache.org/jira/browse/WSS-321
> Project: WSS4J
> Issue Type: Bug
> Components: WSS4J Core, WSS4J Handlers
> Affects Versions: 1.6.3
> Environment: Ubuntu 10.04. ServiceMix 4.
> Reporter: Paul Richardson
> Assignee: Colm O hEigeartaigh
> Fix For: 1.6.4
>
>
> We don't wish to have a Password element in the inbound SOAP request.
> WSSecurityUtil.decodeAction() parses the actions that are put in the Spring xml file. We have "UsernameToken", so decodeAction sets the internal representation of the expected WS Security elements to a list with the single value: WSConstants.UT(0x01).
> When a SOAP message arrives, UsernameTokenProcessor.handleToken() is called which sets the expected action to WSConstants.UT_NOPASSWORD (0x2000) because there is no password element.Thus when WSHandler.checkReceiverResultsAnyOrder() which checks that the list of expected actions and received actions are the same, it fails and the debug output is 'Security processing failed (actions mismatch)".
> Yes, we could override the Processor to get around this, but we were hoping to take advantage of the recent changes which meant that we just needed to implement our own Validator.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org