Return-Path: Delivered-To: apmail-ws-axis-user-archive@www.apache.org Received: (qmail 9753 invoked from network); 17 Oct 2008 03:22:31 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Oct 2008 03:22:31 -0000 Received: (qmail 32594 invoked by uid 500); 17 Oct 2008 03:22:23 -0000 Delivered-To: apmail-ws-axis-user-archive@ws.apache.org Received: (qmail 32563 invoked by uid 500); 17 Oct 2008 03:22:23 -0000 Mailing-List: contact axis-user-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-user@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-user@ws.apache.org Received: (qmail 32552 invoked by uid 99); 17 Oct 2008 03:22:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Oct 2008 20:22:23 -0700 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of nandana.cse@gmail.com designates 209.85.142.191 as permitted sender) Received: from [209.85.142.191] (HELO ti-out-0910.google.com) (209.85.142.191) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Oct 2008 03:21:12 +0000 Received: by ti-out-0910.google.com with SMTP id y6so141539tia.18 for ; Thu, 16 Oct 2008 20:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=4r83UCVdFP7DT303e2BkVurPH1WOsyXIJLNIMrQxXWA=; b=lJhcjFUpnUb3OMdHj+hwhl/kmhnEOkgnvX4fOA5Ks3FyQ2sbNDQgSpE59Qwv1H/TcO ZoRJJaGafgsqbGBDhBEgdlxb0JeslEOssp3ULcI+hDjUrNPUM4rHhByXRm6xIKqZzrYb aWO3qh62qRNLaBwWxjrV1jqMbk6kVSwtRrj44= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=ZmQTeOlOaRf1T+tYxzG00lzOUvnqhGGTyQ4+fmFbl/GQanL6yt7guIym7hRY2iBlQI oQQDxkTdbyyz7TSk/xgDgxz95hEG/M8xVQWXBMtLxyRN7U7cafNsftbc6Up61ypZHi0p JQNE7zhYoRRTxWzJKscjCRIQvogi3wOTNa0pw= Received: by 10.110.31.5 with SMTP id e5mr2608714tie.1.1224213708657; Thu, 16 Oct 2008 20:21:48 -0700 (PDT) Received: by 10.110.63.2 with HTTP; Thu, 16 Oct 2008 20:21:48 -0700 (PDT) Message-ID: <9e2fff830810162021q1023600es636cf13311eacff0@mail.gmail.com> Date: Fri, 17 Oct 2008 08:51:48 +0530 From: "Nandana Mihindukulasooriya" To: axis-user@ws.apache.org Subject: Re: Rampart 1.4 mustUnderstand In-Reply-To: <20016802.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_75629_3982335.1224213708598" References: <19926442.post@talk.nabble.com> <4D9D4C5E5FC8C242A5C5FE28E94BFAA88CCD74@klimaxiii.tasima.co.za> <19984135.post@talk.nabble.com> <4D9D4C5E5FC8C242A5C5FE28E94BFAA88CD364@klimaxiii.tasima.co.za> <9e2fff830810160832hc6110c1j36a2d54d663b4fed@mail.gmail.com> <20016802.post@talk.nabble.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_75629_3982335.1224213708598 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Ronnie, Got you you requirement. I think in that case, it will be better if we can use soap actor / role. I will take a look at how much time/effort it will take to fix the issue [1]. I am interested in to know how your security firewall implemented. Does it pass the message as it to the real service ? So how something like decryption is handled ? Can't you just detach the security header [2] from the message before sending to the ultimate endpoint as it anyway doesn't understand it and not expected to process it. thanks, nandana [1] - http://issues.apache.org/jira/browse/RAMPART-16 [2] - http://nandana83.blogspot.com/2008/10/how-to-expose-web-service-protected-by.html On Fri, Oct 17, 2008 at 2:o27 AM, RonnieMJ wrote: > i > I see what you're saying, and I have seen this as an issue that others have > expressed, however it's not quite the issue I'm referring to. > > My issue turns out to be that as a client, I send to some service. That > service is not the ultimate receiver endpoint. It is more of simply a > security endpoint on a firewall. After verifying the security is ok, that > server forwards it to the ultimate receiver endpoint. Problem is that THIS > server doesn't understand security, and returns a fault. The > mustUnderstand > fault I get (Exception during processing: javax.xml.soap.SOAPException: > Unable to handle mustUnderstand header: wsse:Security (see Fault Detail for > stacktrace)) is thrown by the server and not by rampart. > > So it turns out to be the inability to EITHER specify mustUnderstand = 0 OR > specify an actor (soap 1.1) or role (soap 1.2). If I were able to specify > "next" as the actor for the security header, this wouldn't be an issue (or > if I was able to set mustUnderstand=0). > > I would say it's more this > http://issues.apache.org/jira/browse/RAMPART-16 > JIRA . > > Or this https://issues.apache.org/jira/browse/AXIS2-3982 JIRA . > > Either one would actually work I believe. > > > > Nunny wrote: > > > > Hi, > > The reason for this is due to the implementation logic. In Rampart 1.3, > > rampart processes the empty security header and set it as processed. But > > in > > Rampart 1.4, before going to the processing, Rampart evaluates the policy > > and check whether it is expecting a security header. And if it is not > > expecting a security header it, just returns. So in the latter case , > > the > > security header is not flagged as process. This causes AxisEngine to > cough > > as there are must understand headers not processed. > > We will fix this issue [1], so this no longer be a problem. > > thanks, > > nandana > > > > [1] - http://issues.apache.org/jira/browse/RAMPART-197 > > > > On Wed, Oct 15, 2008 at 12:21 PM, Taariq Levack > > wrote: > > > >> In my case it still says mustUnderstand=1, but it tolerates the empty > >> header which 1.4 does not. > >> > >> -----Original Message----- > >> From: RonnieMJ [mailto:ronniemjohns@hotmail.com] > >> Sent: 15 October 2008 01:30 > >> To: axis-user@ws.apache.org > >> Subject: RE: Rampart 1.4 mustUnderstand > >> > >> > >> I switched back to axis 1.3 with rampart 1.3. Still getting > >> mustUnderstand=1. I see others with the issue when using their own > >> axis2.xml, but I'm using the default axis2.xml that comes with axis. I > >> simply load the client policy (attached). Is it something in my policy > >> that > >> causes mustUnderstand=1? I wouldn't think so. > >> > >> > >> > >> Taariq Levack wrote: > >> > > >> > Had the same issue recently, the security header coming back from the > >> > service was empty in my case. > >> > > >> > For now I'm using 1.3 until the issue I raised is resolved. > >> > Try the same code with Axis 1.3 and Rampart 1.3 and see if that works > >> > for you. > >> > > >> > Taariq > >> > > >> > -----Original Message----- > >> > From: RonnieMJ [mailto:ronniemjohns@hotmail.com] > >> > Sent: 10 October 2008 23:32 > >> > To: axis-user@ws.apache.org > >> > Subject: Rampart 1.4 mustUnderstand > >> > > >> > > >> > Does rampart version 1.4 default mustUnderstand to 1? I'm getting the > >> > famous > >> > error, and am using a policy to set my configurations in code (client > >> > side > >> > ONLY). > >> > > >> > My wsse:security tag ends up as mustunderstand="1". > >> > >> > > >> xmlns:wsse=" > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse > >> > curity-secext-1.0.xsd" > >> > soapenv:mustUnderstand="1"> > >> > > >> > The security isn't set in the WSDL. I am using axis2 1.4.1. > >> > > >> > I've seen the WSDL2Constants flag, but I'm not using WSDL2Constants. > >> > > >> > Just the plain old: > >> > > >> > options.setProperty(RampartMessageData.KEY_RAMPART_POLICY, > >> > loadPolicy(confDir + "/clientSecurityPolicy.xml")); > >> > > >> > stub._getServiceClient().setOptions(options); > >> > > >> > > >> > stub._getServiceClient().engageModule("rampart"); > >> > > >> > > >> > I also don't have access to or control over what is used on the > >> service > >> > side > >> > (external). > >> > > >> > -- > >> > View this message in context: > >> > > >> > http://www.nabble.com/Rampart-1.4-mustUnderstand-tp19926442p19926442.htm > >> > l > >> > Sent from the Axis - User mailing list archive at Nabble.com. > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org > >> > For additional commands, e-mail: axis-user-help@ws.apache.org > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org > >> > For additional commands, e-mail: axis-user-help@ws.apache.org > >> > > >> > > >> > > >> http://www.nabble.com/file/p19984135/clientSecurityPolicyExternal.xml > >> clientSecurityPolicyExternal.xml > >> -- > >> View this message in context: > >> > http://www.nabble.com/Rampart-1.4-mustUnderstand-tp19926442p19984135.htm > >> l > >> Sent from the Axis - User mailing list archive at Nabble.com. > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org > >> For additional commands, e-mail: axis-user-help@ws.apache.org > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org > >> For additional commands, e-mail: axis-user-help@ws.apache.org > >> > >> > > > > > > -- > > Nandana Mihindukulasooriya > > WSO2 inc. > > > > http://nandana83.blogspot.com/ > > http://www.wso2.org > > > > > > -- > View this message in context: > http://www.nabble.com/Rampart-1.4-mustUnderstand-tp19926442p20016802.html > Sent from the Axis - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org > For additional commands, e-mail: axis-user-help@ws.apache.org > > ------=_Part_75629_3982335.1224213708598 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Ronnie,
       Got you you requirement. I think in that case, it will  be better if we can use soap actor / role. I will take a look at how much time/effort it will take to fix the  issue  [1]. I am interested in to know how your security firewall implemented. Does it pass the message as it to the real service ? So how something like decryption is handled ? Can't you just detach the security header [2] from the message before sending to the ultimate endpoint as it anyway doesn't understand it and not expected to process it.

