Hi Nandana, Sorry to keep belaboring this, but I just want to make sure I am 100% crystal clear on the intended implementation of this feature before I put together a test case.
Assume the following scenario: 1. The Security phase successfully completes 2. A failure occurs at any point after the security phase successfully completes (e.g., a handler, the actual service implementation). The error thrown does NOT use the namespace that Rampart uses to determine that the fault occurred in the Security phase. Should the policy (if any) that would be applied if no failure occurs in Step 2, be applied when a failure does occur in Step 2? If the answer is yes (which I think it is based on Scenario 1), I'm not seeing this in practice and will put together a simple test case demonstrating this. If the answer is no, then my question is: why shouldn't it? Thanks, Bob PS - I assume this change was put into Rampart 1.4 -----Original Message----- From: Nandana Mihindukulasooriya [mailto:[EMAIL PROTECTED] Sent: Thursday, October 30, 2008 10:05 AM To: rampart-dev@ws.apache.org Subject: Re: Signing messages in OutFaultFlow Hi Bob, Let me clarify the comment. May the word protocol errors is bit confusing and not the proper word :). Scenario 1: Client sends a message message and the security is successfully verified. So the message reaches MR and then may be a service implementation class. An exception happens in the service implementation. So this fault will be secured according to whatever the applicable policy. This is what was meant by service level errors. Scenario 2: Clients sends a message and at the security phase (in rampart handler) security verification fails. So the the message will not go further in the inflow and fault message will be send back to the client. That fault message will not be secured. This is what was meant by protocol errors. So in the client side, how does the Rampart know whether this was a security validation failure or service failure ? It looks at the reason for error and for security validation errors has namespace qualified error codes. So we can omit security validations if the error code is one of them. thanks, nandana On Tue, Oct 28, 2008 at 11:34 PM, Bob Jacoby <[EMAIL PROTECTED]> wrote: > Hi Nandana, > > I read that issue, but I didn't think it applied to my situation. Perhaps > there's a gray area with respect to service vs protocol errors. Or maybe I'm > misunderstanding how policies are attached to messages/flows. > > From the JIRA issue: > > - Service level errors will be secured using the effective policy of the > message (in the OutFaultFlow) and will be validated for effective policy in > the (in the InFaultFlow). > > - Protocol errors ( errors while processing the security header ) will not > be secured using the security policy and not validated in the client side. > > In my case I have a custom phase at the end of the InFlow that runs some > application specific handler logic. If this logic succeeds, the actual web > service code is invoked and my response is signed. If it fails, the handler > throw an axis fault. I would consider an exception thrown by this handler to > be a 'service level error' rather than a 'protocol error' and the response > should be signed. However, it's not. > > On the flip side, if the rampart logic considers this type of error to be a > 'protocol' error then per the JIRA issue, the client side should not be > attempting to validate the response against the security policy. However, it > is, which results in an AxisFault for missing the security header rather > than the fault that my handler generated. > > I guess the question becomes how does Rampart decide whether the fault is a > service or protocol fault? > > Thanks, > Bob > > > > > Bob Jacoby > [EMAIL PROTECTED] > Gossamer Group > (512) 342-2600 Fax (512) 342-2612 > > -----Original Message----- > From: Nandana Mihindukulasooriya [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 28, 2008 12:42 PM > To: rampart-dev@ws.apache.org > Subject: Re: Signing messages in OutFaultFlow > > Hi Bob, > This is done on purpose. Have a look at this JIRA [1]. We only secure > service faults. But if the security validation fails we don't secure those > faults due to security considerations. > > thanks, > nandana > > [1] - http://issues.apache.org/jira/browse/RAMPART-90 > > On Tue, Oct 28, 2008 at 12:12 AM, Bob Jacoby <[EMAIL PROTECTED]> > wrote: > > > I believe I've run into issue > > https://issues.apache.org/jira/browse/RAMPART-193 where Rampart does not > > sign the outbound message if a fault is encountered. I throw a custom > > soap fault in a handler that runs after the Security phase completes. > > The outbound SOAP message is correct, with the exception that the > > request does not have the policy applied. > > > > Is there any known workaround for this? My consumers depend upon parsing > > the soap fault. With this issue, the only fault I ever get is a wsse one > > due to the response not being signed. The real fault is masked. > > > > In my tracing it appears as if Rampart can't find the appropriate policy > > to apply when constructing the RampartMessageData. > > > > Thanks, > > Bob > > > > > > > -- > Nandana Mihindukulasooriya > WSO2 inc. > > http://nandana83.blogspot.com/ > http://www.wso2.org > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.175 / Virus Database: 270.8.4/1752 - Release Date: 10/28/2008 > 10:04 AM > -- Nandana Mihindukulasooriya WSO2 inc. http://nandana83.blogspot.com/ http://www.wso2.org No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.8.5/1755 - Release Date: 10/29/2008 5:27 PM
