You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by "Doughty, Michael" <Mi...@bmc.com> on 2010/02/08 02:55:55 UTC
Preventing Axis2/Rampart from encrypting faults
We've rewritten several of our services from another Web services stack to Axis2 1.5.1. We are using Rampart 1.4 to handle the WS-Security 1.0 functionality from our previous services.
There have been a few differences though and I am unable to resolve some of them. The most important one right now is in the fault messages being sent from the service.
In our previous implementation, Fault messages were never signed and encrypted. However, in this Axis2 version they are always signed and encrypted. I've tried a few things I've seen from Google searches to see if I can prevent this. One of them was to remove the security phase from the OutFaultFlow section of the axis2.xml file in the WEB-INF/conf directory. However, this causes the Axis2 bundle to fail to load properly.
Is there any way to prevent the faults from being signed and encrypted while still allowing the standard outbound messages to be signed and encrypted?
RE: Preventing Axis2/Rampart from encrypting faults
Posted by "Doughty, Michael" <Mi...@bmc.com>.
That seems to have worked. Thanks very much for your help.
From: Amila Suriarachchi [mailto:amilasuriarachchi@gmail.com]
Sent: Sunday, February 07, 2010 9:46 PM
To: axis-user@ws.apache.org
Subject: Re: Preventing Axis2/Rampart from encrypting faults
On Mon, Feb 8, 2010 at 7:25 AM, Doughty, Michael <Mi...@bmc.com>> wrote:
We've rewritten several of our services from another Web services stack to Axis2 1.5.1. We are using Rampart 1.4 to handle the WS-Security 1.0 functionality from our previous services.
There have been a few differences though and I am unable to resolve some of them. The most important one right now is in the fault messages being sent from the service.
In our previous implementation, Fault messages were never signed and encrypted. However, in this Axis2 version they are always signed and encrypted. I've tried a few things I've seen from Google searches to see if I can prevent this. One of them was to remove the security phase from the OutFaultFlow section of the axis2.xml file in the WEB-INF/conf directory. However, this causes the Axis2 bundle to fail to load properly.
Is there any way to prevent the faults from being signed and encrypted while still allowing the standard outbound messages to be signed and encrypted?
you can unpack the rampart.mar file and edit the module.xml file so that no handlers goes to outFaultFlow. Then recreate the mar file. This won't create any problem when loading modules.
thanks,
Amila.
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Preventing Axis2/Rampart from encrypting faults
Posted by Amila Suriarachchi <am...@gmail.com>.
On Mon, Feb 8, 2010 at 7:25 AM, Doughty, Michael <Mi...@bmc.com>wrote:
> We’ve rewritten several of our services from another Web services stack
> to Axis2 1.5.1. We are using Rampart 1.4 to handle the WS-Security 1.0
> functionality from our previous services.
>
>
>
> There have been a few differences though and I am unable to resolve some of
> them. The most important one right now is in the fault messages being sent
> from the service.
>
>
>
> In our previous implementation, Fault messages were never signed and
> encrypted. However, in this Axis2 version they are always signed and
> encrypted. I’ve tried a few things I’ve seen from Google searches to see if
> I can prevent this. One of them was to remove the security phase from the
> OutFaultFlow section of the axis2.xml file in the WEB-INF/conf directory.
> However, this causes the Axis2 bundle to fail to load properly.
>
>
>
> Is there any way to prevent the faults from being signed and encrypted
> while still allowing the standard outbound messages to be signed and
> encrypted?
>
you can unpack the rampart.mar file and edit the module.xml file so that no
handlers goes to outFaultFlow. Then recreate the mar file. This won't create
any problem when loading modules.
thanks,
Amila.
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/