You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rampart-dev@ws.apache.org by "Nandana Mihindukulasooriya (JIRA)" <ji...@apache.org> on 2008/02/11 16:44:09 UTC

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

    [ https://issues.apache.org/jira/browse/RAMPART-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567672#action_12567672 ] 

Nandana Mihindukulasooriya commented on RAMPART-140:
----------------------------------------------------

Hi Matt,
        If you use the exact policy in sample 01 then you need to have a security header in the response because of the time stamp element. IFAIK, if the security binding policy contains a <sp:IncludeTimestamp/> element, then we MUST have a timestamp in the security header. 
       But I agree with you that this processing is wrong. If we used a policy in the sample 01 without the <sp:IncludeTimestamp/> element, this check will still fail unnecessarily. Will fix this asap. 

> 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
>
> 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.