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