thanks,
nandana

[1] - http://issues.apache.org/jira/browse/RAMPART-16
[2] - http://nandana83.blogspot.com/2008/10/how-to-expose-web-service-protected-by.html

On Fri, Oct 17, 2008 at 2:o27 AM, RonnieMJ <ronniemjohns@hotmail.com> wrote:
i
I see what you're saying, and I have seen this as an issue that others have
expressed, however it's not quite the issue I'm referring to.

My issue turns out to be that as a client, I send to some service.  That
service is not the ultimate receiver endpoint.  It is more of simply a
security endpoint on a firewall.  After verifying the security is ok, that
server forwards it to the ultimate receiver endpoint.  Problem is that THIS
server doesn't understand security, and returns a fault.  The mustUnderstand
fault I get (Exception during processing: javax.xml.soap.SOAPException:
Unable to handle mustUnderstand header: wsse:Security (see Fault Detail for
stacktrace)) is thrown by the server and not by rampart.

So it turns out to be the inability to EITHER specify mustUnderstand = 0 OR
specify an actor (soap 1.1) or role (soap 1.2).  If I were able to specify
"next" as the actor for the security header, this wouldn't be an issue (or
if I was able to set mustUnderstand=0).

I would say it's more this  http://issues.apache.org/jira/browse/RAMPART-16
JIRA .

