You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rampart-dev@ws.apache.org by Bob Jacoby <bo...@gossamer-group.com> on 2008/10/27 19:12:48 UTC
Signing messages in OutFaultFlow
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
Re: Signing messages in OutFaultFlow
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
Hi Bob,
Yes, scenario you described fits the scenario 1 but I have never tested
it with the actual fault happening in a handler. Please create a JIRA with a
test case and I will look in to it,
thanks,
nandana
On Thu, Oct 30, 2008 at 10:05 PM, Bob Jacoby <bo...@gossamer-group.com> wrote:
> 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:nandana.cse@gmail.com]
> 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 <bo...@gossamer-group.com>
> 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
> > bob@gossamer-group.com
> > Gossamer Group
> > (512) 342-2600 Fax (512) 342-2612
> >
> > -----Original Message-----
> > From: Nandana Mihindukulasooriya [mailto:nandana.cse@gmail.com]
> > 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 <bo...@gossamer-group.com>
> > 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
>
RE: Signing messages in OutFaultFlow
Posted by Bob Jacoby <bo...@gossamer-group.com>.
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:nandana.cse@gmail.com]
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 <bo...@gossamer-group.com>
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
> bob@gossamer-group.com
> Gossamer Group
> (512) 342-2600 Fax (512) 342-2612
>
> -----Original Message-----
> From: Nandana Mihindukulasooriya [mailto:nandana.cse@gmail.com]
> 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 <bo...@gossamer-group.com>
> 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
Re: Signing messages in OutFaultFlow
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
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 <bo...@gossamer-group.com> 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
> bob@gossamer-group.com
> Gossamer Group
> (512) 342-2600 Fax (512) 342-2612
>
> -----Original Message-----
> From: Nandana Mihindukulasooriya [mailto:nandana.cse@gmail.com]
> 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 <bo...@gossamer-group.com>
> 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
RE: Signing messages in OutFaultFlow
Posted by Bob Jacoby <bo...@gossamer-group.com>.
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
bob@gossamer-group.com
Gossamer Group
(512) 342-2600 Fax (512) 342-2612
-----Original Message-----
From: Nandana Mihindukulasooriya [mailto:nandana.cse@gmail.com]
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 <bo...@gossamer-group.com> 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
Re: Signing messages in OutFaultFlow
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
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 <bo...@gossamer-group.com> 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