You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by "Colm O hEigeartaigh (Updated) (JIRA)" <ji...@apache.org> on 2011/10/21 11:34:32 UTC

[jira] [Updated] (WSS-321) Cannot configure for no password element expected using Spring configuration

     [ 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