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 <[EMAIL PROTECTED]> > 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 >> > <[EMAIL PROTECTED]>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:[EMAIL PROTECTED] >> >> Sent: 15 October 2008 01:30 >> >> To: [email protected] >> >> 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:[EMAIL PROTECTED] >> >> > Sent: 10 October 2008 23:32 >> >> > To: [email protected] >> >> > 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: [EMAIL PROTECTED] >> >> > For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >> >> > >> >> > >> --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> > For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >> >> > >> >> > >> >> 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: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> > >> > -- >> > 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