Or this  https://issues.apache.org/jira/browse/AXIS2-3982 JIRA .

Either one would actually work I believe.



Nunny wrote:
>
> Hi,
>   The reason for this is due to the implementation logic. In Rampart 1.3,
> rampart processes the empty security header and set it as processed. But
> in
> Rampart 1.4, before going to the processing, Rampart evaluates the policy
> and check whether it is expecting a security header. And if it is not
> expecting a security header it, just  returns.  So in the latter case ,
> the
> security header is not flagged as process. This causes AxisEngine to cough
> as there are must understand headers not processed.
>   We will fix this issue [1], so this no longer be a problem.
> thanks,
> nandana
>
> [1] - http://issues.apache.org/jira/browse/RAMPART-197
>
> On Wed, Oct 15, 2008 at 12:21 PM, Taariq Levack
> <taariq.levack@tasima.co.za>wrote:
>
>> In my case it still says mustUnderstand=1, but it tolerates the empty
>> header which 1.4 does not.
>>
>> -----Original Message-----
>> From: RonnieMJ [mailto:ronniemjohns@hotmail.com]
>> Sent: 15 October 2008 01:30
>> To: axis-user@ws.apache.org
>> Subject: RE: Rampart 1.4 mustUnderstand
>>
>>
>> I switched back to axis 1.3 with rampart 1.3.  Still getting
>> mustUnderstand=1.  I see others with the issue when using their own
>> axis2.xml, but I'm using the default axis2.xml that comes with axis.  I
>> simply load the client policy (attached).  Is it something in my policy
>> that
>> causes mustUnderstand=1?  I wouldn't think so.
>>
>>
>>
>> Taariq Levack wrote:
>> >
>> > Had the same issue recently, the security header coming back from the
>> > service was empty in my case.
>> >
>> > For now I'm using 1.3 until the issue I raised is resolved.
>> > Try the same code with Axis 1.3 and Rampart 1.3 and see if that works
>> > for you.
>> >
>> > Taariq
>> >
>> > -----Original Message-----
>> > From: RonnieMJ [mailto:ronniemjohns@hotmail.com]
>> > Sent: 10 October 2008 23:32
>> > To: axis-user@ws.apache.org
>> > Subject: Rampart 1.4 mustUnderstand
>> >
>> >
>> > Does rampart version 1.4 default mustUnderstand to 1?  I'm getting the
>> > famous
>> > error, and am using a policy to set my configurations in code (client
>> > side
>> > ONLY).
>> >
>> > My wsse:security tag ends up as mustunderstand="1".
>> > <wsse:Security
>> >
>> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse
>> > curity-secext-1.0.xsd"
>> > soapenv:mustUnderstand="1">
>> >
>> > The security isn't set in the WSDL.  I am using axis2 1.4.1.
>> >
>> > I've seen the WSDL2Constants flag, but I'm not using WSDL2Constants.
>> >
>> > Just the plain old:
>> >
>> > options.setProperty(RampartMessageData.KEY_RAMPART_POLICY,
>> > loadPolicy(confDir + "/clientSecurityPolicy.xml"));
>> >
>> > stub._getServiceClient().setOptions(options);
>> >
>> >
>> > stub._getServiceClient().engageModule("rampart");
>> >
>> >
>> > I also don't have access to or control over what is used on the
>> service
>> > side
>> > (external).
>> >
>> > --
>> > View this message in context:
>> >
>> http://www.nabble.com/Rampart-1.4-mustUnderstand-tp19926442p19926442.htm
>> > l
>> > Sent from the Axis - User mailing list archive at Nabble.com.
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: axis-user-help@ws.apache.org
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: axis-user-help@ws.apache.org
>> >
>> >
>> >
>> http://www.nabble.com/file/p19984135/clientSecurityPolicyExternal.xml
>> clientSecurityPolicyExternal.xml
>> --
>> View this message in context:
>> http://www.nabble.com/Rampart-1.4-mustUnderstand-tp19926442p19984135.htm
>> l
>> Sent from the Axis - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>
>
> --
> Nandana Mihindukulasooriya
> WSO2 inc.
>
> http://nandana83.blogspot.com/
> http://www.wso2.org
>
>

--
View this message in context: http://www.nabble.com/Rampart-1.4-mustUnderstand-tp19926442p20016802.html
Sent from the Axis - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org

------=_Part_75629_3982335.1224213708598--