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 RonnieMJ <ro...@hotmail.com> on 2008/10/10 23:31:50 UTC
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-wssecurity-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.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
Re: Rampart 1.4 mustUnderstand
Posted by RonnieMJ <ro...@hotmail.com>.
The Oasis 1.0 specification states:
All compliant implementations MUST declare which profiles they support and
MUST be able to
process a <wsse:Security> element including any sub-elements which may be
defined by that profile.
but it then says:
When a <wsse:Security> header includes a mustUnderstand="true" attribute:...
The first would make me think that you HAD to have mustUnderstand="true" in
the Security header. The latter would make me think that it's optional...
RonnieMJ wrote:
>
> 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-wssecurity-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-tp19926442p20014731.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
Re: Rampart 1.4 mustUnderstand
Posted by RonnieMJ <ro...@hotmail.com>.
Well that was kinda my point to the company that we're integrating with.
They don't pull it off (and could). But getting them to change isn't going
to happen anytime soon. I guess that they're not really into using custom
code to pull it off when the actor/role would be able to do it. It does
pass the whole message.
Nunny wrote:
>
> 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 <ro...@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
>> > <ta...@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
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Rampart-1.4-mustUnderstand-tp19926442p20033806.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
Re: Rampart 1.4 mustUnderstand
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
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 <ro...@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
> > <ta...@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
>
>
Re: Rampart 1.4 mustUnderstand
Posted by RonnieMJ <ro...@hotmail.com>.
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
> <ta...@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
Re: Rampart 1.4 mustUnderstand
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
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
<ta...@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
RE: Rampart 1.4 mustUnderstand
Posted by Taariq Levack <ta...@tasima.co.za>.
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
RE: Rampart 1.4 mustUnderstand
Posted by RonnieMJ <ro...@hotmail.com>.
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.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
RE: Rampart 1.4 mustUnderstand
Posted by Taariq Levack <ta...@tasima.co.za>.
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