[ https://issues.apache.org/jira/browse/RAMPART-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hans G Knudsen updated RAMPART-8: --------------------------------- Attachment: signed_parts_more_policy_compliant.diff Hi! Here is a proposal for making policy handling of signedparts handling more policy complient. The diff also includes updated for handling for encryptedparts - as these should be handled as signedparts - regarding handling of precense or not. If there are questions about implementation - feel free to contact me. I also looked into including searching for SignedElements (path-expressions) - but ran into same problem as mention on mailinglist - regarding prefixes/namespaces that had to be known upfront or search recursively in envelope. I could provide my suggestion if needed... > RAMPART : Policy handling of <SignedPart> <Header(s).. > ------------------------------------------------------- > > Key: RAMPART-8 > URL: https://issues.apache.org/jira/browse/RAMPART-8 > Project: Rampart > Issue Type: Bug > Reporter: Hans G Knudsen > Assigned To: Ruchith Udayanga Fernando > Attachments: fix_outgoing_signedpart_headers.diff, fix_signedpart_headers_rampart_svn.diff, fix_signedpart_headers_rampart_svn.diff, policy_client_only_sign_wsa_to_header.xml, policy_server_expect_all_wsa_headers_signed.xml, signed_parts_more_policy_compliant.diff > > > Hi > Interop testing with .Net/WCF we noticed a few problems if we used/tried to specify "Headers" in the SignedParts Policy block > eg > <sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> > <sp:Body/> > <sp:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing"/> > <sp:Header Name="Action" Namespace="http://www.w3.org/2005/08/addressing"/> > <sp:Header Name="MessageID" Namespace="http://www.w3.org/2005/08/addressing"/> > <sp:Header Name="ReplyTo" Namespace="http://www.w3.org/2005/08/addressing"/> > 1: Incoming handling does not use the list to check that specified headers were signed > Check could be : > - Is header from policy-list present in Soap message ? > - if present - check if header is in 'SignedElements' in WSSecurityEngineResult > 2: Outgoing handling fails if header specified in policy is not present in Soap Message - and message is not sent > Rampart calls WSS4J->WSSecSignature.addReferencesToSign to add headers to be signed - but fails if header is not present - could be a specified addressing header which is not needed in the current message. > Is this a desirable behaviour ? > I suppose you specify the headers in <SignedParts> because you want to enforce that they are signed (when receiving) - so should outgoing handling not be a little less strict ?? > ( - this could of cause also be a bug in WSS4J ) > 3. When used together with policy element <OnlySignEntireHeadersAndBody> - heades are added twice to the signature. > Axis survives this - but .Net/WCF cough a bit (throws exception / Soap fault) > - this is releated to (2) > /hans -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.