Hi again, I made one more debug session and I was wrong that the MessageContext provided by a client is used at service side to verify the SOAP message policy configuration (which should be totally wrong :) ) So it seems that it is not possible to "corrupt" the service side policy in the way I have explained in my previous mail. Anyway I will appreciate any comments about the verification mechanism that I am researching these days.
Thank you, Dobri On Mon, Mar 31, 2008 at 5:57 PM, Dobri Kitipov < [EMAIL PROTECTED]> wrote: > Hi all, > Ruchith thank you for the answer. I will create a JIRA about this. > > Anyway I do not have a clear picture of the mechanism used in Rampart in > order to verify that the message send (by a client) is applicable to the > policy defined for the called WS? > Let us suppose we have a WS client. First it retreives the WS' WSDL to get > a notion about the policy to be used. Now let us suppose that this WSDL was > hacked/modified/corrupted somehow and the client is mislead about the policy > to be applied. Now I am expecting that when the SOAP message (created based > on the wrong policy) is send at server side there should be some kind of > Policy verification mechanism that verifies the policy applied is the same > as the policy defined fro the WS. What I saw is that Policy is retrieved > from the MessageContext, but it seems to me that the MessageContext is > provided to the server by the client (, so if the client is "mislead" then > the MessageContext should be wrong, too)? So I am expecting that Rampart > process the SOAP message based on a Policy created at service side not from > client side and it can detect any inconsistencies? > > I am sorry if I am asking something totally wrong, but it is very hard to > debug the whole process and I did not succeed to get a clear picture about > this. > I will appreciate any comments/advices on this. > > Thank you in advance! > > Regards, Dobri > > On Sun, Mar 30, 2008 at 10:25 AM, Ruchith Fernando <[EMAIL PROTECTED]> > wrote: > > > Hi, > > > > At the moment seems like we do not validate the exact elements that are > > required to be encrypted. > > > > IMHO we will have to improve the > > org.apache.ws.security.processor.ReferenceListProcessor to include the > > decrypted element information (in addition to the ref URI) for rampart > > to be able to validate the encrypted parts correctly. > > > > Thanks Dobri for pointing this out. > > > > Please file an issue here [1]. > > > > Thanks, > > Ruchith > > > > 1. https://issues.apache.org/jira/browse/RAMPART > > > > Dobri Kitipov wrote: > > > Hi everybody, > > > currently I am researching how Rampart is validating and verifying > > the > > > secured artifacts. Let me give you a sample scenario. Let's say we > > have a WS > > > which policy defines that a specific <sp:EncryptedElements/> should be > > > encrypted (corresponding to a given XPath expression). I am interested > > in > > > understanding the mechanism that is used to verify that the incoming > > message > > > has encrypted exactly that <sp:EncryptedElements/> with the given > > specific > > > XPath expression, but not something else. I suppose rampart is not > > just > > > counting scheme to ensure that the right number of encrypted/signed > > > parts/elements is reached? > > > I have not finished my research, but I will appreciate any good > > thoughts > > > and references related to this topic. > > > > > > Regards, Dobri > > > > > > > > > >
