[
https://issues.apache.org/jira/browse/RAMPART-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472456
]
Hans G Knudsen commented on RAMPART-8:
--------------------------------------
Hi!
I just had a closer look at the patch that was applied...
In the incoming policy handling the RampartPolicyData.signedParts gets trashed
in PolicyBasedResultValidator ( around line 73 ) when
Vector signatureParts = RampartUtil.getSignedParts(rmd);
is invoked, and thereafter cannot be relied on in the following validate*
methods. Moving validateSignedPartsHeaders up before the above call is not a
clean solution.
The patch I proposed relied on RampartPolicyData.signedParts being 'immutable'
as it orignally was only written to by RampartPolicyBuilder, and thereafter
only read.
What does the validator expect to get returned from RampartUtil ?? A list of
elements that was signed ??
Now RampartUtil.getSignedParts returns soap-headers + body in case of
'isEntireHeadersAndBodySignatures' or otherwise policy definition of
SignedPart headers + body (if specified).
Is this what is needed for the validateEncrSig test ??
Should it not be the WSSecurityEngineResult.getSignedElements() if a SIGN
WSSecurityEngineResult is present, as this on holds the actual signed elements
??
For outgoing handling I donot see any problems - though I have not had time to
look further into it.
Are proposals for changes supposed to be discussed here or on the mailinglists
?? (if any exist for rampart)
regards
/hans
For the outgoing policy handling I cannot see any problems
> 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
>
>
> 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.
