[jira] Resolved: (RAMPART-140) Processing of response fails if a security policy is set

["Nandana Mihindukulasooriya (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/RAMPART-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandana Mihindukulasooriya resolved RAMPART-140.
------------------------------------------------

    Resolution: Fixed

Fixed revision 620714.

> Processing of response fails if a security policy is set
> --------------------------------------------------------
>
>                 Key: RAMPART-140
>                 URL: https://issues.apache.org/jira/browse/RAMPART-140
>             Project: Rampart
>          Issue Type: Bug
>          Components: rampart-core
>    Affects Versions: 1.3
>         Environment: winxp, wso2 wsas 2.2 (axis2 1.35, rampart 1.35)
>            Reporter: Matt Voysey
>            Assignee: Nandana Mihindukulasooriya
>
> We have an (axis2 powered) webservice secured using UsernameToken over SSL Transport Security. The service returns checks InflowSecurity but has no OutflowSecurity configured - therefore it returns a soap response with no <wsse:Security> header.
> I've created a client program to consume this service and tried to use a security policy to set its security options. This basically configures the rampart module with a simple UTOverTransport policy (exactly as used in the rampart sample program (policy sample 01)). At runtime the receive path fails with an AxisFault: InvalidSecurity exception. I've tracked this down to the org.apache.rampart.handler.PostDispatchVerification class, which at the end of the invoke() method has some code as follows:
>        //Now check for security processing results if security policy is available
>         if(securityPolicyPresent && msgContext.getProperty(WSHandlerConstants.RECV_RESULTS) == null) {
>             throw new AxisFault("InvalidSecurity");
>         }
>         
> This effectively says if a security policy of any kind has been enabled and there is no security header in the message then it's an error. I don't think this is the case according to the ws-securitypolicy spec, in which the presence of even a Timestamp element is optional.
> Configuring rampart using the "deprecated" parameter-based approach (creating a specific OutflowConfiguration programmatically for the client stub) works fine with this same service.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.