• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

SOAP Header missing using Rampart w/ Axis2 Generated Stub

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I used Axis2 WSDL2Java to generate a client stub, which works just fine and dandy against an unsecured version of the service.

However, I need to use simple UsernameToken for a "secured" version.

I have followed the rampart samples and tried to accomplish this both via a config file:

<module ref="rampart" />
<parameter name="OutflowSecurity">
<action>
<items>UsernameToken</items>
<user>userblah</user>
<passwordCallbackClass>client.PWCallbackHandler</passwordCallbackClass>
</action>
</parameter>

...as well as through an OutflowSecurity (deprecated) object:

OutflowConfiguration ofc = new OutflowConfiguration();
ofc.setActionItems("UsernameToken");
ofc.setUser("userblah");
options.setProperty(WSSHandlerConstants.OUTFLOW_SECURITY, ofc.getProperty());


...and additionally through the following VERY SIMPLE code:

ServiceClient sc = <stub>._getServiceClient();
sc.engageModule("rampart");
Options o = sc.getOptions();
o.setUsername("userblah");
o.setPassword("userpass");

I noticed I was getting "MustUnderstand header not processed" errors, so...

When I serialize my SOAPEnvelope before sending the message off (in the generated stub code), I notice that the soap envelope does not contain an <env:Header> element.... it's totally missing.

Furthermore, if I put a system.out in my password callback handler, the code executes. Why?

There is one line of interest in the generated stub:

_serviceClient.addSoapHeaders(env);

Serializing the envelope before/after that line yields identical, headerless envelopes, yet debug dissection of the _serviceClient object reveals that it contains the appropriate action items, username, password, etc. Furthermore, the rampart object is correctly engaging according to console output, and I get no errors from Axis2 or Rampart (other than the MustUnderstand from the server).

Why is the service client not adding the appropriate soap header??? This should be so simple!

Please, any help is appreciated, I've spent nearly two full days trying all sorts of things, and I'm tired of searching Google, to no avail.

What could I be doing wrong?

I'm using Axis2 1.4 w/ Rampart 1.4

-Chris
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to JavaRanch.

First off, I have to admit that I don't know the answer to any of your questions. I've only ever tried to apply WS-Security via a config file, never programmatically.

The good news is that I was successful in doing that, and wrote up the whole thing, right here. The article includes a full example, source files, build file, config file, you name it. (The libraries included are from an older version of Axis2, but the update to 1.4 should be straightforward.)

I'll watch this thread, so if you have any questions, feel free to post them here.
 
Christopher Dobbins
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the warm welcome!

I will follow your example and see if it yields any answers, thank you.

-C
 
Christopher Dobbins
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
FYI, I misquoted a line of code before... the line I expect to see the soapenv:Header object present after is:

_serviceClient.addHeadersToEnvelope(env);

it does not change the envelope at all! doh!
 
Christopher Dobbins
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So... unfortunately when I set up my own test server and client w/ rampart and Axis2, it works seamlessly.

The problem is that I'm trying to write a client using rampart/Axis2 to work against a service generated with Weblogic 10. Should work fine, right?

I keep getting back a message from the server saying:

...AxisFault: MustUnderstand header not processed '{http://blah blah blah.xsd}Security'

If I remove the rampart portion of the client, I get back a 403: Forbidden code, and since when rampart is engaged it properly executes the callback to the PasswordHandler class, I am wondering if this is an interoperability problem between the client and server. If I turn the UsernameToken security on and then set WSHandlerConstants.MUST_UNDERSTAND to "false," I likewise get a 403: Forbidden.

I am completely stuck with no way to diagnose what is going wrong... it appears that my "diagnosis" of the header missing from the soap envelope was wrong, because it doean't call the password callback until axis is already handling the sendReceive, so it looks like it modifies the envelope somewhere in that method.

I wish there was a way to see my envelope in transport, but unfortunately I am not able to install any tcp monitors on my machine or anything of the like.

Has anyone ever seen that "MustUnderstand header not processed" error and understood what that means for the client?

As far as I can tell, the error means that the server was not able to process the header block I sent... the fact that the authentication fails completely when I set mustUnderstand to false seems to support this, but I could just be guessing... I'm not by any means a web services expert.

Just throwing this all out there in the hopes that someone else has had and solved this problem.
 
Christopher Dobbins
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok so I wrote a custom handler that prints out the SOAP envelope in transport and stuck it as the last phase on OutFlow and the first phase on Inflow. Rampart is working correctly, and the header IS being added to the envelope.

The problem appears to be the weblogic server does not understand the <wsse:Security> header that rampart is building... which is why it doesn't process it correctly and throws the "MustUnderstand header not processed" fault. When I set mustUnderstand="false," obviously, I get a 403: Forbidden because the server cannot validate the client....

Is anyone out there REALLY good with Rampart and can suggest a way to swap out the implementation that builds the UsernameToken object? Maybe there is another library that might work better... or the guy who wrote the service is feeding me incorrect information when he said that the server needs only username/password authentication. I've tried "UsernameToken" and "UsernameToken Timestamp," neither work.
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I had a very similar problem. come to find out it wasn't the server I was sending it to, it was the EVENTUAL endpoint that was throwing the error. Basically the system I was sending it to was not stripping it appropriately before passing it on (sigh). Unfortunately there was no one who would change this on the remote side (not under my control), so I eventually had to devise a way to send a mustUnderstand flag of 0 (or false). Unfortunately there wasn't a way for me to do this with Rampart and I had to simply download the source code, find where it sets the flag, and change it to pull from a property file (true or false).
I think the right way to do this was through the "actor" component of WSSE Security, where I would indicate next which would mean the first server it comes to would need security (which it has). But rampart didn't have this. So my way wasn't elegant or terribly maintainable, but it worked.
 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

I'm having a very similar issue.... the details are as follows. (I'm loosely basing my code on the following link http://www.javaranch.com/journal/200709/web-services-authentication-axis2.html).

I have created a web service client using the axis 2 codegen wizard plugin for eclipse.

The web service that is being consumed requires a time sensitive username token.

I have looked at the rampart samples but I'm receiving the following exception when performing the call:




I have the following in my axis2.xml




And the code that performs the request is as follows....




And the exception occurs at line 5 I've also verified through a packet sniffer that the request doesn't have the username token in the soap header and a debug point in the PasswordHandler is never hit.

Note: Rampart 1.3 with Axis2 - 1.4.1

Any help is appreciated.

Thanks,
Eric
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Try this policy

<wsp:Policy wsu:Id="UsernameToken" xmlns:wsu=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:SupportingTokens
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"/>
</wsp:Policy>
</sp:SupportingTokens>

<ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy">
<ramp:user>admin</ramp:user>
<ramp:passwordCallbackClass>org.apache.rampart.samples.sample03.PWCBHandler</ramp:passwordCallbackClass>
</ramp:RampartConfig>

</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
 
Weeds: because mother nature refuses to be your personal bitch. But this tiny ad is willing:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic